Subject: Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converters-09?

From: <[email-masked]>
Date: Wed, 31 Jul 2019 10:26:16 +0000

I think most of my comments are addressed. Here are some things I think could still be clarified, plus a couple of extra questions that occurred to me when I was checking the latest version.

Section 3.1
<<Nevertheless, and unless this is explicitly stated,  the description assumes outgoing connections as default.>>

This sentence seems to contradict itself (can something be both assumed and have to be explicitly stated?). Maybe:-
In general this document assumes that the client initiates the connection (in other words, it is an outgoing connection); the scenario with an incoming connection is discussed in a couple of places [references]. 

In Figure 1 I find the 'upstream' and 'downstream' labels a bit confusing (especially as the lines have arrowheads in both directions), and it is shown as the link between client and converter etc. I think it would be better to move lower down (ie separate from the actual link), something like:
-------> upstream direction (outgoing connections)
<------ downstream direction (incoming connections)

Figure 5 caption has a stray "(1)" that can be deleted

Above Figure 6
<<addresses and, eventually, the destination IP address and port number"
I think ", eventually," should be deleted. 

Section 3.2 / 3.3
There are two paragraphs at the end of 3.2 and a bit more in 3.3 discussing what happens when a connection ends with FIN and TCP RST etc. I think you should write a bit more about the MPTCP case - since there are subflow TCP RST and MP_FASTCLOSE cases to consider. A TCP RST on one MPTCP subflow presumably shouldn't trigger the Converter to close the TCP connection on its other interface. 

Section 4 intro

<< This section describes the messages that are exchanged between a
   Client and a Transport Converter.

   By default, the Transport Converter listens on TCP port number TBA
   for Convert protocol (Convert, for short) messages from Clients.

   Clients send packets that are eligible to the conversion service to
   the provisioned Transport Converter using TBA as destination port
   number.  Additional information is supplied by Clients to the
   Transport Converter by means of Convert messages as detailed in the
   following sub-sections.

   Convert messages may appear only in a SYN, SYN+ACK, or ACK.

   Convert messages MUST be included as the first bytes of the
   bytestream.  A Convert message starts with a 32 bits long fixed
   header (Section 4.1) followed by one or more Convert TLVs (Type,
   Length, Value) (Section 4.2).

Some comments:
The Client also listens on TCP port TBA (not just the converter)
Stress that ALL convert msgs start with the same header.
I think the "Clients send packets..." para is better re-arranged.

Question: there seems to be a contradiction. The text here says "Convert messages may appear only in syn, syn-ack, ack". But then in S3.2 it says "This information is sent at the beginning of the bytestream, either directly in the SYN+ACK or in a subsequent packet." (this information is "about the TCP options that were negotiated with the Server.") (Incidentally, in S3.2 essentially the same sentence is repeated two sentences later.)  is the idea that SYN / syn-ack /ack is the 'normal' case, but can be in later pkts?

Question: the text says "Clients send packets that are eligible to the conversion service to the provisioned Transport Converter using TBA as destination port number." Is this referring to the exchange of Convert protocol messages? Or is this referring to subsequent data that is actually sent to the TBA port number? I think the text implies the latter, which I assume is not correct. 

Suggested text:-

<<
   This section defines the Convert protocol (Convert, for short) messages that are exchanged between a Client and a Transport Converter.

   Convert messages MUST be sent to TCP destination port TBA. Therefore, a Transport Converter and a Client listen on this TCP port for Convert messages.
   Convert messages MAY appear in a SYN, SYN+ACK, or ACK or MAY appear in a subsequent packet.
Convert messages MUST be included as the first bytes of the bytestream.  
All Convert messages start with a common 32 bits long header (Section 4.1), followed by one or more Convert TLVs (Type, Length, Value) (Section 4.2).
After a successful exchange of Convert messages, a TCP connection with TCP extension(s) is established between the Client and Transport Converter (for instance, Multipath TCP), and a (normal) TCP connection is established between the Transport Converter and other end host, with the Transport Converter acting as an explicit proxy between the two connections (for instance, between MPTCP and TCP).  

Section 4.0, 4.2.6 etc
Various places say things like "the Unassigned field MUST be set to zero by the transmitter and
   ignored by the receiver.  These bits are available for future use
   [RFC8126]."
Comment: I heard in ietf-105 about problems for extensibility of various protocols because implementations insist on all zeroes for fields, otherwise discard packets. The suggestion is to grease (which I think means that the senders set to random values and receivers MUST ignore)
Also, 'sender' rather than 'transmitter'

Figure 11
In the figure you have Value being optional in bits 16-31 and compulsory in bits 32+. I think this should be the other way round. 

Section 4.2.8
"This TLV has a variable length.  It appears after the Convert fixed-
   header in the bytestream returned by the Transport Converter."
