Subject: [tcpm] Éric Vyncke's Discuss on draft-ietf-tcpm-converters-17: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 02 Mar 2020 06:58:47 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-tcpm-converters-17: Discuss

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-converters/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. It is indeed useful to be able
to deploy easily new TCP features.

Nevertheless, please find below two DISCUSSes and some non-blocking COMMENTs
(and I would appreciate a response from the authors) and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 1.2 --
A trivial one: while the title and the abstract of this document appear as
quite generic, the document focus is reduced later in section 1.2 to MPTCP:
  "this
   document specifies how the Convert Protocol applies for Multipath
   TCP.  It is out of scope of this document to provide a comprehensive
   list of all potential conversion services. "
While I do not mind having a focus on MPTCP only, I would strongly suggest to
reflect this focus in the title and in the abstract (the current filename is
correct).

-- Section 6.2.8 --
I appreciate that this is an experimental document, but, having only 2
occurrences of ICMP in the whole document and no real "how to process" TLV
"Destination Unreachable"... and the payload of this TLV having only the code
without the offending packet will probably make Path MTU discovery (and other
mechanisms) impossible.

While I am not a transport expert, I believe that this aspect needs to be
described in this document.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Here are some COMMENTs
-- Section 1.2 --
Is the benefit of a transport proxy only for the clients as written in the 1st
paragraph? It was probably the case for the original MPTCP proxy but what about
other TCP extensions?

-- Section 4.1 --
While the difference "(Internet-facing interface, customer-facing interface)"
will probably represent the vast majority of use cases, I wonder whether there
will always be a single Internet-facing ? Could probably be 0 or 2 in some use
cases... Suggest to remove this part of the text.

-- Section 6.1 --
Please state the usual wording about "unassigned" field: it must be ignored by
the receiver.

Adding some explanations on why version 0 is reserved but cannot be used would
be welcome.

-- Section 6.2.5 --
Can the "remote peer IP address" be a link-local address ?

== NITS ==

-- Section 1.1 (and possibly others) --
Please use a consistent means of introducing acronyms, cfr URLLC and ATSSS ;-)

-- Section 4.2 ---
The use of "regular TCP packets" makes me wonder whether the authors think that
MPTCP uses "irregular TCP packets"... The use of 'regular' seems a little weird
here but I am not a native English speaker.

-- Section 4.3 --
The caption below figure 7 ends with "(TCP)" that is not the acronym of
"Transport Session Entry". Is it expected ?

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 2 Mar 2020 16:18:38 +0100

Hi Eric,

Just on your first discuss comment. This document was initial proposed in MPTCP and then moved to tcpm as a generic mechanism. Use of a converter does not make sense for all TCP options but in other cases than MPTCP it is also often quite straight forward. I would prefer to keep it generic in the abstract and especially title because that the intention.

Mirja

> On 2. Mar 2020, at 15:58, Éric Vyncke via Datatracker <[email-masked]> wrote:
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 2 Mar 2020 19:41:23 +0000

Mirja,

Your explanation about my first discuss makes sense. I will downgrade this DISCUSS to a COMMENT (see below) when clearing the 2nd DISCUSS.

The old discuss becomes the following non-blocking COMMENT. Same issue, but, with a text change suggestion:

OLD TEXT
   This document specifies an application proxy, called Transport
   Converter, to assist the deployment of TCP extensions such as
   Multipath TCP.  A Transport Converter may provide conversion service
   for one or more TCP extensions.  The conversion service is provided
   by means of the TCP Convert Protocol (Convert).

NEW TEXT
   This document specifies an application proxy, called Transport
   Converter, to assist the deployment of TCP.
   A Transport Converter may provide conversion service
   for one or more TCP extensions.  The conversion service is provided
   by means of the TCP Convert Protocol (Convert). This document focuses on Multipath TCP as an example of this generic mechanism.

Hope this helps

-éric
-----Original Message-----
From: iesg <[email-masked]> on behalf of Mirja Kuehlewind <[email-masked]>
Date: Monday, 2 March 2020 at 16:19
To: Eric Vyncke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-tcpm-converters-17: (with DISCUSS and COMMENT)

    Hi Eric,

    Mirja

---

From: <[email-masked]>
Date: Tue, 3 Mar 2020 08:02:10 +0000

Hi Eric, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:[email-masked]]
> Envoyé : lundi 2 mars 2020 15:59
> À : The IESG
> Cc : [email-masked]; [email-masked];
> [email-masked]; Michael Scharf; [email-masked]
> Objet : Éric Vyncke's Discuss on draft-ietf-tcpm-converters-17: (with
> DISCUSS and COMMENT)
> 

[Med] As explained by Mirja, MPTCP is only meant to exemplify the approach. I added this note at the end of the abstract:

"As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP." 

> without the offending packet will probably make Path MTU discovery

