Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-25.txt

[Greg Skinner <[e-mail]>]

I hope these changes are not too late.  Some things I’ve been looking into recently could be applicable to this draft.

Included below is a context diff of -25 and three changes:
adjustment of an expression in §3.7.1 to make it compatible with a similar expression in the same sentence
addition of a citation and supporting text in §3.8.1
a spelling correction in §3.8.6.3

Some notes about the changes:
The citation was for IEN177.  I couldn’t find a template for an IEN, so I had to roll my own.
Long story short —  looking at some mailing list discussions about Internet congestion during the 1980s eventually brought me to Dave Mills’ Internet Delay Experiments study, RFC889.  In the study, he expressed concern about the alpha and beta parameters of the (RFC793) TCP algorithm, made some changes, and took some measurements.  I wondered where the original parameters came from, especially since they were not cited in RFC793.  Further investigation led me to IEN177.
The subject matter of RFC889 may warrant it being obsoleted and its status changed to Historic.  There has recently been some concern about changing the status of pre-IETF documents <https://mailarchive.ietf.org/arch/msg/last-call/ZLhdZge4iRrpmgVSZdXI7EVeFow/> until the new RFC Editor model  is in place.  If there is any pushback about changing RFC889’s status, I hope these changes can still be incorporated.
Incidentally, RFC879 was obsoleted by RFC7805.

Regards, Greg

----

*** draft-ietf-tcpm-rfc793bis-25.xml	2022-01-24 15:17:04.000000000 -0800
--- draft-ietf-tcpm-rfc793bis-25.xml+	2022-01-24 18:05:42.000000000 -0800
***************
*** 1842,1848 ****
      </t>
      <t>
      If an MSS option is not received at connection setup, TCP implementations
!     MUST assume a default send MSS of 536 (576-40) for IPv4 or 1220 (1280 - 60) for IPv6 (MUST-15).
      </t>
      <t>
      The maximum size of a segment that TCP endpoint really sends, the
--- 1842,1848 ----
      </t>
      <t>
      If an MSS option is not received at connection setup, TCP implementations
!     MUST assume a default send MSS of 536 (576 - 40) for IPv4 or 1220 (1280 - 60) for IPv6 (MUST-15).
      </t>
      <t>
      The maximum size of a segment that TCP endpoint really sends, the
***************
*** 1996,2002 ****
        algorithm in <xref target="RFC6298"/>, including Karn's algorithm for taking RTT samples (MUST-18).
  </t>
  <t>
!       RFC 793 contains an early example procedure for computing the RTO.  This was then replaced by the algorithm described in RFC 1122, and subsequently updated in RFC 2988, and then again in RFC 6298.
  </t>
  <t>
  RFC 1122 allows that if a retransmitted packet is identical to the original
--- 1996,2002 ----
        algorithm in <xref target="RFC6298"/>, including Karn's algorithm for taking RTT samples (MUST-18).
  </t>
  <t>
!       RFC 793 contains an early example procedure for computing the RTO, based on TCP performance measurements done by the Royal Signals and Radar Establishment (RSRE) <xref target="IEN177"/>.  This was then replaced by the algorithm described in RFC 1122, and subsequently updated in RFC 2988, and then again in RFC 6298.
  </t>
  <t>
  RFC 1122 allows that if a retransmitted packet is identical to the original
***************
*** 2433,2439 ****
  	    (SHLD-19). Excessive delays on ACKs can disturb the round-trip
  	    timing and packet &quot;clocking&quot; algorithms.  More complete
  	    discussion of delayed ACK behavior is in Section 4.2 of RFC 5681
! 	    <xref target="RFC5681"/>, including recomendations to immediately
  	    acknowledge out-of-order segments, segments above a gap in sequence
  	    space, or segments that fill all or part of a gap, in order to
  	    accelerate loss recovery.
--- 2433,2439 ----
  	    (SHLD-19). Excessive delays on ACKs can disturb the round-trip
  	    timing and packet &quot;clocking&quot; algorithms.  More complete
  	    discussion of delayed ACK behavior is in Section 4.2 of RFC 5681
! 	    <xref target="RFC5681"/>, including recommendations to immediately
  	    acknowledge out-of-order segments, segments above a gap in sequence
  	    space, or segments that fill all or part of a gap, in order to
  	    accelerate loss recovery.
***************
*** 5066,5071 ****
--- 5066,5081 ----
              </front>
              <seriesInfo name="Proceedings of IEEE INFOCOM" value="pp. 1573-1583"/>
          </reference>
+ 
+ 	<reference
+ 	    anchor="IEN177" target="https://www.rfc-editor.org/ien/ien177.txt">
+ 	    <front>
+ 		<title>Comments on Action Items from the January Meeting</title>
+ 		<author initials = "J" surname="Postel"></author>
+ 		<date year="1981" month="March" />
+ 	    </front>
+ 	    <seriesInfo name="IEN" value="177"/>
+ 	</reference>
  
      </references>
      <section title="Other Implementation Notes">