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

[Bob Briscoe <[e-mail]>]

Joao,

At 15:49 29/10/2009, João Taveira Araújo wrote:
>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.

[BB] I am aware that everything you say under 1/& 2/ will be a problem.
This is why I think we need to work out whether 
there is a better codepoint arrangement. But it's 
not easy - for instance, I'm not convinced that 
the assignment for re-echo on drop that you have 
chosen is a good one. I.e. using the 'currently 
unused' codepoint left free in the re-ECN spec (ECT(1) with the RE flag set).

That involves sending an ECN-capable codepoint to 
a receiver that doesn't understand ECN. If this 
passes through a congested ECN-capable queue 
(different from the queue that did the drop in 
the last round) these packets will get ECN marked 
as congestion experienced (CE). The receiver is 
not ECN-capable so it will not understand and the 
congestion notifications will all get lost.


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

[BB] ECN black-hole generally means, when a 
client sends SYN with ECN flags in the TCP header, either:
- home router crashes, or
- home router drops the SYN, possibly returning a TCP RESET, possibly not
(See RFC3360)

This means there won't be any packets to measure 
- nothing gets past the home router, because of 
the TCP header, not the IP header. Am I missing something?

[BTW, there are many other ways for crap 
implementors to screw up everything... Recently, 
folks at UCL have also seen a router (probably at 
UCL's border) clearing ECN-capable codepoints in 
the IP header of UDP datagrams, back to Not-ECT (00). Dangerous, but true.]


Bob


>Joao.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design