Re: [re-ECN] CONEX Principles & Constraints (version 2)

[<[e-mail]>]

I think this is getting to be a good list... Specific comments by number:

 

1)    I would actually suggest spelling out that ConEx is not just open about the responses but is truly independent of any response

2)    Congestion information is already generally visible to the end points...

3)    Join the first two sentences...

4)    Perhaps phrase it that the logical result of constraints 2 & 3 is to put ConEx info in the IP header... Also this is not necessarily explicit signalling of all congestion info - just of whole=path info... packet structure à codepoint structure? Set of codepoints? The packet structure will still be IP.

5)    No, the receiver needs to inform the sender of its most recent knowledge of whole-path congestion. It doesn't necessarily follow that this is the same as what the sender will then set (flow start, sudden increases in sending rate, change of path, etc...). However some form of feedback does seem to be required in general

6)    This seems out of place in the list. Perhaps the list needs to be split into constraints and aims as two separate items

7)    This would also be an aim not a constraint.

 

Regarding the specific question of transport. I would favour limiting to TCP BUT explicitly stating that UDP is in scope as an extension once TCP is sorted. The problem with UDP is the lack of feedback...

 

Regarding "opportunistic" deployment, I think I might prefer unilateral or spell it out a bit better...

 

Toby

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 04 November 2009 16:35
To: [e-mail]
Subject: [re-ECN] CONEX Principles & Constraints (version 2)

 

Thanks for your very usefull comments about this. I've attempted a revised version

 

[CONEX information = expected rest-of-path congestion]

 

1.	Application-agnostic - the CONEX protocol should be open about the responses it allows to the CONEX information, supporting a diversity of traffic management practices by networks and end-hosts. The proposed WG will encourage experiments on traffic management, but not standardise them (in order to reduce its scope).
2.	Visibility of CONEX information - it should be easily visible to all network elements (even if the data traffic is encrypted), in order to ensure the widest possible applicability -- it is visible to both end-systems (to help them control their sending rate) and to network managers (to help them manage a bottleneck, whether traffic originates from their own users or from other networks).   
3.	Granularity of CONEX information - it should be sufficiently granular to allow near real-time, per packet traffic management. So that any node can see the impact of the packets it is asked to forward. The CONEX information is inevitably a minimum of 1 RTT out-of-date
4.	CONEX information is in IP header - 2 & 3 imply that the CONEX information is carried in the IP header. Signalling of congestion information is thus explicit, rather than implicitly through packet loss, delay or jitter, which allows a faster and more accurate reaction. The proposed WG will specify a packet structure (v4 & v6) to encapsulate CONEX information (header bits, interpretation)
5.	Transport protocol - the receiver needs to inform the sender what CONEX information to set (TBD: whether the capability of an ECN receiver is sufficient). 
6.	Threats analysis - the proposed WG will study the threats, especially from falsifying or suppressing the CONEX information
7.	Deployability analysis - the proposed WG will study technology to support incremental deployment steps: ECN routers vs non-ECN routers vs CONEX routers; receivers with CONEX-capability, ECN-capability, or neither; opportunistic deployment.

 

3 - John, does this now briefly summarise your granularity point? 

 

5 - some people have suggested we should restrict initial work to TCP (to limit WG scope). John has argued that UDP needs to be in scope. Views?

 

7 - bob, does 'opportunistic deployment' get your "subtle point 15"?

 

thanks

phil

 

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 29 October 2009 18:03
To: [e-mail]
Subject: [re-ECN] CONEX Principles & Constraints

 

We wanted to start some discussion on "principles" and "constraints" ie what we want to do in the proposed WG and how would its scope would be restricted (building especially on emails from John (about "principles") and Rich (about "requirements"). Eventually this would feed into the Charter. This is just a first guess, so please bash. Something on these lines would be in the "Constraints" part of the Agenda.  

                                                                  

1.	the purpose is to standardise the conex protocol - this exposes congestion information along the forwarding path of the Internet ("rest-of-path congestion"). (This is in addition to the current capability that exposes the congestion on the "path-so-far".). Note, the purpose doesn't include studying how the conex information could be used. Reason: there are lots of potential uses for the information. In order to reduce the scope of the proposed WG, we concentrate on the underlying information protocol.
2.	The protocol should be open about the responses it allows to the conex information. For example, it should not make assumptions about the behaviour of a particular application, and it should allow a diversity of potential traffic management practices (of networks and end-hosts).
3.	the conex information needs to be easily visible to all network elements, and be application-independent (including encrypted apps). Reason: this ensures widest possible applicability -- it is visible to both end-systems (to help them control their sending rate) and to network managers (to help them manage a bottleneck, whether traffic originates from their own users or from other networks).
4.	the conex information needs to be sufficiently up-to-date, for example so that it can usefully assist congestion control by end systems. Reason: stale information is little use. [Question: instead of "sufficiently up-to-date", would "real-time" or "near real-time" be better?]
5.	the conex information needs to be sufficiently granular, to allow identification of those sending traffic to the bottleneck [Comment: this is trying to get a point that John made about 'granular enough for cost allocation' but in a more generic way. "Identification" is a bad word as, for some readers, it might be imply more than intended - but I can't think of a better one at the moment. I hope that the following bullet about conex information in the IP header solves how to do it.]
6.	the conex information is carried in the IP header. Note: it is in scope to work out which IP header bits to use (and the implications for other stuff that may already be using those bits). 
7.	a protocol will be developed for both IPv4 and IPv6. Reason: both are needed for full applicability. (There was push-back on an earlier suggestion of narrowing the scope to IPv4.)
8.	TCP options will be used to inform the sender about congestion received at the receiver. (Note, current proposals require this information transfer.) Reason: narrow the scope by looking only at TCP, which is used by the vast majority of the traffic (~85-90%). 
9.	a baseline assumption is that routers are unmodified. Reason: deployment viability
10.	a baseline assumption is that conex information is signalled explicitly (through the IP header) and not implicitly signalled through packet loss, delay or jitter. Reason: explicit signalling allows a "better" reaction, for example faster, without impairment
11.	but we will also develop a solution where the conex information is signalled through packet loss. Reason: ECN is not enabled in most routers today; incremental deployment is critical
12.	(possibly) we will study an incremental deployment step where only the sender is conex-enabled [Step suggested by Matt]
13.	(possibly) another incremental deployment step?
14.	we will describe threats, especially from falsifying or suppressing the conex information - whether by ISPs or end-hosts. The protocol needs to allow such threats to be dealt with (in as simple a manner as possible), but the actual mechanisms to tackle those threats (using policer boxes, for instance) are out of scope. Reason: such mechanisms are about uses of conex, rather than exposing the information.
15.	anything else?

 

Thanks

phil