[tcpm] RFC793bis AD review

Martin Duke <martin.h.duke@gmail.com> Thu, 24 June 2021 20:12 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3AC873A29B0; Thu, 24 Jun 2021 13:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zkwW-C3cDHdI; Thu, 24 Jun 2021 13:12:22 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D0F3A29AC; Thu, 24 Jun 2021 13:12:22 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id h2so9805865iob.11; Thu, 24 Jun 2021 13:12:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JuyglivXDBdPy9XKqTc4rCF+wknMzxB79nypTTXLKgA=; b=fPEx2FYwk5BQLKn0HT95LJy3QOlxpShkaXLuLrPv5Wqi3JbD0GcQQ6hC0ifyjaw6DG jEbXkrgQ3n+X4+3IdXEKdOhtekV4HttK+6wbz7bMPFn6xTKEgu9Iw3V8/S8f0hRH7Mzf ZWJhdi7rcuw49UDTdkzUiAflsgWl0Sy/bmglHerg0hRnoxACfNNXcAZR6DRyb0wM/V+w RQYZpxo6qbGVjDHLzJerha5KAfDCICZqX2tvjzm16y0a2ensR/AIqJ/EloE/Y+epMviV 3WSI9ydJIqiMZZKjViJi8MpUlP5AKSF/JOWmmbZ9daJ3HKZHe/j/7Nz/vbLTTaxNO/e7 5WqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JuyglivXDBdPy9XKqTc4rCF+wknMzxB79nypTTXLKgA=; b=DbNzJD06F2uXAWtWxhEGhTaRwe+fvAoKncBOIu6b+wvzhUkF6RJxzYt94uaW9aAmwc feG8vZ+dPguN60tyjIXi5NhiSXpvvM6xIb0giMsOueMh2+ekTiGkqbT9ydvOUCIooHOp sJSNkKXkkIbOV584e+2ymPPX74Ce2ZfAZnYM3Sg5Z28sg+CNT0RTYDw1dOYLvDMmfYp6 xTeJvlXC/9QFSh2wIRzrE28z/W8E0SiC9rTLfr7LTA08YwX7phsMOjicBWkw2nU9EVNv KlOv4DstqxkKXeFkT1N/LBqsxTeA5RpK9XTArOM4cdgiX6TpYSN5cijS5vqOTGg16dRD LZ+A==
X-Gm-Message-State: AOAM533MvYSI4l51waqxKekFygh3CqASwv3WU63QKP/3/wbkyU6oV7sP wi6N38CPTWwVKQOD/S0r8lP1KzUoHOCDpWUS1ho6DzY2SbI=
X-Google-Smtp-Source: ABdhPJx5BVmDKu7PXDfvblACqUk7wG7HxoqiGUtxpLEOgxYlfl3QDeLFSe5RKOFMS6W9tQ8tTQo3ozRKElz9ZlT2yTw=
X-Received: by 2002:a05:6602:2595:: with SMTP id p21mr5575386ioo.51.1624565540859; Thu, 24 Jun 2021 13:12:20 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 24 Jun 2021 13:12:09 -0700
Message-ID: <CAM4esxQggOyqpO4RhE151En2mATce8jL0s4dt6CEeqEAqaXkQw@mail.gmail.com>
To: draft-ietf-tcpm-rfc793bis.all@ietf.org, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fa32df05c588a341"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/9Lzd5fgi7_YyGsc6nmapp5oBAuY>
Subject: [tcpm] RFC793bis AD review
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jun 2021 20:12:27 -0000

First of all -- wow. Thanks for your efforts on this historic document.

After a detailed reading, I have a number of minor comments that should be
addressed before IETF Last Call, and a bunch of nits.

As always, these AD review comments should be viewed as the start of
discussion rather than a series of demands. If I'm off base, please say so!


(Document Header) Please update the Intended Status to "Internet Standard".

(3.8.3) R1 and R2 can be measured in retransmissions or seconds; the
proposed bounds are in retransmissions for R1 and seconds for R2. So if I
have a time-based R1, should that be 3? If I have a retransmission based
R2, should I compare that to the value of RTO somehow?

(3.8.5)  This section is unclear as to whether the sender can cause the
Urgent Pointer to recede (move to the left), and if so, if that MUST be
reported to the application like a pointer advance.


The sending TCP peer must be prepared to accept from the user and
   send at least one octet of new data even if the send window is zero.
   The sending TCP peer must regularly retransmit to the receiving TCP
   peer even when the window is zero

Please clarify that these probes only happen when there is new data, if
that's the intent.

( the first paragraph says

Two minutes is recommended for the retransmission interval when the
   window is zero.

but the last one says

The transmitting host SHOULD send the first zero-window probe when a
   zero window has existed for the retransmission timeout period (SHLD-
   29) (Section 3.8.1
and SHOULD increase exponentially the interval
   between successive probes (SHLD-30).

so is it 2 min or the RTO?

( If I read this algorithm correctly, an un-pushed send
buffer of < MSS, if D < Fs*Max(SND.WND), will sit there indefinitely
being transmitted; is this intentional?

(3.8.2) and ( Should RFC 5681 be a normative reference, given the
congestion control requirement? If not, ( shouldn't require the
reader to go there to fully implement delayed ACKs. I suggest

s/an ACK for at least every second segment/an ACK for least every 2*MSS
bytes of data

to fully state what is in 5681.

(3.10) I understand the desire to conform to RFC 793 formatting, but this
section is very long and has quite a bit of hierarchy. Some subsections
would be very helpful for some needed cross-referencing, as described in
the nits.


If active and the remote socket is specified, then change the
         connection from passive to active,

I think you mean "If passive"?

(3.10, SEGMENT ARRIVES/LISTEN) Step 4 mentions RST but those have already
been handled in Step 1.


(3.1, data offset section) s/integral number/integer multiple

(3.1, URG and ACK) s/field significant/field is significant

(3.1, Window) It would be useful to observe here that RFC 7323 can change
the meaning of this field.

(3.1, Options) "

   Options: [TCP Option]; Options#Size == (DOffset-5)*32; present only
   when DOffset > 5.

What is this notation?

(3.4)  s/l0/10 (switch letter L with numeral 1)

(3.7.2) In the first paragraph it says

RFC 1122 <https://datatracker.ietf.org/doc/html/rfc1122> recommends an
IP-layer default
   effective MTU of less than or equal to 576 for destinations not
   directly connected

In the last it says

RFC 1191 <https://datatracker.ietf.org/doc/html/rfc1191> discusses
this implication of many older TCP
   implementations setting MSS to 536 for non-local destinations, rather
   than deriving it from the MTUs of connected interfaces as

Could we unify these comments in the same location? Implementers browsing
the spec should see the old recommendation and its drawback in the same

(3.8) "push function" should include a reference to Section 3.9.1.

(3.8.2) s/endpoint may implement/endpoint MAY implement

( s/min(D.U)/min(D,U)

( Is "> a stray mark, or does it mean something?

(3.10) s/and it the segment/and the segment

(3.10, RECEIVE/CLOSE_WAIT) s/text/data

(3.10, SEGMENT ARRIVES/LISTEN) s/text/data

(3.10, SEGMENT ARRIVES/SYN_SENT) Step 4 directs the reader to the "sixth
step below" but the algorithm has only 5 steps! IIUC it is referring to
step 6 of the "other states" procedure, which is several pages later. This
needs to be clearer! (and is where having subsections would be helpful).

(3.11) There are redundant definitions of "Type of Service" and "TOS"