Re: [re-ECN] ConEx-IP & ConEx-TCP as separate docs?

Hi

As I see it the congestion is fed back using basically two methods
1) For each received packet
2) For every N packets

TCP (and SCTP?) belongs to the 1st cathegory while RTP/UDP (RTCP) is a good example of the 2nd cathegory, I also believe that DCCP fits into the 2nd. 

In cathegory 2 the feedback can be either an RLE encoded sequence of congestion marks or a number that describes how many congestion marks since the last report. This has implications on how the congestion is reinserted into the IP packets.
So all in all cathegory 2 comes with a 2 extra complications 
1) reinsertion of congetsion (credit) is delayed by an extra amount corresponding to the report interval
2) If congestion is only reported as a number then the reinserted credit must be pasted out in some fashion (uniform distribution?).  
I don't see this as complicating matters for the IP header, but it has implications for the (incentive)droppers and possibly the congestion volume policers.  
There are other issues like reaction to congestion here but I believe that this another vector in the multidimensional problem space.
I may have missed some issues here, please enlighten me.

I don't have any strong feeling regarding one or two documents but somehow I would prefer a separate ConEx IP doc that describes the protocol details on IP level and then the implications of different approaches to congestion feedback without too much mention of transports like TCP, RTP/UDP....  
Separate docs like ConEx TCP, ConEx RTP/UDP and so on would then carve out the details for each transport

The main point should be that an implementor of an (incentive)dropper or a congestion volume policer should ideally only need to read the ConEx IP document to get enough informaton. 
Application developers would need to read both ConEx IP and the transport related ConEx docs.

My 5€  
/Ingemar

> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 14 Dec 2009 18:18:14 +0000
> From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
> Subject: [re-ECN] ConEx-IP & ConEx-TCP as separate docs?
> To: ConEx IETF list <re-ecn@ietf.org>
> Message-ID: <200912141818.nBEIICBS025236@bagheera.jungle.bt.co.uk>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> Folks,
> 
> In chartering discussions, the ConEx spec(s) for IP are 
> implicitly separate from those for TCP and for other 
> transports. On balance I believe separating IP out is the 
> best course, but I'm I'm willing to be persuaded otherwise, 
> hence this posting...
> 
> We should all be aware of the implications of writing a ConEx 
> spec for IP alone (for all transports). The alternative is to 
> write the spec for ConEx in TCP/IP as one doc including 
> generic guidelines for all transports. Then gradually write 
> other transports as separate specs.
> 
> When ECN was written (RFC2481 then 3168), the IESG decided IP 
> & TCP should be written together.
> 
> Yes, IP-only will be a good exercise in being transport agnostic. 
> Writing the wire protocol should be straightforward, but the 
> document, and particularly the protocol semantics, will be 
> abstract and difficult for an implementer to read and 
> understand, as well as difficult to write.
> 
> Also:
> 1) No-one will be able to implement an IP-only spec without 
> also implementing a transport.
> 2) IP doesn't recognise flows, but we will have to talk about 
> what to do at flow start and after flow idle time (because 
> ConEx is about expectation of congestion, which you don't 
> know at these times).
> 3) IP also doesn't recognise round trip times, but again we 
> will have to talk about them - for instance, the expectation 
> of congestion depends how much the transport plans to 
> increase its rate in the next RTT.
> 4) It won't be easy to include transport example(s) without 
> confusing the reader into thinking this is a spec of that transport.
> 
> None of these problems is insurmountable. But do we want to 
> make life difficult for ourselves?
> 
> We do have the advantage of already having re-ECN as an 
> example combined spec for TCP/IP. This should make going 
> straight to an IP-only doc easier. But we have to incorporate 
> Matt Mathis's idea, which still doesn't have wire protocol 
> details worked out (I think that will be tough or maybe 
> impossible in the space available). That process is probably 
> easier in a single doc first.
> 
> Discuss...
> 
> 
> Bob
> 
> 
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 10, Issue 22
> **************************************
> 