Re: [re-ECN] Other transports than TCP in charter

[<[e-mail]>]

> -----Original Message-----
> From: John Leslie [mailto:[e-mail]]
> Sent: 13 November 2009 12:00
> To: Moncaster,T,Toby,DEE1 R
> Cc: [e-mail]
> Subject: Re: [re-ECN] Other transports than TCP in charter
> 
> [e-mail] <[e-mail]> wrote:
> >
> > Any WG that is formed as a result of this BoF will have a very
> > difficult balancing act to do - clearly eventually we want every
> > transport that is commonly used on the network to integrate ConEx.
> 
>    Hopefully, we can agree on that much...
> 
> > However each transport will add significantly to the time it takes
> > the WG to produce usable output.
> 
>    Well, that depends...
> 
>    IMHO, how _any_ transport determines what fraction of IP packets
> "expect" congestion is pretty much out-of-scope for CONEX. Clearly
> TCP congestion-control algorithms will differ in this, and I believe
> we're agnostic about which way is right.

We may be agnostic about what is right, but we may have views about what
is wrong (in other words some things may be demonstrably wrong like
significantly under-estimating the forward congestion which will reduce
the utility of conex).

> 
>    Almost as clearly, we'd be fools to _only_ worry about TCP, because
> the vast majority of TCP connections will depend upon UDP for the DNS
> lookup; and any "policing" will take into account UDP packets.
> 
>    We _do_ need to specify _how_ any transport _signals_ congestion
> expected, which I expect will be at the IP layer.
> 
> > My view is that we therefore need to approach transports in a
> > sensible order. One possible compromise might be as follows:
> >
> > ? Define a clear set of minimal transport requirements since these
> >   will allow people to start working out how to integrate this
> >   into their transport of choice.
> 
>    Such as... ?

The key thing here is at what point should the path congestion
information you have be considered stale and how accurately should you
be trying to measure congestion


> 
> > ? Fully define the protocol extensions for TCP since this is still
> >   the transport of choice for both the majority of bits and the
> >   majority of flows.
> 
>    Is it clear that we need to define _any_ "protocol extensions"
> for TCP?

Well, it depends on how accurate you want to be. Currently ECN in TCP is
designed to effectively mask multiple congestion signals in a single RTT
since TCP will only react once anyway. For conex to be accurate we
really need to know about EVERY CE mark. And our simulations suggest in
any network with lots of short lived flows it is not uncommon to get
multiple marks in a RTT.

> 
> > ? Then follow Ingemar's suggestion of adding this to RTP (and
> >   related real-time protocols) since these are becoming ever more
> >   significant as real-time media really starts to take off.
> 
>    I would hope that RTP could work from merely a definition of how
> to signal "congestion expected".

So would I, but somehow even the easiest things at the IETF seem to grow
in complexity!

> 
> > ? Then move onto transports such as SCTP and DCCP once we have
> >   evidence of how the TCP implementation is going.
> 
>    I can agree that worrying about "protocol extensions" for
transports
> other than TCP and UDP shouldn't be "critical path" to getting TCP
> experiments going.
> 
> --
> John Leslie <[e-mail]>