Re: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK

Hi, Michio,

On 3/8/2013 2:06 PM, Michio Honda wrote:
> Just a note, we should distinguish middleboxes from buggy endpoints.
> Exchanging options on data packets just confirms that a middlebox does not affect options.
> Preventing from such a buggy endpoint should happen independently, for example, defining a rule like "Returning value of the option MUST differ from the original one".

That works, but it then requires that options include parameters so that 
the return value can vary. TCP is not overall designed to be robust to 
buggy or incorrect implementations, and adding this capability for 
options just encourages wasted space in the SYN and SYN/ACK - precisely 
where we have the least of it available.

Joe

>
> Cheers,
> - Michio
>
> On Mar 8, 2013, at 7:14 PM, Joe Touch wrote:
>
>>
>>
>> On 3/8/2013 10:10 AM, Mark Handley wrote:
>>> On 8 March 2013 15:17, Joe Touch <touch@isi.edu> wrote:
>>>>> What they seem to do is to NOP all the undesired known options and echo
>>>>> the unknown ones in the SYN/ACK.
>>>>
>>>>
>>>> That's easy to debug - it's a major error of their stack, and needs to be
>>>> corrected.
>>>
>>> I think we're all agreed on that.
>>>
>>>> There is no reason to address this in mptcp or any other option.
>>>>
>>>>
>>>>> This shows how important it is that TCP extensions should not only
>>>>> rely on the SYN-SYN/ACK exchange to negotiate support for a new TCP
>>>>> option.
>>>>
>>>>
>>>> I disagree; it shows the impact of an incorrect implementation. "Be generous
>>>> in what you receive" doesn't include this sort of case.
>>>
>>> Unfortunately that's the same reason ECN is still largely undeployed
>>> 15 years on - new functionality really must not cause previously
>>> working things to break, even if other people have done stupid things.
>>>   Otherwise you get condemned in the real world as undeployable and
>>> join the very large stack of other undeployed RFCs.
>>>
>>> MPTCP gets this right, though not for this reason - the same check is
>>> needed for option-stripping middleboxes on the return path to avoid
>>> the server thinking something has been negotiated and the client
>>> thinking it has not.
>>
>> Well, I'd rather not see new TCP options expect to have to have an active challenge-response *solely* to get around this sort of error.
>>
>> Joe
>>
>>
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp
>