Subject: Re: [tcpm] 793bis ready to go?

From: Wesley Eddy <[email-masked]>
Date: Mon, 3 May 2021 22:31:10 -0400

On 2/10/2021 7:14 PM, Yuchung Cheng wrote:
> I think it's ready. Kudos to Wes for the N-years-long effort to put
> this together!
>
> Minor:https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4
>
> The less clear part is the wording of "idle connections". Idleness can
> be interpreted in several ways: no recent rx, tx, or both {on the wire
> | on socket interface}. It'd be good to define more clearly. AFAIK
> implementations have different definitions already leading to
> different KA behaviors.

You're right the definition was only implicit in the text later on, so 
at the beginning of this section I've added:

             A TCP connection is said to be "idle" if for some long
             amount of time there have been no incoming segments 
received and
             there is no new or unacknowledged data to be sent.

How to configure that length of time is dealt with separately later on, 
so I think this should suffice.

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 3 May 2021 22:31:47 -0400

Thank you, I made these clarifications in the latest revision.

On 2/16/2021 9:12 AM, Markku Kojo wrote:
> The CC test looks good. Just two minor things: one editorial and 
> another small addition to address exponential backoff more accurately 
> and correctly. See inline.
>
> On Mon, 8 Feb 2021, Michael Scharf wrote:
>
>> Dear all,
>>
>> draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According 
>> to Wes, all WGLC feedback should be reflected in this version. A link 
>> to a complete diff can be found below.
>>
>> During WGLC, there has been quite some discussion on the exact 
>> wording on congestion control. The suggested text in version -20 is 
>> copied below:
>>
>> 3.7.2.  TCP Congestion Control
>>
>>   RFC 2914 [7] explains the importance of congestion control for the
>>   Internet.
>>
>>   RFC 1122 required implementation of Van Jacobson's congestion control
>>   algorithms slow start with congestion avoidance together with
>
> Here
>
> "SS with CA together with ..."
>
> reads a bit odd to me. But not sure as a non-native speaker. Would it 
> possibly read better if changed to(?):
>
> "algorithms slow start and congestion avoidance together with
>  exponential back-off ..."
>
> OR:
>
>  "algorithms slow start, congestion avoidance, and exponential
>   back-off ..."
>
>>   exponential back-off for successive RTO values for the same segment.
>>   RFC 2581 provided IETF Standards Track description of slow start and
>>   congestion avoidance, along with fast retransmit and fast recovery.
>>   RFC 5681 is the current description of these algorithms and is the
>>   current Standards Track specification providing guidelines for TCP
>>   congestion control.  RFC 6298 describes exponential back-off of RTO
>>   values, including keeping the backed-off value until a subsequent
>>   segment with new data has been sent and acknowledged.
>
> It would be useful to make the last sentence unambiguous as per Karn's 
> original specification:
>
>  "segment with new data has been sent and acknowledged without
>   retransmission."
>
> Thanks,
>
> /Markku
>

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 3 May 2021 22:31:57 -0400

On 2/21/2021 9:33 AM, Scheffenegger, Richard wrote:
> Well, making the transmission of the ACK-only-the-SYN optional when data
> is present, which needs to be ACK'd anyway..
>
> That way, current FBSD and Linux behaviour both would comply with
> 793bis, while I agree with Michael T. that the behavior of FBSD is more
> efficient.

The different behaviors seem important to document, though it wasn't 
clear to me that the WG thread here had converged to a specific change, 
so for now I simply added note of this condition:

    Some TCP implementations suppress sending this segment when the
    received segment contains data that will anyways generate an
    acknowledgement in the later processing steps, saving this separate
    extra acknowledgement of the SYN from being sent.

This is kind of a weak statement, since it doesn't really say whether 
this is "right" or "wrong".  If there is agreement in the WG, then we 
could make a stronger statement.

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 3 May 2021 22:32:03 -0400

On 2/16/2021 3:58 AM, Scharf, Michael wrote:
> I'd also be interested in more details. Unfortunately, I am not familiar with BSD.
>
> For what it is worth, RFC 1122 Section 4.2.3.6 "TCP Keep-Alives" states:
>
>              Keep-alive packets MUST only be sent when no data or
>              acknowledgement packets have been received for the
>              connection within an interval.
>
> So, the latter part of the sentence originates from RFC 1122.
>
> Could somebody comment on whether recent BSD stacks would deviate from the proposed text in 793bis? That would be an important insight!

This is not answering your question about BSD, but just for reference, 
the change in that sentence came from consolidated review comments from 
Microsoft colleagues that was sent to the mailing list:

https://mailarchive.ietf.org/arch/msg/tcpm/rqHhtpqW3m0QikJnaz_4y-y7NyQ/

Section 3.7.4
"Keep-alive packets MUST only be sent when no data or acknowledgement
    packets have been received for the connection within an interval
    (MUST-26).

"

It's important to call out an additional condition - that sends are not already outstanding. When a send is outstanding, it is retransmitted and serves as an implicit liveness check.

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 3 May 2021 22:32:47 -0400

On 2/16/2021 4:40 AM, Jonathan Morton wrote:
>> On 8 Feb, 2021, at 7:00 pm, Scharf, Michael <[email-masked]> wrote:
>>
>>    A TCP endpoint MUST implement the basic congestion control algorithms
>>    slow start, congestion avoidance, and exponential back-off of RTO to
>>    avoid creating congestion collapse conditions (MUST-19).  RFC 5681
>>    and RFC 6298 describe the basic algorithms on the IETF Standards
>>    Track that are broadly applicable.  Multiple other suitable
>>    algorithms exist and have been widely used.  Many TCP implementations
>>    support a set of alternative algorithms that can be configured for
>>    use on the endpoint.  An endpoint may implement such alternative
>>    algorithms provided that the algorithms are conformant with the TCP
>>    specifications from the IETF Standards Track as described in RFC
>>    2914, RFC 5033 [10], and RFC 8961 [15].
> I agree that this is substantially the right approach.  One quibble is that the word "may" is used, but not capitalised and given a corresponding MAY-X entry in Appendix B.  I think it would be appropriate to do so here, in the last sentence above.

ACK.  This is now labelled as "MAY-18".

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 4 May 2021 08:59:08 -0700

On Mon, May 3, 2021 at 7:32 PM Wesley Eddy <[email-masked]> wrote:
> This is not answering your question about BSD, but just for reference, the change in that sentence came from consolidated review comments from Microsoft colleagues that was sent to the mailing list:
>
The latest draft looks good to me to publish. Thanks for the revisions!

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm