Note: This ballot was opened for revision 04 and is now closed.
Summary: Has enough positions to pass.
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!
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
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
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.
the ConEx signals inserted into IP headers as shown in Figure 1
indicate the congestion along a whole path from source to
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
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
- 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
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?
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:
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-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
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)?
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.
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.
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
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
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?