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

[John Leslie <[e-mail]>]

[e-mail] <[e-mail]> wrote:
>> From: John Leslie [mailto:[e-mail]]
>>
>> 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).

   I don't think "significantly under-estimating" will necessarily
"reduce the utility" of CONEX. We should be able to define policing
in a manner which incrementally improves utility.

   In all probability, there will be significant non-CONEX-marked
traffic at any policing point, which may instead lead to "significant
over-estimating" of forward congestion. This IMHO should lead to
estimating "willingness to pay to upgrade" on the high side, which
may speed the upgrade process and certainly marks the traffic as
deserving a higher priority than unmarked traffic.

   "Significant under-estimating" OTOH will lead to low estimates of
"willingness to pay to upgrade", and possibly causing a lower priority
to be inferred.

   It does seem worthwhile for us to define what constitutes the "right"
amount to estimate; but I'm not sure it helps to jawbone about whether
an estimate is high or low.

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

   Clearly, staleness corresponds to how far past one RTT you are.
Unfortunately, what "one RTT" actually means is less clear.

   IMHO, "how accurately you measure" congestion is a meaningless
concept unless we agree what "congestion" is -- which I don't believe
will ever happen.

>> Is it clear that we need to define _any_ "protocol extensions"
>> for TCP?
> 
> ... Currently ECN in TCP is designed to effectively mask multiple
> congestion signals in a single RTT since TCP will only react once
> anyway.

   I prefer not to comment on that: over-estimating should give you
"better" throughput; under-estimating "worse" -- pick your poison...

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

   Agreed. But that's getting into how congestion is signaled to the
sender, which still feels out-of-scope to me...

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

   Indeed!

--
John Leslie <[e-mail]>