Figure 19 doesn't show variable length. Must its length be a multiple of 32 bytes (padded if needed)? (I assume so, to be consistent with elsewhere.)
The second sentence could be deleted, since elsewhere text says the TLV(s) must be at the start of the bytestream. But if you keep the sentence I suggest you say "appears _immediately_ after" 

S6
"The case of a middlebox that removes the payload of SYN+ACKs (but the  
       payload of SYN) can be detected by a Client."
Do you mean: but _not_ the payload of SYN?

<<Appendix A.  Change Log
   This section to be removed before publication.>>
It would be really nice if somehow the material here that explains the design rationale, and development from earlier approaches, could be kept. It's useful info, I think. 

Best wishes,
phil

-----Original Message-----
From: Scharf, Michael [mailto:[email-masked]] 
Sent: 22 July 2019 09:01
To: Eardley,PL,Philip,TUD1 R <[email-masked]>
Cc: [email-masked]
Subject: WGLC comments addressed in draft-ietf-tcpm-converters-09?

Hi Phil,

Could you please have a look at -09 and let me know if your WGLC comments are addressed?

If not, please follow-up on the mailing list.

Thanks

Michael

-----Original Message-----
From: tcpm <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, July 22, 2019 8:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-09.txt

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-09.txt
	Pages           : 47
	Date            : 2019-07-21

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.

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-09
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-09

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

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/

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

---

From: <[email-masked]>
Date: Wed, 31 Jul 2019 12:21:59 +0000

Hi Phil, 

Thank you for double checking. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : mercredi 31 juillet 2019 12:26
> À : [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converters-
> 09?
> 
> I think most of my comments are addressed. Here are some things I think
> could still be clarified, plus a couple of extra questions that occurred
> to me when I was checking the latest version.
> 
> Section 3.1
> <<Nevertheless, and unless this is explicitly stated,  the description
> assumes outgoing connections as default.>>
> 
> This sentence seems to contradict itself (can something be both assumed
> and have to be explicitly stated?).

[Med] Yes. Consider for example the following text:

   "By default, the Transport Converter listens on TCP port number TBA
   for Convert protocol (Convert, for short) messages from Clients.

   following sub-sections."

It applies only for the outgoing connections. 

 Maybe:-
> In general this document assumes that the client initiates the connection
> (in other words, it is an outgoing connection); the scenario with an
> incoming connection is discussed in a couple of places [references].

[Med] I can use this wording if you think it is better.  

> 
> In Figure 1 I find the 'upstream' and 'downstream' labels a bit confusing
> (especially as the lines have arrowheads in both directions), and it is
> shown as the link between client and converter etc. I think it would be
> better to move lower down (ie separate from the actual link), something
> like:

[Med] Actually, upsteram and downstream are defined as follows: 

   o  the upstream connection is the one between the Client and the
      Transport Converter.

   o  the downstream connection is between the Transport Converter and
      the Server.

This is independent of the connection direction. 

> Figure 5 caption has a stray "(1)" that can be deleted

[Med] Fixed.

> I think ", eventually," should be deleted.

[Med] "eventually" is justified: cover the case of a converter configured in an address preservation mode (e.g., IPv6). The destination IP address won't be rewritten in such case.   

> Section 3.2 / 3.3
> There are two paragraphs at the end of 3.2 and a bit more in 3.3
> discussing what happens when a connection ends with FIN and TCP RST etc. I
> think you should write a bit more about the MPTCP case - since there are
> subflow TCP RST and MP_FASTCLOSE cases to consider. A TCP RST on one MPTCP
> subflow presumably shouldn't trigger the Converter to close the TCP
> connection on its other interface.

[Med] Section 3.2 covers the generic TCP case. Hence, there is no need to discuss MPTCP specifics in that section. 

I guess you are referring to this text in Section 3.3: 

   Note that, if the TCP connection fails for some reason, the Converter
   tears down the Multipath TCP connection by transmitting a
   MP_FASTCLOSE.  Likewise, if the Multipath TCP connection ends with
   the transmission of DATA_FINs, the Converter terminates the TCP
   connection by using FIN segments. 

The text covers exclusively the cases that lead to the termination of the upstream/downstream connection. 

Given that MPTCP spec says: 

   "With MPTCP, the RST only has the scope of the
   subflow and will only close the concerned subflow but not affect the
   remaining subflows.  MPTCP's connection will stay alive at the data
   level, in order to permit break-before-make handover between
   subflows."

the subflow RST is not covered (as it does not terminate the MPTCP leg). 

> The Client also listens on TCP port TBA (not just the converter)

[Med] The client will listen on the internal port number that it indicated when creating a mapping in the converter to allow for incoming connections. This is needed to demux services hosted on the same client. 

This is covered in this text: 

   The Converter accepts the request by creating a TCP
   mapping (internal IP address, internal port number, external IP
   address, external port number).  The external IP address and external
   port number will be then advertised using an out-of-band mechanism so
   that remote hosts can initiate TCP connections to the Client via the
   Converter.  Note that the external and internal information may be
   the same. 

> Question: there seems to be a contradiction. The text here says "Convert
> messages may appear only in syn, syn-ack, ack". But then in S3.2 it says
> "This information is sent at the beginning of the bytestream, either
> directly in the SYN+ACK or in a subsequent packet." (this information is
> "about the TCP options that were negotiated with the Server.")
> (Incidentally, in S3.2 essentially the same sentence is repeated two
> sentences later.)  is the idea that SYN / syn-ack /ack is the 'normal'
> case, but can be in later pkts?

