Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt

[Joe Touch <[e-mail]>]

On 5/5/2014 9:04 AM, Costin Raiciu wrote:
>> A middlebox that examines the contents of TCP traffic - or worse, modifies it - needs to follow all of RFC1122 host requirements. It's interpreting content - if it sees a SYN with an unknown option, it ought to have removed it or dropped the SYN.
>>
>> If it doesn't, you have a device that is broken and needs to be
>> replaced.
>>
>> We should design TCP to be liberal in what it accepts, but no
>> Internet protocol should be designed to overcome deliberate
>> implementation errors.
>>
> As much as I agree with this purist view of the Internet, I also
> believe it is unworkable if we want stuff deployed.
>
> Say we actually stuck to the plan and designed EDO for a world with
> reasonable middleboxes. Then we implement it in Linux, then we turn it
> on by default. Then, all of a sudden the Internet stops working, and you
> have disgruntled users cursing Linux right and left....

Linux already runs lots of things we didn't approve, and never seems to 
take any blame. I don't see avoiding Linux user ire as a viable approach.

> Trouble is, for middleboxes to change you need to have a working
> protocol (that is maybe suboptimal) and a strong need for the change,
> and push from OS/app vendors etc.

For middleboxes to change, they have to start breaking things. As long 
as we adapt to the errors they make, we're helping create their market.

I agree with your overall point that we do need to consider how/whether 
this can avoid being held hostage by middleboxes, and a *temporary* 
header checksum might be a way.

But ultimately, that still means the new option will not work through 
middleboxes, and lots of people will not consider that the fault of the 
middlebox.

Joe