[e2e] TCP Loss Differentiation

[Jon Crowcroft]

um - i am not talking about whether ECN works right in the presence of
lost packets - i am talking about what you need to differentiate 
non-congestive loss. you need to be somewhat more ingeneious - 

if each router were to record in every packet in a flow, all the
packets it had seen, the order it had seen them, and the routers own
address, then when any packet arrives, you'd have a cmplete history of
packets predeceessors and successors and gaps, and where gaps are
caused, and so a receiver can disambiguate on a _per packet_ base 
when a loss was not congestive...

In missive <3D86E9E6-8FB4-458C-9DC2-8883F8805161 at cisco.com>, Fred Baker typed:

 >>
 >>On Feb 22, 2009, at 4:33 AM, Jon Crowcroft wrote:
 >>
 >>> thought experiment - what if a packet that is ECN marked gets lost?
 >>
 >>The structure of ECN is such that it really shouldn't matter any more  
 >>than dropping a TCP Ack matters, or not dropping some data segment and  
 >>dropping a different one instead. Yes, there is an effect. The ECN  
 >>loss, or not dropping one data segment and instead dropping a  
 >>different one in Reno/etc, means that *that* packet doesn't trigger a  
 >>cwnd change. If there is one ECN mark/Reno packet loss there is likely  
 >>to be another as the same conditions hold for some period of time, so  
 >>the session that *other* packet is in might adjust cwnd. If there  
 >>isn't an ECN mark on some other packet (if the duration of the  
 >>congestion event was really so short that no other packet was marked)  
 >>one might be justified in asking what the fuss is about. Dropping a  
 >>TCP Ack means that you will skip a small burst (2-3 packets sent in  
 >>response to the Ack) and send one or two larger bursts a little later.
 >>
 >>There is an isolated effect, but I don't think it is a huge one.

 cheers

   jon