[Med] Some comments here:
* The connection is split into two legs. As such, path MTU considerations are managed by the endpoints of each of these legs: (client and converter) and (converter and server). 
* We don't require specific treatment to ICMP messages, except for when there is a reachability issue to the server we decide to echo ICMP reachability errors to the client. 
* We don't need to echo the payload (*) of the ICMP error in the Convert Error Code because this is bound to the TCP connection over which the error was received. This is done in-band if you will.  

=(*)=
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Or 

      |                    As much of invoking packet                 |
      +                as possible without the ICMPv6 packet          +
      |                exceeding the minimum IPv6 MTU [IPv6]          |
==

* The connection is aborted upon receipt of this error. 

Please let us know if you had in mind other processing that we need to call out. Thank you. 

> described in this document.

[Med] Good point. Added "in particular" to the sentence you are referring to. 

Even with MPTCP we do have scenarios that are 'network-specific" (e.g., data-centers). 

> cases... Suggest to remove this part of the text.

[Med] Indeed, more than one interface may be available. See for example:

   A first safeguard against the misuse of Transport Converter resources
   by illegitimate users (e.g., users with access networks that are not
   managed by the same provider that operates the Transport Converter)
   is the Transport Converter to reject Convert connections received on
   its Internet-facing interfaces.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

What about using Internal realm and External realm? 

> Please state the usual wording about "unassigned" field: it must be

[Med] Added. Thanks.

> Adding some explanations on why version 0 is reserved but cannot be

[Med] In early versions of the spec, we don't use a dedicated port number for the protocol but relies only the IP address of the converter. Having a bit set in the version number + the length field allows to avoid interpreting a data as Convert TLVs. We even considered the use of a Magic Number to unambiguously identify Convert messages. 

Since we updated design to have a dedicated service port, we don't have those issues. Version 0 would work as well but existing implementations already use version 1.

> Can the "remote peer IP address" be a link-local address ?

[Med] It is unlikely but I prefer to not declare it as illegal. As a general rule, the converter will return a "Network Failure" error when it can't forward a packet.  

(You may check RFC8335 which allows to probe a remote endpoint...using a link-local address!)

> Please use a consistent means of introducing acronyms, cfr URLLC and

[Med] Will double check. Than you.

> MPTCP uses "irregular TCP packets"... The use of 'regular' seems a

[Med] I hear you. Will update the text. 

> "Transport Session Entry". Is it expected ?

[Med] Deleted, thanks.

We used to have another example with MPTCP specifics hence that mention.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 5 Mar 2020 13:19:05 +0000

Med

About my second discuss around ICMP. Thank you for the added information, but, I think that the document should be clear about:
- how the Convert processes received ICMP (e.g., you wrote in the email but not in the I-D: when receiving ICMPv6 type 1, then close the 2 connections and pass the code for ICMPv6 type=1 b)
- what to do with ICMPv6 type 3 from the server for example (re-assembly time-out) ? I guess that it is handled by the TCP entity in Convert but then there is no feedback to the client ?
- what to do with ICMPv6 type 3 from the client ?

In short, mentioning only twice ICMP without any description on how to process received ICMP seems really light and open to interpretation

-éric

-----Original Message-----
From: iesg <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Tuesday, 3 March 2020 at 09:02
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Michael Scharf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-tcpm-converters-17: (with DISCUSS and COMMENT)

    Hi Eric, 

    Please see inline. 
    
    Cheers,
    Med

    

    
    =(*)=
    
    Or 

    

    

    

    
    [Med] Added. Thanks.

    

    

    

    
    [Med] Deleted, thanks.

---

From: <[email-masked]>
Date: Thu, 5 Mar 2020 13:46:27 +0000

Hi Eric, 

Thank you for the follow-up.

Please see inline. 

Cheers,
Med

> De : Eric Vyncke (evyncke) [mailto:[email-masked]]
> Envoyé : jeudi 5 mars 2020 14:19
> À : BOUCADAIR Mohamed TGI/OLN; The IESG
> Cc : [email-masked]; [email-masked]; Michael
> Scharf; [email-masked]
> Objet : Re: Éric Vyncke's Discuss on draft-ietf-tcpm-converters-17:
> (with DISCUSS and COMMENT)
> 
> Med
> 
> About my second discuss around ICMP. Thank you for the added
> information, but, I think that the document should be clear about:
> - how the Convert processes received ICMP (e.g., you wrote in the
> email but not in the I-D: when receiving ICMPv6 type 1, then close the
> 2 connections and pass the code for ICMPv6 type=1 b)

[Med] Actually, this is governed by this text for all errors (6.2.8):

   "Upon reception of an Error TLV, a
   Client MUST reset the associated connection."

> - what to do with ICMPv6 type 3 from the server for example (re-
> assembly time-out) ? I guess that it is handled by the TCP entity in
> Convert but then there is no feedback to the client ?

[Med] These are handled locally by the converter and no feedback is sent to the client because this is a soft error (RFC793bis):

