Re: [tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-2140bis-10: (with COMMENT)

[Joseph Touch <[e-mail]>]

Hi, Benjamin,

Thank you for your feedback.

All items below have been incorporated in the upcoming update.

Some notes below to assist tracking.

Joe

> On Mar 25, 2021, at 2:07 AM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-tcpm-2140bis-10: 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 to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to the shepherd for the very helpful writeup!
> 
> Section 3
> 
>   +RTTVAR - variance of round-trip times of a TCP packet exchange
>   [RFC6298]
> 
> nit: in RFC 6298 this is "round-trip time variation", which to me is a more
> useful description, since it is not a standard statistical averaged
> squared deviation.

Agreed.

> Section 6.2
> 
> A forward reference to where the "merge()" operation is discussed would
> be helpful.

Added text when this and other table functions are introduced.

>   During the connection, the associated TCB can be updated based on
>   particular events, as shown below:
> 
> nit(?): should we s/associated TCB/assoicated TCB cache/?  (Likewise for
> §6.2.)

Yes. Clarified in both sec 6 and 7.

> Section 9
> 
>   confirmation, etc.) [RFC3124]. By dealing exclusively with
>   transients, TCB interdependence is more likely to exhibit the same
>   behavior as unmodified, independent TCP connections.
> 
> Is this the "same behavior" in the steady-state?  There seem to be
> obvious (intentional) differences in behavior at startup.

Yes; clarified.

> Section 10
> 
>   The observation that some TCB state is host-pair specific rather
>   than application-pair dependent is not new and is a common
>   engineering decision in layered protocol implementations. Although
>   now deprecated, T/TCP [RFC1644] was the first to propose using
>   caches in order to maintain TCB states (see 0).
> 
> "see 0" feels like a broken automation for referencing Appendix A.
> (Also occurs in Section 11 for the same T/TCP topic.)

Fixed.

> Section 11
> 
> (nit) this feels more like a "changes from RFC 2140" section than an
> "updates to RFC 2140" section, to me.

Yes.

> Appendix B
> 
> A reference to the IANA registry might help the reader make sense of
> some of these option names.

Added.

> Appendix C
> 
>   Temporal sharing, as described earlier in this document, builds on
>   the assumption that multiple consecutive connections between the
>   same host pair are somewhat likely to be exposed to similar
>   environment characteristics. The stored information can therefore
>   become invalid over time, and suitable precautions should be taken
> 
> nit: I don't think the preceding sentence justifies the use of
> "therefore" here.

Fixed.

> Appendix C.2
> 
>   environment, can always use a different value. In specific,
>   information from previous connections, or sets of connections with a
>   similar path, can already be used as context for such decisions (as
>   noted in the core of this document).
> 
> nit: it feels like there might be a missing word here, perhaps
> "situations" after "specific"?  Or perhaps just s/specific/particular/?

The latter seems clearer to me.

> Appendix C.3
> 
>   1. On boot:
> 
>      IW = MaxIW; # assume this is in bytes, and an even number of MSS
> 
> nit: is "even number" intended to mean "integral multiple"?

Actually both; it’s described later as “integer multiple of 2 MSS” to support ACK compression. This is explained here as well.

>   A number of additional constraints need to be imposed if this
>   mechanism is implemented to ensure that it defaults values that
> 
> nit: singular/plural mismatch (maybe "it defaults to values"?)

The latter; fixed.

> Appendix C.4
> 
>   reasons (e.g., the ISN is used in TCP-AO [RFC5925]). The mechanism
>   also benefits from persistent state kept across reboots, as would be
>   other state sharing mechanisms (e.g., TCP Control Block Sharing
>   [RFC2140]). The mechanism is inspired by RFC 2140's use of
>   information across connections.
> 
> It feels strange for some reason to reference RFC 2140 here when this
> document obsoletes RFC 2140.

Agreed. Fixed.