Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt

From: [email-masked]
Date: Fri, 04 Oct 2019 08:16:10 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.

        Title           : 0-RTT TCP Convert Protocol
        Authors         : Olivier Bonaventure
                          Mohamed Boucadair
                          Sri Gundavelli
                          SungHoon Seo
                          Benjamin Hesmans
	Filename        : draft-ietf-tcpm-converters-12.txt
	Pages           : 52
	Date            : 2019-10-04

Abstract:
   This document specifies an application proxy, called Transport
   Converter, to assist the deployment of TCP extensions such as
   Multipath TCP.  This proxy is designed to avoid inducing extra delay
   when involved in a network-assisted connection (that is, 0-RTT).

   This specification assumes an explicit model, where the proxy is
   explicitly configured on hosts.

   -- Editorial Note (To be removed by RFC Editor)

   Please update these statements with the RFC number to be assigned to
   this document: [This-RFC]

   Please update TBA statements with the port number to be assigned to
   the 0-RTT TCP Convert Protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-converters-12
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Fri, 4 Oct 2019 15:19:46 +0000

Hi Phil, Michael, 

This version implements the suggestions discussed so far: add a new section to discuss data processing once a state is created + appendix to discuss address sharing/preservation modes. 

I think this version solves the concerns raised by Phil. 

