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

[Bob Briscoe <[e-mail]>]

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