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

[Bob Briscoe <[e-mail]>]

Mirja,

At 12:46 16/12/2009, Mirja Kuehlewind wrote:
> > 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.

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
>not-ConEx packets. In a long range from my understanding it would be the goal
>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
>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)?

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.

>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...

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


>Mirja
>_______________________________________________
>re-ECN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design