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

[Joe Touch <[e-mail]>]

On 5/31/2013 3:51 AM, Fernando Gont wrote:
> Hi, Richard,
>
> For the most part I've not participated in this discussion at all, but
> at times have lurked a bit... A small comment here:
>
> On 05/30/2013 04:28 PM, Scheffenegger, Richard wrote:
>>
>> My understanding is, that failing the PAWS test should be treated like receiving
>> a segment that is out-of-window. The reason for failing the PAWS test (missing TSopt,
>> or invalid TSval) is secondary, not?
>>
>> Thus an ACK for the last in-sequence segment should be sent.
>>
>>> 1) MAY/SHOULD/MUST send response for missing timestamp
>>
>> This case is not currently covered. As consensus was reached that TSopt should not be allowed to be sent arbitratily for some segments and not for others, I would think a missing timestamp in a segment means, that segment needs to be treated like any other out-of-window segment.
>
> Datapoint: Some OSes accept non-timestamped packets because they've fund
> that some implementations (or maybe sites "protected" by some sort of
> middlebox) at times stop sending timestamps, or include timstamp options
> at their own discretion.
>
> Not that I think that accepting such packets is nice (actually, it
> doesn't look "clean") -- but at the end of the day, you need to
> interoperate with others.

Interoperation has two interpretations:

- accept packets under any circumstances

- accept packets that conform to the requirements of the connection

It's critical to note that accepting non-TSopt packets in a connection 
that has successfully negotiated TSopt effectively defeats PAWS. There's 
no such thing as "just for this packet".

So the key question is:
	
	- should a connection follow the constraints of its
	negotiation, or should being "interoperable" trump
	the entire existence of the PAWS feature?

I don't think so. I.e., being "interoperable" here means "being incorrect".

Joe