Subject: Re: [tcpm] draft-ietf-tcpm-2140bis-01

From: Michael Welzl <[email-masked]>
Date: Sat, 29 Feb 2020 23:59:05 +0100

Hi Michael,

We have now addressed your comments (please see below).

> Begin forwarded message:
> 
> From: "Scharf, Michael" <[email-masked] <mailto:[email-masked]>>
> Subject: draft-ietf-tcpm-2140bis-01
> Date: 30 January 2020 at 01:28:50 CET
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, tcpm IETF list <[email-masked] <mailto:[email-masked]>>
> Resent-From: <[email-masked] <mailto:[email-masked]>>
> Resent-To: <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>
> 
> Hi,
>  
> I have read the most recent version of 2140bis. As usually, my comments are posted with chair hat off.
>  
> I encourage others to also read the document.
>  
> Issues / comments:
>  
> The document structure follows in many cases exactly RFC 2140, even if content has changed. In some cases, this confuses me. For instance, the Section „An Ensample of Temporal Sharing“ in RFC 2140 indeed contained an implementation example. Section 6 of RFC 2140bis is generic. This raises at least two questions für Section 6 and similarly for Section 7:
> Is the title for the section still appropriate?

Good catch, thanks! It isn't. Fixed it to "Temporal Sharing" (and "Ensemble Sharing" in case of Section 7).

> Is some additional explanation needed e.g. on page 6 that an implementation can decide to implement only subsets of the table on page 6, as an early heads-up?

We don't make a recommendations for implementers but just present the possibilities with their pro's and con's; hence the text points at sections 8 and 9 for compatibility issues and implications of sharing the information. Thus, we believe that's the most appropriate type of "early heads-up".

> Sections 6, 7, 8, 9 and 10 are longer than the original 2140. I wonder if subsections would be useful to better structure them. At least I find some of the long text blocks hard to read and it is not always apparent how a given paragraph fits into the overall storyline. I suspect that the document would be easier to parse with some more structuring (e.g., subsections).

We inserted sub-headings in Sections 6, 7, 8 and 9. This was great advice indeed! This should be much clearer now, especially sections 6 and 7.

> The internal structure of Section 8 is hard to understand. For instance, ECMP and LAG are discussed twice. Also, this section discusses quite a number of different aspects, including fairness, challenges with ECMP/LAG, interactions with fast recovery and NAT. I suggest to either add early an explanation what is meant by „compatibility“, or to use sub-sections to make clear what topics are in scope (see above).

We have re-organized the text here a bit, removing a redundant statement about ECMP and LAG, and inserted sub-headings in Section 8.

> The separation of topics between Section 8 and 9 is not fully clear to me (different to RFC 2140 – prior to deployment these sections had a relatively clear meaning). For instance, both sections discuss traffic with possibly short flows (e.g., http). I think the existing content could be reorganized by copy&paste in sections with a well-defined focus. Example section titles could be:
> Fairness issues
> Impact on applications and performance
> Interactions with network mechanism
> Discussion of design aspects and alternatives
> … (or other terms – I just post this list to illustrate that alternatives could exist)

8 are issues local to the TCB sharing function; 9 are interactions with other architecture and protocol issues. Although the sum of the two sections could be completely revised, we don't currently see a benefit.

> The table on page 15 is a bit dated. I hope that we could update that, say, during a WGLC

We believe that the best approach is to copy+paste this table into an email and send it to the mailing list for checking. We'll do this.

> Section 12: I am not sure if I fully understand the attack vectors section. For instance, how would an attack like „an application can open a connection and set its window size to zero, denying service to any other subsequent connection between those hosts.“ work if the receive window is not shared?

We agree, this was wrong; we removed this line.

> In addition, I wonder if privacy needs to be discussed, e.g., whether user tracking or fingerprinting is possible by the methods discussed in the document.

Added a paragraph to the security section addressing this. We believe the mixing mitigates the effect of reuse.

> Section 14: I would classify more references as „normative“ (e.g., RFC 793)

Done (RFC 793, 1122, the PMTUD RFCs and the TFO RFC)

> Appendix C.3: I really wonder why not to specify the algorithm with (optional) persistence across reboots

Because it's the same as temporal sharing, just with different averaging and information decay.

>  
> Editorial nits:
>  
> Please ensure that capitalization of all headlines is consistent (e.g., title of Apendix A)

Done

> Same for all table captions (e.g., caption „Option info“)

Done.

> Section 2: I am not sure about this wording: s/permitted by TCP implementers/permitted by TCP standards/ ???

Done (replaced as you suggest).

> In the table on Section 5, „round-trip time and variance“ appears twice, is this a bug or a feature? (Same as in RFC 2140)

It's a bug. Removed.

> Page 7 refers to Appendix B. If that appendix shall indeed be removed prior to publication, that reference also needs to be removed. Maybe that sentence should be flagged for removal, too?!

Done.

> On page 7 and 8, I believe that the position of the tables could be rearranged so that they are not rendered back-to-back. Both tables seem partly unrelated and the current position may be a bit confusing. Same issue later on page 10. (Alternatively, the tables could be numbered to make clear that they are separate.)

Fixed: the tables are now clearer due to the new subheadings.

> On page 8, the order of the entries in the table and the order of their explanation is not well aligned. This may be a matter of personal taste, but I would expect a somewhat similar order.

Fixed.

> Page 8/9: „The method for merging old and current values needs to attempt to reduce the transient for new connections.“ I am not sure if I fully understand what is meant by this (albeit I suspect a certain meaning).

Clarified.

> Page 9: The table in the upper part of the page is not explained. I think it would make sense to have at least one sentence to introduce it.

This is fixed by the newly introduced subheadings which clarify that some tables are for initialization and some for cache updates.

> Page 11: The position of the table confuses me.

Fixed.

Best Regards,
Joe, Michael and Safiqul