Looking forward to advance the document. 

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[email-masked]] De la part de internet-
> [email-masked]
> Envoyé : vendredi 4 octobre 2019 17:16
> À : [email-masked]
> Cc : [email-masked]
> Objet : [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: <[email-masked]>
Date: Mon, 21 Oct 2019 13:10:04 +0000

Med,
Thanks for creating these new pieces of text, I think they're helpful and it's looking good!

Comments:
Section 3.3
<<User data is unambiguously distinguished from Convert TLVs by a Transport Converter owing to the Total Length field in the Convert messages>>
Better:
User data is unambiguously distinguished from Convert TLVs by a Transport Converter by the Convert Fixed Header (Figure 12) in the Convert messages

In Section 3.3, I think you should move the text about MPTCP out of S3.3 (into S3.4, maybe with some renumbering of S3.4 & 3.5 to make a section about mptcp)
[this is the text "Note that for the Multipath TCP case..." to the Figure 8 caption and the bullet "In reference to Figure 8"]
Reason: handle the general case first, then the MPTCP variant. 

<< Note that for the Multipath TCP case, the Transport Converter identifies an MPTCP connection by means, e.g., of the token assigned to the MPTCP connection.>>
If I get it right, this is nothing to do with the token defined in MPTCP, but is simply an identifier internal to the Converter (to help it keep together entries for the same Client). Ie this token is not seen on the wire. Please could you re-phrase the para and the definition of "token" in the Figure 8 caption. 

Section 4.1
In the Figure 12 caption, I suggest deleting "-Sized" (so: "Figure 12: The Fixed Header of the Convert Protocol" or even "Figure 12: The Convert Fixed Header")

Section D.2
Appendix D.1 has a final paragraph which doesn't appear at the end of D.2 (<<The Transport Converter must be on the forwarding path of incoming traffic.>>)
I assume the same text is true for the IPv4 address sharing model. I suggest adding a comment at the end of D.2 that the same considerations apply (or repeating the paragraph, possibly with "IP address" changed to "IP address prefix")
I also suggest changing the title "IPv4 Address Sharing" to "Address Sharing"

Best wishes,
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 04 October 2019 16:20
To: Eardley,PL,Philip,TUD1 R <[email-masked]>; Scharf, Michael ([email-masked]) <[email-masked]>
Cc: [email-masked]
Subject: RE: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt

Hi Phil, Michael, 

Cheers,
Med

> [email-masked] Envoyé : vendredi 4 octobre 2019 17:16 À : 
> [email-masked] Cc : [email-masked] Objet : [tcpm] I-D Action: 
> draft-ietf-tcpm-converters-12.txt
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>

---

From: <[email-masked]>
Date: Mon, 21 Oct 2019 13:59:34 +0000

Hi Phil,

Thank you for double checking. 

Please see inline. 

Cheers,
Med

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : lundi 21 octobre 2019 15:10
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Cc : [email-masked]
> Objet : RE: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt
> 
> Med,
> <<User data is unambiguously distinguished from Convert TLVs by a Transport
> Converter owing to the Total Length field in the Convert messages>>
> Better:
> User data is unambiguously distinguished from Convert TLVs by a Transport
> Converter by the Convert Fixed Header (Figure 12) in the Convert messages
> 

[Med] The OLD wording insisted on the importance of Total Length field to disambiguate TLVs when user data is also present, but OK to change as follows if you think this is better:  

User data is unambiguously distinguished from Convert TLVs by
a Transport Converter owing to the Convert Fixed Header in the
Convert messages (Section 4.1).

> In Section 3.3, I think you should move the text about MPTCP out of S3.3
> (into S3.4, maybe with some renumbering of S3.4 & 3.5 to make a section
> about mptcp)
> [this is the text "Note that for the Multipath TCP case..." to the Figure 8
> caption and the bullet "In reference to Figure 8"]

[Med] No problem to rearrange the text if you think that is better. 

> 
> << Note that for the Multipath TCP case, the Transport Converter identifies
> an MPTCP connection by means, e.g., of the token assigned to the MPTCP
> connection.>>
> If I get it right, this is nothing to do with the token defined in MPTCP,

[Med] ", e.g., of the token assigned to the MPTCP connection." refers to the token defined in MPTCP: 

   Token:  A locally unique identifier given to a multipath connection
      by a host.  May also be referred to as a "Connection ID".

Any issue with that?

> but is simply an identifier internal to the Converter (to help it keep
> together entries for the same Client). Ie this token is not seen on the
> wire. Please could you re-phrase the para and the definition of "token" in
> the Figure 8 caption.
> 
> Section 4.1
> In the Figure 12 caption, I suggest deleting "-Sized" (so: "Figure 12: The
> Fixed Header of the Convert Protocol" or even "Figure 12: The Convert Fixed
> Header")

[Med] OK, changed to "Figure 12: The Convert Fixed Header)".

> 
> Section D.2
> Appendix D.1 has a final paragraph which doesn't appear at the end of D.2
> (<<The Transport Converter must be on the forwarding path of incoming
> traffic.>>)

[Med] D2.2 has already the following text: 

   Adequate forwarding policies are enforced so that traffic destined to
   an address of such pool is intercepted by the appropriate Transport
   Converter.

> I assume the same text is true for the IPv4 address sharing model. I
> suggest adding a comment at the end of D.2 that the same considerations
> apply (or repeating the paragraph, possibly with "IP address" changed to
> "IP address prefix")

[Med] Changed the title to "Address/Prefix Sharing" to cover both IPv4 and IPv6.

Thank you.

> To: Eardley,PL,Philip,TUD1 R <[email-masked]>; Scharf, Michael
> ([email-masked]) <[email-masked]>
> Cc: [email-masked]
> This version implements the suggestions discussed so far: add a new section
> to discuss data processing once a state is created + appendix to discuss
> address sharing/preservation modes.
>

---

From: <[email-masked]>
Date: Tue, 22 Oct 2019 10:25:51 +0000

Tiny follow-ups below.

Thanks for your efforts on this, I think we're done
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 21 October 2019 15:00
To: Eardley,PL,Philip,TUD1 R <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt

Hi Phil,

Please see inline. 

Cheers,
Med

> De : [email-masked] [mailto:[email-masked]] Envoyé : 
> lundi 21 octobre 2019 15:10 À : BOUCADAIR Mohamed TGI/OLN; 
> [email-masked] Cc : [email-masked] Objet : RE: [tcpm] 
> I-D Action: draft-ietf-tcpm-converters-12.txt
> 

[phil] thanks, yes I think that would definitely be better. 

Any issue with that?

[phil]
Thanks for the pointer. 

I wonder if the following would be better (instead of the "Note that for the Multipath TCP case..." paragraph above Figure 8). I'll leave it to you to decide. 

Note that for the Multipath TCP (MPTCP) case, a connection between the Client and Transport Converter has multiple subflows (each with a different IP address and/or port). In the MPTCP specification [ref], at each host an MPTCP connection is identified by a token (a one-way hash of the MPTCP key). An implementation example of a MPTCP transport session entry maintained by a Transport Converter is shown in Figure 7. The entry needs to be updated whenever subflows are added to, or deleted from, the MPTCP connection. As a reminder, the Convert TLVs are only exchanged during the establishment of the initial subflow.

> Section D.2
> Appendix D.1 has a final paragraph which doesn't appear at the end of 
> D.2 (<<The Transport Converter must be on the forwarding path of 
> incoming
> traffic.>>)

[phil] I missed that, thanks. 
In the sentence after the one you quote
<< Unlike Appendix D.1, the Transport Converter drops
   incoming packets which do match an active transport session entry.>>

I assume it should be: "which do not match"

---

From: <[email-masked]>
Date: Tue, 22 Oct 2019 12:09:50 +0000

Hi Phil, 

Great! Thanks. 

I submitted a new version which fixes the nits + rearranged text.  

Cheers,
Med

> Envoyé : mardi 22 octobre 2019 12:26
> I wonder if the following would be better (instead of the "Note that for
> the Multipath TCP case..." paragraph above Figure 8). I'll leave it to you
> to decide.
> 
> Note that for the Multipath TCP (MPTCP) case, a connection between the
> Client and Transport Converter has multiple subflows (each with a different
> IP address and/or port). In the MPTCP specification [ref], at each host an
> MPTCP connection is identified by a token (a one-way hash of the MPTCP
> key). An implementation example of a MPTCP transport session entry
> maintained by a Transport Converter is shown in Figure 7. The entry needs
> to be updated whenever subflows are added to, or deleted from, the MPTCP
> connection. As a reminder, the Convert TLVs are only exchanged during the
> establishment of the initial subflow.
> 
> 
> > Section D.2