[Med] Good catch. 

OLD:
   The Client sends a SYN destined to the Transport Converter.  The
   payload of this SYN contains the address and port number of the
   Server.  The Transport Converter does not reply immediately to this
   SYN.  It first tries to create a TCP connection towards the target
   Server.  If this upstream connection succeeds, the Transport
   Converter confirms the establishment of the connection to the Client
   by returning a SYN+ACK and the first bytes of the bytestream contain
   information about the TCP options that were negotiated with the
   Server.  This information is sent at the beginning of the bytestream,
   either directly in the SYN+ACK or in a subsequent packet.  For
   graphical reasons, the figures in this section show that the
   Transport Converter returns this information in the SYN+ACK packet.
   An implementation could also place this information in a packet that
   it sent shortly after the SYN+ACK.

NEW:
   The Client sends a SYN destined to the Transport Converter.  The
   payload of this SYN contains the address and port number of the
   Server.  The Transport Converter does not reply immediately to this
   SYN.  It first tries to create a TCP connection towards the target
   Server.  If this upstream connection succeeds, the Transport
   Converter confirms the establishment of the connection to the Client
   by returning a SYN+ACK and the first bytes of the bytestream contain
   information about the TCP options that were negotiated with the
   Server.  

> 
> Question: the text says "Clients send packets that are eligible to the
> conversion service to the provisioned Transport Converter using TBA as
> destination port number." Is this referring to the exchange of Convert
> protocol messages? Or is this referring to subsequent data that is
> actually sent to the TBA port number? I think the text implies the latter,
> which I assume is not correct.

[Med] This applies to all messages that cross the converter. 

> 
> 
> Suggested text:-
> 
> <<
>    This section defines the Convert protocol (Convert, for short) messages
> that are exchanged between a Client and a Transport Converter.
> 
>    Convert messages MUST be sent to TCP destination port TBA. Therefore, a
> Transport Converter and a Client listen on this TCP port for Convert
> messages.

[Med] The initial wording is correct. 

>    Convert messages MAY appear in a SYN, SYN+ACK, or ACK or MAY appear in

[Med] The initial wording is correct. 

> All Convert messages start with a common 32 bits long header (Section
> 4.1), followed by one or more Convert TLVs (Type, Length, Value) (Section
> 4.2).
> After a successful exchange of Convert messages, a TCP connection with TCP
> extension(s) is established between the Client and Transport Converter
> (for instance, Multipath TCP), and a (normal) TCP connection is
> established between the Transport Converter and other end host, with the
> Transport Converter acting as an explicit proxy between the two
> connections (for instance, between MPTCP and TCP).

[Med] No problem (even if the last sentence is already stated in previous sections). 

> Comment: I heard in ietf-105 about problems for extensibility of various
> protocols because implementations insist on all zeroes for fields,
> otherwise discard packets. The suggestion is to grease (which I think
> means that the senders set to random values and receivers MUST ignore)

[Med] I don't see the value for doing this.   

> Also, 'sender' rather than 'transmitter'

[Med] Fixed. Thanks. 

> 
> Figure 11
> In the figure you have Value being optional in bits 16-31 and compulsory
> in bits 32+. I think this should be the other way round.

[Med] OK.

> Figure 19 doesn't show variable length. Must its length be a multiple of
> 32 bytes (padded if needed)? (I assume so, to be consistent with
> elsewhere.)

[Med] Agree. Fixed the figure. 

Padding is mentioned in the error description (when appropriate), e.g.,: 

     "The
      list of unsupported TCP options MUST be padded with zeros to end
      on a 32 bits boundary. "

> The second sentence could be deleted, since elsewhere text says the TLV(s)
> must be at the start of the bytestream. But if you keep the sentence I
> suggest you say "appears _immediately_ after"
> 

[Med] Deleted that sentence. No need to be redundant. 

> Do you mean: but _not_ the payload of SYN?

[Med] Yes. 

> It would be really nice if somehow the material here that explains the
> design rationale, and development from earlier approaches, could be kept.
> It's useful info, I think.

[Med] OK, added a new appendix to cover the key points. 

> 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.
>