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

[Bob Briscoe <[e-mail]>]

Don,

At 18:38 14/12/2009, Don Bowman wrote:
>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.

I think there's been a misunderstanding. I didn't mean we can't *do* 
IPv4 because it hasn't got a concept of flows. I was merely talking 
about how abstract it will be to *write* about the semantics of ConEx 
in IP without also talking about the semantics of flows for specific 
transport(s).


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

Oh! this certainly is the goal - that's the point. Congestion 
exposure in the IP header means we don't need to care what's in the payload.


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

I don't imagine we should do TCP-only, just TCP-second (with 
IP-first). We should be keeping all transports in mind all the time, 
incl issues like fragmentation.

I have a draft (ietf-tsvwg-byte-pkt-congest) that says a congestion 
mark on a packet means all the bytes are marked (similarly a packet 
drop means all the bytes are dropped, of course). This gives the 
right thought framework to standardise fragmentation & reassembly.


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

I propose we rule multicast out of scope in ConEx. Not because we're 
doign TCP-only, but because ConEx is unnecessary for multicast (and 
it would be hard if you did need it).

The rationale behind ConEx is that the sender controls unicast packet 
sending, so you need info on congestion at the sender's network. With 
multicast, the receiver can control whether it receives (even tho it 
can't control how fast it receives). So ECN is sufficient for 
multicast, without re-ECN.

We need to have this discussion tho, but that's a brief version of 
the argument.


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

Of course. Because we're doign IP-first, then TCP-second != TCP-only.


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

Again, TCP-second != TCP-only

Cheers



Bob


>--don

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design