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

["Ingemar Johansson S" <[e-mail]>]

Hi

Just a comment to the TCP vs UDP discussion. IMHO the "center of
gravity" is IP.

It is true that UDP alone does not provide with any feedback, however
the work around ECN for RTP in AVT
(http://tools.ietf.org/id/draft-westerlund-avt-ecn-for-rtp-02.txt)
should be applicable as long as one run RTP/(something)/IP. Typically
that (something) is UDP. For other than RTP over UDP transports it
should be possible to devise similar mechanisms. It must also be
recognized that in many cases UDP-tunneling is proposed as a means to
manage NAT/FW traversal for new transports like DCCP and in certain
cases even for TCP, in the latter case a policing node will not see that
the transport is actually TCP..

So I would not rule out other than TCP transports, rather I would give
it the same priority as UDP or alterantively try to unthink TCP and UDP
(or whatever is on top of IP) as much as possible. The testing is for
natural reasons on some transport that provides with the feedback
mechanisms (TCP or RTP/UDP or DCCP or SCTP) but the ConEx protocol
design should not need to consider the transport, what matter is is that
feedback is sent back to the sender. It is up to the applications to fix
the feedback and it is in this case also in the applications best
interest to do so. This may lead to extra standization of feedback
mechanisms but I don't beleieve that this standardization necessarily
needs to happen in ConEx.

/Ingemar




> Message: 1
> Date: Wed, 4 Nov 2009 17:07:29 -0000
> From: <[e-mail]>
> Subject: Re: [re-ECN] CONEX Principles & Constraints (version 2)
> To: <[e-mail]>om>,	<[e-mail]>
> Message-ID:
> 	
> <[e-mail]1
> .systemhost.net>
> 	
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 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
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/re-ecn/attachments/20091
104/0a3b3b0b/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 9, Issue 5
> ************************************
>