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

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 16 Dec 2009 08:23:51 +0100

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 <[email-masked]>
> Subject: [re-ECN] ConEx-IP & ConEx-TCP as separate docs?
> To: ConEx IETF list <[email-masked]>
> Message-ID: <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 10, Issue 22
> **************************************
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 16 Dec 2009 13:46:23 +0100

> 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.
That's a good point. Inline with that we have to address how to handle 
not-ConEx packets. In a long range from my understanding it would be the goal 
to make very IP packets ConEx-capable. That would mean you need to have an 
IP(-only) spec and also specify requirements for a feedback mechanism (in 
transport layer) regarding e.g. max delay of the ConEx information or 
whatever.

So the question is: Is the goal to make ConEx used by very kind of transport? 
Or does ConEx also work if just some connections use it (e.g. TCP based 
ones)?

I'm not sure if a policer at network ingress makes any sense if one easily can 
avoid to exposure the congestion information by not using TCP...

Mirja

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 16 Dec 2009 15:03:15 +0000

Mirja,

At 12:46 16/12/2009, Mirja Kuehlewind wrote:
>That's a good point.

Yes, good point (Ingemar). I hadn't thought about implementors of 
incentive mechanisms. This makes tips the balance more towards a 
separate IP doc for me.

>Inline with that we have to address how to handle
>to make very IP packets ConEx-capable.

I don't think we need to have that aas a goal. A better goal would be 
to have the system working well with permanent partial deployment. If 
one day the Internet has very few non-ConEx packets on it, that's 
beyond success, but it doesn't need to be a goal.

>That would mean you need to have an

ConEx should work if only some connections use it. That's important 
for incremental and partial deployment. For example, DNS datagrams 
might not be upgraded to use ConEx for a very long time.

Certainly an ultimate goal could be to update every transport to be 
able to use ConEx. And new transports might not even need a non-ConEx 
variant (ConEx info does no harm if it's ignored). We don't have to 
feel we've failed if we never update *all* transports.

>avoid to exposure the congestion information by not using TCP...

I disagree.

In future an ISP can:
1/ limit congestion entering its network (using a ConEx-based policer)
2/ also allow through some non-ConEx packets, but bit-rate-limited.

Over the years, as legacy OSs reduce in popularity, ISPs will tighten 
down the non-ConEx limit further. This way, the ISP can encourage 
users & OS/app vendors to expose congestion to them using ConEx. 
(ISPs could then have an interesting role in helping to deprecate 
end-of-life OSs, which will keep up sales of new OS licenses!).

We designed re-ECN to ensure re-ECN packets were distinguishable from 
non-re-ECN. It's important to do that for ConEx too. Sally Floyd was 
much happier with re-ECN when it became clear that I was not trying 
to change the service model of existing packets, but instead I was 
adding a new service model.

Then there can be market selection, between the two aproaches.

For ConEx the goal of "measuring congestion-volume as easily as we 
measure volume today" has to apply at a border (say), where you want 
to ignore non-ConEx packets, as they would confuse the measurement. 
You want to be able to filter out non-ConEx packets by just looking 
at them - you don't want flow state.

Bob