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

["Don Bowman" <[e-mail]>]

From: Bob Briscoe
> 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...
> 
 ...

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

For IP, would we maybe start just @ ipv6, it does have a flow (RFC3697).
Having the success of TCP behind would make it simpler to convince
adopters.

For a router adopter, the flow need not be the 5-tuple, even in the TCP
case, it could be e.g. MPLS.

Similarly i'm assuming that there is no intent to solve IPSEC-AH with
transport
mode for TCP?

TCP typically is not fragmented, although tunnels + misconfiguration
do lead rise to a small amount. So if we address TCP-only i suspect will
not be addressing the fragmented case where PMTU has failed us.

TCP-only would also let us conveniently skip some multicast issues.

If its TCP-only, would i assume that associated ICMP would be included
as part of the flow? (e.g. from PMTU).

I would support the pragmatic "split and solve tcp" approach.

There are of course some non-TCP, congestion-causing, flow-based cases
(e.g.
VPN over UDP, GRE) that are skipped by this.

--don