Subject: [tcpm] Comments on draft-ietf-tcpm-1323bis

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 11 Mar 2013 15:06:49 -0400

Hi,

(typing as an individual WG participant)

I read the latest version of 1323bis, and here are a few comments:

* There is some new text in the introduction that says following:
   "A modern TCP
   implementation SHOULD implement and make use of the extensions
   described in this document."
I think this is a bit questionable SHOULD. For window scaling I might say this, but there may be good reasons to not use timestamps always. It is possible to do per-packet RTTM without timestamps (excluding retransmissions, of course), and some implementations might want to spare the option space for something else. So in my opinion, it would be better to leave this sentence out.

* In multiple places the text refers to "new TCP options", but they are not very new anymore. Better to use just "TCP options" or such in these places.

* There is a new section 3.4 on Addressing Window Retraction. This section is a bit hard to understand, particularly steps 1) to 5). Hopefully it would be possible to clarify this section, and why are the different steps needed. Unfortunately I don't have concrete proposals how to do that, but hopefully others do.

* Section 4.3: RTTM measurement => RTT measurement

* I did not check in detail Appendix D: pseudo-code summary, but we should review it carefully for correctness before passing the document forward, so that it does not have inconsistencies with the rest of the text. Another question is, do we actually need the pseudocode in the document?

- Pasi

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 11 Mar 2013 20:36:25 +0000

Hi Pasi,

thanks for reading the Doc!

Hmm... actually, that SHOULD should be a "should", as it's in section 1 before any normative texts. Thanks for spotting, I had missed that. Even if that "should" is too strong, I'd rather leave something with "recommend" in that place...

The "new TCP" is fixed in the upcoming -07 (after the meeting, also contains the updated text section sent around earlier), this was a feedback from Michael too!

The last paragraphs of section 3.4 is based on the relevant text regarding window reduction from RFC1122. That particular text was donated by Matt Mathis IIRC, to make it clear to any implementer, how to code what is described in RFC1122/4.2.2.16...

Section 4.3 title reads "RTTM Mechanism" not "RTTM Measurement" :)

Regarding Pseudocode: One thing missing there is adding relevant receiver code to allow "late" TS enablement. That pseudo-code was added in 2007 in draft-borman-1323bis-00; TSoffset is also not explicitly included in that section.

As acting editor, I don't have any strong feelings regarding that pseudocode section. If the WG feels that the pseudocode (or event processing appendix?) aren't necessary, it can be removed easily; if the consensus is that the optional "TSoffset" and "late TS enablement" should go into the pseudocode, I can add that too.

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: Pasi Sarolahti [mailto:[email-masked]]
> Sent: Montag, 11. März 2013 20:07
> To: Scheffenegger, Richard
> Cc: tcpm
> Subject: Comments on draft-ietf-tcpm-1323bis
> 
> Hi,
> 
> I think this is a bit questionable SHOULD. For window scaling I might say
> this, but there may be good reasons to not use timestamps always. It is
> possible to do per-packet RTTM without timestamps (excluding
> retransmissions, of course), and some implementations might want to spare
> the option space for something else. So in my opinion, it would be better
> to leave this sentence out.
> 
> * In multiple places the text refers to "new TCP options", but they are
> not very new anymore. Better to use just "TCP options" or such in these
> places.
> 
> * There is a new section 3.4 on Addressing Window Retraction. This section
> is a bit hard to understand, particularly steps 1) to 5). Hopefully it
> would be possible to clarify this section, and why are the different steps
> needed. Unfortunately I don't have concrete proposals how to do that, but
> hopefully others do.
> 
> * I did not check in detail Appendix D: pseudo-code summary, but we should
> review it carefully for correctness before passing the document forward,
> so that it does not have inconsistencies with the rest of the text.
> Another question is, do we actually need the pseudocode in the document?
> 
> - Pasi

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 11 Mar 2013 17:16:18 -0400

> Hmm... actually, that SHOULD should be a "should", as it's in section 1 before any normative texts. Thanks for spotting, I had missed that. Even if that "should" is too strong, I'd rather leave som…

ok, "recommended" sounds better.

> The "new TCP" is fixed in the upcoming -07 (after the meeting, also contains the updated text section sent around earlier), this was a feedback from Michael too!

ok

> The last paragraphs of section 3.4 is based on the relevant text regarding window reduction from RFC1122. That particular text was donated by Matt Mathis IIRC, to make it clear to any implementer,…

How about this:

expand/rephrase step 1) a bit: if window has been shrinked due to reception of small segment, the receiver should accept segments that would have been in window prior to window retraction (this is not ideal wording for the document, but trying to rephrase what it says to check that I understand). Should receiver really accept *any* segment that would have been in-window for *any* ACK sent by the server? RFC 1122/4.2.2.16 does not seem to say that (in case some receiver against recommendations would intentionally shrink the window)

step 2) might benefit from explaining more verbosely what exactly is "actual maximum window sequence number". The edge of the actual current buffer at TCP receiver?

Step 3) is clear

Step 4) what sequence number exactly? It might also be useful to have an additional sentence to explain why it is ok/required to ignore receive window in this case

step 5) explain what are "such ACKs". Difficult to associate with the preceding text.

> Section 4.3 title reads "RTTM Mechanism" not "RTTM Measurement" :)

I didn't mean title, but second to last paragraph, where it says "RTTM measurement"

> Regarding Pseudocode: One thing missing there is adding relevant receiver code to allow "late" TS enablement. That pseudo-code was added in 2007 in draft-borman-1323bis-00; TSoffset is also not exp…

Ok, so I was looking at diff between RFC1323 and the latest version of the document. My memory does not cover what has been discussed about this many years ago. If the WG thinks it is fine to include the code, then ok.

> As acting editor, I don't have any strong feelings regarding that pseudocode section. If the WG feels that the pseudocode (or event processing appendix?) aren't necessary, it can be removed easily;…

I'm not concerned about these individual additions. The question was more about whether the pseudocode is needed at all. Personally I don't have strong feelings one way or another, either.

- Pasi

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Mar 2013 14:38:16 -0700

On 3/11/2013 1:36 PM, Scheffenegger, Richard wrote:
> Hmm... actually, that SHOULD should be a "should", as it's in
> section 1 before any normative texts. Thanks for spotting, I had
> missed that. Even if that "should" is too strong, I'd rather leave
> something with "recommend" in that place...

FWIW, these words are sometimes interpreted as meaning the same thing as 
per RFC 2119. If the lowercase is intended to *not* refer as strongly as 
RFC 2119, then Sec 2 might need to be updated to add:

---
    In this document, these words will appear with that interpretation
    only when in ALL CAPS. Lower case uses of these words are not to be
    interpreted as carrying RFC-2119 significance.
---

Joe