Congestion Exposure (ConEx) Concepts and Use Cases
Note: This ballot was opened for revision 04 and is now closed.
( Wesley Eddy ) Yes
Barry Leiba Yes
Martin Stiemerling Yes
Comment (2012-08-10 for -05)
Excellent document, just two minor issues: - I can understand that in Section 1 the overview of the documents was added, but I wonder why these individual drafts are listed: - [I-D.briscoe-conex-initial-deploy] - [I-D.briscoe-conex-data-centre] They are also mentioned down in the draft in Section 5. The point is that they describe some potential cases, but are not agreed with the WG. I would remove them. - This ref seems to be missing some information, e.g., where it was published! [Bauer09] Bauer, S., Clark, D., and W. Lehr, "The Evolution of Internet Congestion", 2009.
( Ron Bonica ) (was Discuss) No Objection
Comment (2012-08-09 for -05)
This may be a DISCUSS-DISCUSS, but I would like to pose the following questions: 1) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs downstream?. For example, assume that my ISP deploys CONEX. Assume also that a loss-prone link connects my PC to the CPE router in my kitchen. The TCP stack on my PC will report lots of loss. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network? 2) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs upstream? For example, assume that my ISP deploys CONEX. Assume also that I subscribe to a stream that incurs loss before it hits my ISPs network. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network? 3) Is the applicability of CONEX restricted to access networks, where it is possible to deploy per-user policers at the distant end of the network from the user? 4) Can CONEX markings be used as an attack vector? 5) How will CONEX behave in networks where incoming traffic can be characterized as follows: 90% is streaming UDP over IP multicast 10% is TCP. In this example, assume that multicast traffic is responsible for 90% of the congestion and that the multicast receivers send traffic in the reverse direction very infrequently. 6) How will CONEX work in a transition scenario, when some transport layer stacks are CONEX aware and others are not. 7) Does CONEX encourage traffic originators to falsify congestion markings?
( Stewart Bryant ) No Objection
( Gonzalo Camarillo ) No Objection
Benoit Claise (was Discuss) No Objection
Comment (2012-04-18 for -04)
Initially, I put a DISCUSS-DISCUSS because I was missing some information to correctly review the draft (This was advised by Ron Bonica). Discussing with Wes Eddy off line, maybe I should have put "Defer". Anyway, sorry for the confusion. Now that I had a 1:1 with Eddy, many points are clarified, and here is my feedback. - One of my confusion reading the draft was that I was missing the link with RFC3168. After a conf. call with Wes Eddy, I understand that your plan is to use an IPv6 destination option, and that RFC3168 is a very not required (but might be used, if I read http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-03#section-3 correctly). It would be nice to say a few words about this in the draft. - From the charter: The purpose of the CONEX working group is to develop a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. Question about how to do define the notion of flow inside the IP layer? I see an IPv6 destination option in http://tools.ietf.org/html/draft-ietf-conex-destopt-02, but I don't see any encoding for a flow in there? - Section 1, Introduction As described in Figure 1, congestion control currently relies on the transport receiver detecting these 'Congestion Signals' and informing the transport sender in 'Congestion Feedback Signals.' Do you always assume that, because you receive a congestion signals for a specific TCP session, the congestion is for this entire session? I see more and more cases for which a router does a Deep Packet Inspection, and treat applications differently, as opposed to the 5 tuple. Is this a use case for CONEX? Without a DPI engine on the sender, I don't see how this could work... - What is happening in case of ECMP? One router is congested, and not the other one. Is the CONEX enabled sender clever enough to mark only the affected flow (based on the 5 tuple)? - Following on the two previous points, I would like to see the issues/limitations documented. Issue 1: one round trip late Issue 2: the congested device MUST support CONEX. The Sender MUST support CONEX Issue 3: DPI engine must be supported on the sender, if we want to differentiate per application Issue 4: ECMP (if this is one) Issue 5: not UDP etc.. From there, the use cases are limited. I see one though: managed services, bought by an enterprise customer, out of a single service provider - Section 2.3 "rest-of-path congestion" (also known as "downstream congestion") is the level of congestion that a traffic flow is expected to experience between the measurement point and its final destination. What is a flow? The draft doesn't tell if the congestion is at layer 3, layer 4 or layer 7. In contrast, the ConEx signals inserted into IP headers as shown in Figure 1 indicate the congestion along a whole path from source to destination. source and destination what? IP addresses, or IP address/protocol/ports, or maybe IP address/protocol/ports/session id. That's a key question in my mind. Same remark in section 2.4, what is user's traffic Congestion: In general, congestion occurs when any user's traffic suffers loss, ECN marking, or increased delay as a result of one or more network resources becoming overloaded. - Section 2.4 definitions You define congestion here, while section 2.1 already defines congestion The definition used for the purposes of ConEx is expressed as the probability of packet loss (or the probability of packet marking if ECN is in use). This definition focuses on how congestion is measured, rather than describing congestion as a condition or state. - Section 3.1 By deploying a congestion policer at the BRAS location, the network operator can measure the congestion-volume created by users within the access nodes and police misbehaving users before their traffic affects others on the access network. My issue (again) with this use case, is if the BRAS sees a high congestion-volume ratio, it will police all traffic from that users. However, that users might at the same time be part of a webex call (voice + video), doing a backup, and downloading with P2P. And the flow/session/application (to be clarified) you want to slowdown are the P2P, then then backup, and not the webex. - 6. Security. Am I able to send a message (from my own IP address) with an IPv6 destination option containing the IP address of my neighbor, so that his packets are slowed down, and I can benefit from the full cable infrastructure? Seems like an important question...
( Ralph Droms ) No Objection
Comment (2012-04-12 for -04)
I could use a little help understand the example in section 3.1. Do I have it right that ConEx is used to provide information about congestion in a flow to devices that are not directly experiencing the congestion? In the use case in section 3.1, the congestion policer is placed exactly at the point where the existence of congestion is known. Why is any signaling mechanism needed at all? In the first paragraph of section 3.2, how does ConEx specifically encourage the use of scavenger transport protocols, relative to other congestion policing mechanisms? Does the second paragraph of section 3.2 suggest that ConEx is used to actively affect traffic management in a way that is not directly related to congestion experienced at the user device? That is, the receiver uses artificially generated congestion signals to cause ConEx marking that affects its received traffic. This use case is fine, except that labeling the receiver->sender signaling as "congestion feedback" is no longer accurate.
( Adrian Farrel ) No Objection
Comment (2012-04-06 for -04)
A fine document that would have been enhanced by a short exposure of the Conex references to live up to the "entry point" claim. --- Classic ASCII-art. Well done!
Stephen Farrell No Objection
Comment (2012-04-10 for -04)
Section 2.4: what (if any) metric is used for rest-of-path and upstream- congestion? Is it volume? If so, or if not, be good to say that.
Brian Haberman No Objection
Comment (2012-04-10 for -04)
In general, this is a good high-level description of what the community should expect in the coming CONEX drafts. I do have a few questions though... 1. The draft talks about attributing congestion-volume contributions. Shouldn't there be some description of how that would be done? That sounds like a lot of state to maintain when congestion begins to occur. 2. Conceptually, if a CONEX-aware device in a network sees 10 packets of varying size from a single source and all have these CONEX markings, how do I equate the congestion-volume contribution of that source? Are there assumptions made about the packets' characteristics *in the last RTT* based on the packets seen in the current RTT?
( Russ Housley ) No Objection
( Pete Resnick ) No Objection
( Robert Sparks ) No Objection
( Sean Turner ) (was Discuss) No Objection
Comment (2012-04-11 for -04)
s2.2: Maybe: Congestion-volume is a property of traffic, whereas congestion describes *a property of* a link or a path. s3.1: 1st para: manage really meanest throttle and management means throttling right ;) s3.1: I'm obviously not hard over on either of these: Monitor is much a nicer term than policer, but maybe monitor is overloaded. Also "police traffic" maybe "manage misbehaving". s3.3: For give the security guy, but "scavenger transports" refers to ... Vultured TCP (vTCP)?