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

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

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

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

> 3/ Yes, black hole detection is critical (to re-ECN on drop as much as 
> to ECN).


I'm using the currently unused codepoint to signal loss echos. 
Correlating the amount of loss, congestion and RECT traffic to a 
destination might be a better way of detecting ECN black holes, 
especially as ISPs have an incentive to prod the deployment of something 
like this along. It might not be the easiest solution, but I think it's 
cleaner: this way you can tell if it's an "evil bit" black hole (dropped 
FNEs), or just ECN averse (FNE sets up state but packet which follows 
through is lost. Multiple loss echos follow?).

Joao.