Re: [re-ECN] re-echo of drop

[João Taveira Araújo <[e-mail]>]

Quick comment (more of a doubt actually)

Matt Mathis wrote:
>>> 2/ Re-ECN currently doesn't re-echo on drop unless the receiver is at
>>> least ECN-capable. But there's an easy way to make that happen, but with
>>> possible devil in details.
>>>       
>> You don't want to mix FNE's with l-echos. Besides being a weak abstraction,
>> the FNE flag is critical in creating state, which you use for policing flows
>> and sampling interdomain. Another problem with loss echos without re-ECN is
>> it makes it impossible for networks to verify the percentage of e2e loss
>> over bulk traffic, since they don't know what traffic marks loss or not.
>>     
>
> The Ah Ha is that this condition detectable/enforceable.   There has
> to be a one-to-one correspondence between RE marks and
> retransmissions.

There is some sort of equilibrium property, but re-ECN (for now) has the 
notion of building up credit at flow start almost as a sign of goodwill 
to the policer. From my understanding this opens up the possibility of a 
retransmission NOT being marked. For example, if a flow is finishing off 
with sufficient credit to offset CE markings, it could choose to not 
re-echo congestion. Bob should be able to clear this one up.

This also made me wonder whether the one-to-one correspondence is simply 
a trademark of TCP or whether it's a characteristic we want to enforce 
on every future transport protocol. Considering most short flows don't 
get out of slow start, if some were to transfer all their data in a 
burst of (re) marked packets, is this inherently wrong?

Joao