==
   Soft Errors
     For ICMP these include: Destination Unreachable -- codes 0, 1, 5,
     Time Exceeded -- codes 0, 1, and Parameter Problem.
     For ICMPv6 these include: Destination Unreachable -- codes 0 and 3,
     Time Exceeded -- codes 0, 1, and Parameter Problem -- codes 0, 1, 2
     Since these Unreachable messages indicate soft error conditions,
     TCP implementations MUST NOT abort the connection (MUST-56), and it
     SHOULD make the information available to the application (SHLD-25).
==

If we had to echo such class of ICMP messages in an Error TLV, the connection will be reset...which is conflicting with RFC793. That's not an option.

Will need to think about this one further and add more text to the draft. 

> In short, mentioning only twice ICMP without any description on how to
> process received ICMP seems really light and open to interpretation
> 

[Med] Idem as above. Thank you. 

> From: iesg <[email-masked]> on behalf of
> "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <draft-ietf-tcpm-
> [email-masked]>, "[email-masked]" <[email-masked]>, Michael Scharf
> <[email-masked]>, "[email-masked]" <tcpm-
> [email-masked]>
>     > email addresses included in the To and CC lines. (Feel free to
> cut
>     > this
>     > Thank you for the work put into this document. It is indeed
> useful to
>     > be able
>     > Nevertheless, please find below two DISCUSSes and some non-
> blocking
>     > COMMENTs
>     > quite generic, the document focus is reduced later in section
> 1.2 to
>     > MPTCP:
>     >   "this
>     > While I do not mind having a focus on MPTCP only, I would
> strongly
>     > suggest to
>     [Med] As explained by Mirja, MPTCP is only meant to exemplify the
> approach. I added this note at the end of the abstract:
> 
>     "As a sample applicability use case, this document specifies how
> the Convert Protocol applies for Multipath TCP."
> 
>     > -- Section 6.2.8 --
>     > occurrences of ICMP in the whole document and no real "how to
> process"
>     > TLV
>     > "Destination Unreachable"... and the payload of this TLV having
> only
>     > the code
>     > without the offending packet will probably make Path MTU
> discovery
>     > (and other
>     > mechanisms) impossible.
>     >
> 
>     * The connection is split into two legs. As such, path MTU
> considerations are managed by the endpoints of each of these legs:
> (client and converter) and (converter and server).
>     * We don't require specific treatment to ICMP messages, except for
> when there is a reachability issue to the server we decide to echo
> ICMP reachability errors to the client.
>     * We don't need to echo the payload (*) of the ICMP error in the
> Convert Error Code because this is bound to the TCP connection over
> which the error was received. This is done in-band if you will.
> 
>     =(*)=
>     > While I am not a transport expert, I believe that this aspect
> needs to
>     > be
>     > Is the benefit of a transport proxy only for the clients as
> written in
>     > the 1st
>     > paragraph? It was probably the case for the original MPTCP proxy
> but
>     > what about
>     > other TCP extensions?
>     >
> 
>     > While the difference "(Internet-facing interface, customer-
> facing
>     > interface)"
>     > will always be a single Internet-facing ? Could probably be 0 or
> 2 in
>     > some use
>     > Please state the usual wording about "unassigned" field: it must
> be
>     > ignored by
>     > the receiver.
>     >
> 
>     [Med] Added. Thanks.
> 
>     > Adding some explanations on why version 0 is reserved but cannot
> be
>     > used would
>     > be welcome.
> 
>     [Med] In early versions of the spec, we don't use a dedicated port
> number for the protocol but relies only the IP address of the
> converter. Having a bit set in the version number + the length field
> allows to avoid interpreting a data as Convert TLVs. We even
> considered the use of a Magic Number to unambiguously identify Convert
> messages.
> 
>     Since we updated design to have a dedicated service port, we don't
> have those issues. Version 0 would work as well but existing
> implementations already use version 1.
> 
> 
>     >
>     > -- Section 6.2.5 --
>     [Med] It is unlikely but I prefer to not declare it as illegal. As
> a general rule, the converter will return a "Network Failure" error
> when it can't forward a packet.
> 
>     > Please use a consistent means of introducing acronyms, cfr URLLC
> and
>     > ATSSS ;-)
> 
>     > The use of "regular TCP packets" makes me wonder whether the
> authors
>     > think that
>     > MPTCP uses "irregular TCP packets"... The use of 'regular' seems
> a
>     > little weird
> 
>     > The caption below figure 7 ends with "(TCP)" that is not the
> acronym
>     > of

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 5 Mar 2020 13:53:00 +0000

Med,

I am sure that you and the other authors could easily add clarifications and descriptions around the ICMP handling (as seen from the Convert node). Once, it is clarified and added to the I-D, then I am clearing my DISCUSS ;-)

-éric

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Thursday, 5 March 2020 at 14:46
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Michael Scharf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-tcpm-converters-17: (with DISCUSS and COMMENT)

    Hi Eric, 

    Please see inline. 
    
    Cheers,
    Med

    

    
    ==
       Soft Errors