Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt

[Joe Touch <[e-mail]>]

On 6/1/2013 9:54 AM, Yuchung Cheng wrote:
> On Sat, Jun 1, 2013 at 6:57 AM, Scheffenegger, Richard <[e-mail]> wrote:
>> Hi Tim,
>>
>> I agree with your reasoning, and think that IF Tsopt was established, under the current semantics, subsequent segments without Tsopt MUST not be accepted.
>>
>> Sending an ACK for the last in-sequence segment MAY be allowed (but a receiver should not keep sending such an ACK excessively - if it would, and the reason for the non-TSopt segments is a path change where TSopt is being stripped, it could result in a permanent exchange of data/ack, without any forward progress... Although the sender would continuously shrink the cwnd, and limit the wasted bandwidth.)
>>
>> Olivier remarked, that sometimes a sender might push out the TSopt in favor of other options (MPTCP, SACK). While I believe that even then a segment should not be accepted, if it lacks TSopt, I was wondering if there is any benefit to be had, to allow a fully in-sequence packet to be accepted then (shinking the acceptance window basically to one particular sequence number).
>>
>> OTOH, the point of SACK is that it being sent during reorder / loss events, so a rule like above wouldn't be all that helpful really...
>>
>> Does anyone know why Linux does accept non TSopt segments at any time?
>
> quoting Olivier
> """
> Dropping segments that do not contain the TSopt is excessive. There
> are on the Internet middleboxes that coalesce or split segments. While
> doing that, they may remove options. Dropping a segment because it
> does not contain the TSopt which is only informative appears overkill
> to me. Dropping a segment that does not contain the negotiated TCP-AO
> option makes sens, but not for the TSopt.
> """
>
> Real implementations need to handle things that purists don't like.

I completely agree. However, what you describe is a middlebox that 
allowed the TSopt in a SYN and then blocked it later.

The middlebox made a decision that broke what the endpoints asked for. 
So whose intentions do we honor?

Given this is the Internet, it seems clear to me that the endpoints are 
in control, and if the middlebox does something that breaks the 
negotiated connection semantics, then it is a real implementation that 
is broken.

If you let the "real implementation" of the middlebox drive the solution 
here, you have just told all the endpoints that PAWS is no longer available.

You cannot have it both ways. There are real implementations at the 
endpoints who care.

Joe