Subject: Re: [tcpm] John Scudder's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

From: Wesley Eddy <[email-masked]>
Date: Thu, 6 Jan 2022 16:13:54 -0500

At long last, I've had a chance to go through these comments; thanks for 
your patience.

On 9/22/2021 10:00 PM, John Scudder via Datatracker wrote:
> John Scudder has entered the following ballot position for
> draft-ietf-tcpm-rfc793bis-25: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks very much for this document and all the work that went into it. Thanks
> also for the clear and illuminating shepherd write-up.
>
> Below are some comments I hope will be helpful.
>
> 1. Regarding in §1,
>
>    The purpose of this document is to bring together all of the IETF
>    Standards Track changes that have been made to the base TCP
>    functional specification and unify them into an update of [RFC 793].
>
> It also incorporates Informational documents, right? For example, RFC 6691 is
> Informational, as is 6429. So, these are being elevated, by virtue of their/
> incorporation, to Standards Track. I'm not saying that's a problem, but the
> quoted text, while technically accurate I suppose (it doesn't say "exclusively
> Standards Track changes" after all) is misleading.

You're right.  I've adjusted the sentence in a working copy to become 
the -26 revision to say:

    ... to bring together all of the IETF Standards Track changes and
    other clarifications ...

The "and other clarifications" covers things like 6691 and 6429.

>
> 2. Regarding, in §3.4,
>
>    A new acknowledgment (called an "acceptable ack"), is one for which
>    the inequality below holds:
>
>     SND.UNA < SEG.ACK =< SND.NXT
>
> I’m having a hard time seeing why the first part of the inequality is < and not
> =<. Wouldn’t =< be the case when a single new byte is being acknowledged?
> (Based on the definition that SND.UNA is the “oldest unacknowledged sequence
> number” and therefore, presumably needs to be acknowledged.) I do see this text
> is unchanged from RFC 793 so I am very likely wrong, but I’d appreciate knowing
> WHY I’m wrong…

It's because SEG.ACK is the next value expected to be received and is 
acknowledging the bytes prior to that, so for SND.UNA to be ack'ed, 
SEG.ACK has to be greater than it.

>
> 3. Regarding, in §3.4,
>
>       even if data rates escalate to 10's of megabits/sec. At 100
>       megabits/sec, the cycle time is 5.4 minutes, which may be a little
>       short, but still within reason.
>
> I realize this is, again, inherited from RFC 793 but it seems hopelessly quaint
> in 2021 and not suitable for publication today. I mean, my unexceptional
> commodity home connection is 1 Gbps and it just goes up from there. At 100 Gbps
> we’re down to a cycle time of ~300 msec which no longer seems so easy to brush
> off as "still within reason". I’m not suggesting this document has to fix the
> problem, and indeed I’m aware there are other documents for this purpose — but
> does the outdated text have to be retained?

You're totally correct, in response to this and a similar comment from 
Lars, I added a paragraph to the working copy:

     High performance cases will have shorter cycle times than those in the
     megabits per second that the base TCP design described above considers.
     At 1 Gbps, the cycle time is 34 seconds, only 3 seconds at 10 Gbps, and
     around a third of a second at 100 Gbps.  In these higher 
performance cases,
     TCP Timestamp options and Protection Against Wrapped Sequences 
(PAWS) <xref
     target="RFC7323"/> provide the needed capability to detect and 
discard old
     duplicates.

> 4. The parenthetical reference to “User Telnet” in §3.8.3 seemed equally
> anachronistic. Seems like it could just be removed.

Ack.  Done in working copy.

> 5. It made me sad while reviewing the document, that certain sections were
> stingy with subsection numbering. In particular §3.4 has the unnumbered
> subheadings "Initial Sequence Number Selection", "Knowing When to Keep Quiet",
> and "The TCP Quiet Time Concept", and §3.5 has "Half-Open Connections and Other
> Anomalies", "Reset Generation", and "Reset Processing". I think it would make
> the document more usable if these were numbered, as we tend to do in the modern
> era, and as the rest of the document does do. (I may have missed some, the list
> above isn't necessarily exhaustive.)

Lars made a similar comment, and I've attempted to fix this in the 
working copy.  That was something originally done intentionally to try 
to look as much like 793 as possible (and diffing from 793 directly was 
of interest to the WG early on), but I agree that at this point having 
more traditional and navigable sections is important.

> Nits:
>
> 6. I found it odd that figure 11 uses Z and X as the sequence numbers, whereas
> all the previous illustrations used actual numbers. It works of course, but
> it's inconsistent.

I haven't done anything about this one.

>
> 7. In §3.1:
>
>     The control bits are also know as "flags"
>
>     S/know/known/

Ack.  Fixed in working copy.

> 8. In §3.1, “one’s complement” should be “ones’ complement”.

Ack.  Fixed in working copy.

>
> 9. In §3.3.2:
>
>     transitions are not not explicitly shown
>
>     Presumably the double negation isn’t isn't deliberate. :-)

Ack. Fixed in working copy.

>
> 10. In §3.4:
>
>      next sequence number expected on an incoming segments
>
>      Should be segment, singular.

Ack.  Fixed in working copy.

> 11. In §3.4:
>
>      sequence space occupying controls
>
>      I think this needs, or at least would be better with, a hyphen: “sequence
>      space-occupying controls”

Ack.  Fixed in working copy.

> 12. In several places, "anyways" should probably be "anyway". (At least my
> dictionary suggests the change.)

Ack.  I found 3 copies of this and fixed in my working draft.

> 13. In §3.4:
>
>    Hosts that prefer to avoid waiting are
>    willing to risk possible confusion of old and new packets at a given
>    destination may choose not to wait for the "quiet time".
>
> “Are willing” should be “and are willing”

Ack.  Fixed in working copy.

> 14. In §3.6:
>
>      the user can terminate his side gracefully
>
> Perhaps consider a non-gendered pronoun such as "their"?

Ack.  Fixed in working copy.

> 15. In §3.8.2:
>
>    [RFC 1122] required implementation of Van Jacobson's congestion control
>    algorithms slow start and congestion avoidance together with
>
> Seems as though there’s some punctuation missing. Perhaps “RFC 1122 required
> implementation of Van Jacobson’s congestion control algorithms, slow start, and
> congestion avoidance, together with“?

I think maybe a ":" after "algorithms" would work.

> 16. “Internet” is inconsistently capitalized throughout, probably corresponding
> to age of the text. But I suppose the RFCEd will fix this.

I haven't made any change related to this yet, and am happy to leave it 
to the RFC Editor's judgement.

---

From: John Scudder <[email-masked]>
Date: Thu, 6 Jan 2022 21:59:32 +0000

On Jan 6, 2022, at 4:13 PM, Wesley Eddy <[email-masked]<mailto:[email-masked]>> wrote:

At long last, I've had a chance to go through these comments; thanks for your patience.

Thanks. Your proposed resolutions seem fine to me.

Regards,

—John