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

[Mirja Kühlewind <[e-mail]>]

Hi,

> The thing I (and probably Ingemar) would ideally like to see is a charter
> that doesn't preclude the introduction of proposed work involving
> transports other than TCP.  

Yes! Me too. Actually exposing congestion is something that works on IP layer. 
Then you might want to also specify how the algorithms should work on sender 
and  on receiver side to count congestion and estimate the right number of ce 
marks to send. But how you actually feedback the current state of your 
counter from the receiver to the sender is a minor thing. In TCP case it 
might be using the 3 ECN bit. In another protocol you simply use 3 or more 
other bits. Definitely you need some requirements how often you have to 
feedback this information and so on. But this you need for very transport 
protocol. 
And than furthermore the case were you have no feedback channel should be 
covered as well, anyway.
But finally how to react on congestion (with TCP congestion control or 
something else or not at all) is in my option out of scope.

> This is perhaps a question to the chairs/ADs, 
> but would it be possible to have a charter that makes a more general
> statement about transport protocols, and then for now have a specific
> milestone that only identifies a work item for TCP and no other transport
> protocol?
I still think that we can't excluse other protocols anyway. If the goal is to 
make the endsystem/user more responsible for their congestion (using some 
kind of congestion policing on ingress node) you need to have congestion 
exposure on very kind of traffic. Otherwise this gives one the chance to 
cheat.

Mirja