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

[John Leslie <[e-mail]>]

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

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

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

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

> ? 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]>