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

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Dec 2009 18:18:14 +0000

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

---

From: "Don Bowman" <[email-masked]>
Date: Mon, 14 Dec 2009 13:38:27 -0500

From: Bob Briscoe
> be persuaded otherwise, hence this posting...
 ...

> 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

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 16 Dec 2009 08:54:53 +0000

Don,

>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

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.

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

>as part of the flow? (e.g. from PMTU).

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

>VPN over UDP, GRE) that are skipped by this.

Again, TCP-second != TCP-only

Cheers

Bob