[Iccrg] Re: [tcpm] ECN feedback discussion

[Michael Welzl]

On Nov 8, 2012, at 2:50 PM, Steve Bauer wrote:

>> To have a better basis for such a decision, it could be useful to  
>> look at some data from the backbone, or from popular servers, on  
>> how many packets arrive with ECT0 or ECT1 set.
>
> In our IMC 2011 paper,
>
> Measuring the State of ECN Readiness in Servers, Clients, and Routers
> http://rbeverly.net/research/papers/ecn-imc11.pdf
>
> We reported that "Across all of our data sets, we see no instances of
> ECN nonce support. Manual inspection of arriving packets with ECT1 set
> reveals that these flows always set ECT1, even when ECN is not
> negotiated by TCP."

I have read this paper, and also had it open while I wrote my previous  
email  :-)   but I managed to miss that statement.


> So any packets with ECT1 set are evidence of something broken along  
> the path.

Well... up to now, it is. I don't see how what you describe would  
limit us to not have a sender set ECT1?
It would break the nonce interpretation though. Tricky. But should we  
design for such equipment faults? A quick look at your paper doesn't  
reveal how often you saw that; maybe I'm missing it again...

Another thought: in my previous email, addressing Richard, I wrote:
"Yes this leads to unexpected behavior for current ECN-capable end  
systems, but given that nobody (except for you!  :-)))   )   uses ECN,  
maybe we can just update that behavior and not worry about this  
problem much?"

- this made me think: Richard would certainly not run an old kernel.
=> given that ECN is probably not on by default in any system, isn't  
it fair to assume that folks who'd turn it on would run an up-to-date  
system?

Sure, lots of assumptions, but we're talking of blowing life into a  
dead corpse here! You can't do that without doing ugly stuff, such as  
having a zombie bite it...

Cheers,
Michael