[re-ECN] re-echo of drop

[Matt Mathis <[e-mail]>]

I made a comment on the list some time ago that pertains to your point below:

2009/10/29 João Taveira Araújo <[e-mail]>uk>:
> Bob,
>
> I talked to you offline about this the other day, but here goes my main
> concern..
>
> Bob Briscoe wrote:
>>
>> For those who don't want the technical details, here's a summary
>> 1/ Since draft-00 (Oct 2005), the re-ECN spec has always said re-echo
>> whether congestion is drop or ECN-marking.
>
> Which suggests there is good reason to separate both. The endpoint behaviour
> doesn't change, but the network's understanding of what is happening does,
> and so you'll get an overestimation of upstream congestion. With a loss
> echo, you can give a neutral value (as with cautious packets) but still rate
> limit at the ingress. However...

My goal would  be to tweak RE-ECN and loss based RE feedback, such
that the signal semantics are congruent.  After all a loss and ECN
mark are supposed to be equivalent.

>> 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.  For unencrypted connections, these can be detected
by looking at TCP sequences numbers.  Yes it requires per flow state,
but it does not need to be done at the most heavily aggregated points
in the network

Thanks,
--MM--