Subject: Re: [tcpm] 1323bis - introduction

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 21 Mar 2013 14:47:14 +0000

Hi Andre, Joe,

New text fragment reads:

   The timestamp option may appear in any data or ACK segment, adding 12
   bytes to the 20-byte TCP header.  We believe that the bandwidth saved
   by reducing unnecessary retransmission timeouts will more than pay
   for the extra header bandwidth.  It is required that this TCP option
   will be sent on non-<SYN> segments only after an exchange of options
   on the <SYN> segments has indicated that both sides understand this
   extension.

To your remarks:

>>>     The timestamps option may appear in any data or ACK 
>>>     segment, adding
>>
>> The "*" inserted below is explained further down...
>>
>>>     12 bytes to the 20-byte TCP header. *  It is recommended that
>>>     this TCP
>>
>> Again, IMO recommended should be REQUIRED (in all caps too).
> 
> Is required the correct RFC keyword?  Shouldn't the sentence be rewritten
> to make it use the "MUST" keyword?
> 

This is still section 1, before the RFC2119 disclaimer. This is introductory text, thus I refrained from any ALL CAPS words everywhere in section 1 (except for the 2119 disclaimer, that is the last subsection of section 1).

As mentioned in the comment to the normative section, the actual current 1323 text allows the receiver to start reflecting TSopt as soon as it sees it. Disallowing this would have two effects:

a) certain widely deployed stacks would no longer comply with 1323 (as obsoleted by 1323bis)

b) it would limit further developments regarding the timestamp option that could potentially be sender-side only modifications initially.

Any comments?

Best regards,

Richard Scheffenegger

>>>     option will be sent on non-SYN segments only after an 
>>>     exchange of options on the SYN segments has indicated 
>>>     that both sides understand the extension.
>>
>> The portion below is a bit different:
>>
>>>     We believe that the bandwidth saved by reducing
>>>     unnecessary retransmission timeouts will more than 
>>>     pay for the extra header bandwidth.
>>
>> it talks about the bandwidth of the overall connection; it's not
>> specific to the SYN exchange. It might be useful to move this up to the
>"*" above.
>>
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 21 Mar 2013 16:48:24 +0100

> -----Original Message-----
> New text fragment reads:
> 

Just a quick thought on one of the other sentences: Could we remove the sentence "We believe that the bandwidth saved by reducing unnecessary retransmission timeouts will more than pay for the extra header bandwidth"?

As individual TCPM contributor I have some doubts on that. I don't have experimental data for that trade-off, though.

Michael

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Mar 2013 10:58:13 -0700

Hi, Richard,

>     on the <SYN> segments has indicated that both sides understand this

Reads better, and I agree with its contents.

> This is still section 1, before the RFC2119 disclaimer. This is
> introductory text, thus I refrained from any ALL CAPS words everywhere
> in section 1 (except for the 2119 disclaimer, that is the last
> subsection of section 1).

You might then include the following text which I've been including for 
a while in the 2119 disclaimer:

    When used in lower case, these words have their conventional meaning
    and do not convey the interpretations in RFC-2119.

> As mentioned in the comment to the normative section, the actual
> current 1323 text allows the receiver to start reflecting TSopt as soon
> as it sees it. Disallowing this would have two effects:
>

I'm OK with that ;-)

> b) it would limit further developments regarding the timestamp
> optionthat could potentially be sender-side only modifications initially.

This is yet another reason why this is the correct decision, IMO. TCP 
isn't a protocol where surprises should keep popping up - the whole 
point of the 2WHS is to establish a common understanding of the 
parameters of the protocol for a given connection.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Mar 2013 11:00:04 -0700

> As individual TCPM contributor I have some doubts on that. I don't have experimental data for that trade-off, though.

+1, but the trade-off is worth noting, IMO. Maybe:

---
There is a trade-off between the bandwidth saved by reducing unnecessary 
retransmission timeouts vs. the extra header bandwidth of this option.
---

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 21 Mar 2013 19:10:03 +0100

> >>     bytes to the 20-byte TCP header.  We believe that the 
> bandwidth 
> >> saved
> > Just a quick thought on one of the other sentences: Could 
> we remove the sentence "We believe that the bandwidth saved 
> by reducing unnecessary retransmission timeouts will more 
> than pay for the extra header bandwidth"?
> >
> > As individual TCPM contributor I have some doubts on that. 
> I don't have experimental data for that trade-off, though.
> >
> > Michael
> 
> There is a trade-off between the bandwidth saved by reducing 
> unnecessary retransmission timeouts vs. the extra header 
> bandwidth of this option.
> ---

Good point. I agree.

Michael

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 21 Mar 2013 21:40:11 +0000

Hello Joe,

> You might then include the following text which I've been including for a
> while in the 2119 disclaimer:
> 

I added

   In this document, these words will appear with that interpretation
   only when in UPPER CASE.  Lower case uses of these words are not to
   be interpreted as carrying [RFC2119] significance.

> > current 1323 text allows the receiver to start reflecting TSopt as
> > soon as it sees it. Disallowing this would have two effects:
> >

I knew you would be... :)

Best regards,
  
Richard Scheffenegger