Subject: [tcpm] WGLC for draft-ietf-tcpm-converters-08

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 25 Jun 2019 16:38:52 +0000

Hi all,

draft-ietf-tcpm-converters has been discussed and reviewed quite a bit.

Therefore, this e-mail starts a working group last call (WGLC) for draft-ietf-tcpm-converters-08 that will run until ***July 14, 2019***.

Please let us know if there are any remaining open issues regarding this document. Statements supporting publication are also welcome. In absence of feedback we will assume that the TCPM consensus is to move the document to the IESG. As discussed in the past, the intended status of the document is experimental.

Thanks a lot

Michael
(TCPM co-chair)

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 25 Jun 2019 23:35:56 -0700

Hello,

> Please let us know if there are any remaining open issues regarding this document. Statements supporting publication are also welcome. In absence of feedback we will assume that the TCPM consensus…

I support this document.

In cellular networks proxies are very common and won't go away for various
reasons.
Having a standardized way for proxying - with the goal of allowing
extensibility - will bring some structure in this environment.

Christoph

---

From: Adi Masputra <[email-masked]>
Date: Wed, 26 Jun 2019 17:15:56 +0900

I support this document.

Adi

> On Jun 26, 2019, at 01:38, Scharf, Michael <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Florin Baboescu <[email-masked]>
Date: Wed, 26 Jun 2019 18:01:07 +0900

Dear all,

I support this document.
- Florin 

> On Jun 26, 2019, at 5:15 PM, Adi Masputra <adi=[email-masked]> wrote:
> 
> I support this document.
> 
> Adi
>

---

From: <[email-masked]>
Date: Thu, 27 Jun 2019 15:58:01 +0000

I support this document. Thanks to the authors for the nice work. 

Here are some comments /questions and suggested clarifications.

Questions:
Section 4.1
"    The Client and the Transport Converter MUST send the fixed-sized
   header, shown in Figure 9, as the first four bytes of the bytestream."
Are there any other protocols that claim rights on the first bytes of the bytestream? Even in the context of signalling as indicated by the port# (to be assigned), is this certain?

" Data added by the Convert protocol to the TCP bytestream in the
   upstream connection is unambiguously distinguished from payload data
   in the downstream connection by the Total Length field in the Convert
   messages."
Is it required that the Convert data is at a fixed point in the bytestream? Think you've assumed it's at the start?
(Also, I think you could delete 'upstream' and 'downstream' in the quoted sentence - in any case, presumably they should both be one or the other)

Convert protocol:
How do the messages with the Supported TCP Extensions TLV and Connect TLV relate to each other? Is it required to learn through the "Supported TCP Extensions" that a Converter supports a particular TCP option before sending a Connect with that Option? I assume not - and that it's just a MAY to send the Supported TCP Extensions - as it seems to me like an optimisation and not too much harm happens if you send a Connect for an unsupported extension. 

--------------
Suggested clarifications - significant:-

I think it would be great if Section 3 was expanded into a "protocol model" https://tools.ietf.org/html/rfc4101 in particular to expand on
<<   2. What messages are being transmitted and what do they mean?>> - figures show the basic msg exchanges (info, connect, extended, supported, cookie and error)
<<   3. What are the important, but unobvious, features of the protocol?>> eg use of assigned port# ; use of first bytes of bytestream ;etc.

I think you could distinguish more carefully between: the initiator of the TCP convert protocol and the other 'legacy' end point versus the end device downstream on a broadband line and the server upstream in the internet. The language of the doc basically assumes that a "Client" fulfils both the first roles and a "Server" fulfils both the last roles, but this needs not always be the case. I realised this reading Section 4.2.8, but I suspect it's true in many other places. 

----------------
Suggested clarifications - other:-
Section 1:

Para " There are some situations..." I think you could slightly adjust the mention of PEPs. For example, a PEP that re-spaces TCP ACKs doesn't have anything to do with the problem mentioned in the first part of the para (about the difficulty of ensuring both clients and servers are upgraded)

Para " More recently, experimentation" I found the first sentence hard to parse. The para seems to use latency to refer to two things (without pointing this out): packet forwarding latency and set-up signalling latency

List of bullets about what a transport converter achieves. I 'd add one to say it achieves 0-RTT - and to explain what 0-RTT means (quite a bit later before the reader discovers this) (and expand the RTT abbreviation)

Section 3:
Figure 2: explain "R"

" Further, the architecture allows for making use of new TCP extensions
   even if those are not supported by a given server."
I find the sentence a bit awkward. Maybe: Further, the architecture enables the use of new TCP extensions between the client and Transport Converter when they are not supported by a server.

Figure 3: I didn't understand why the note is needed "* TLS messages exhanged between the Client and the Server are not shown."

Para under figure 3: This mentions Connect TLVs, which is a mystery concept at this stage. 

Section 1 mostly says TCP extensions, with an occasional TCP options. Be consistent?

Section 3.2:
Figure 5: in the figure title there's "(1)" - what does this mean or is it a typo?

Para " A Transport Converter MAY operate"
"external address" - what does 'external' mean?

Section 4
Should there be a new Section 4.1 that explains the use of port # (to be assigned) to identify Convert protocol messages?

S4.1 title
"fixed header" - is "fixed" needed?

Figure 10:
I think the first "(optional)" should be deleted (ie in bytes 3 & 4)

" In general
   zero padding MUST be added if the value's length in bytes can not be
   expressed as 2+(4 * n)."
better, something like: If necessary, Value MUST be padded with zeroes so that the length of the TLV is a multiple of 32 bits.

" As a general rule, when an error is encountered an Error TLV with the
   appropriate error code MUST be returned by the Transport Converter."
'As a general rule' seems to conflict with 'MUST'

" Transport Converter SHOULD include in this
   list the TCP options that it accepts from Clients and that it
   includes the SYN packets that it sends to initiate connections."
I couldn't parse the second part of the sentence ("and that it...")

" The list of Supported TCP Extension is padded with 0 to end on a 32
   bits boundary."
Replace: The list of Supported TCP Extensions MUST be padded with 0 to end on a 32
   bits boundary.

Section 6
This section actually only discusses one type of middlebox (removes SYN). Can the discussion be widened slightly - or maybe simply say that if middlebox interference detected, then MUST stop using the Converter (with SYN removal given as an example)?

Not yet read Section 7 onwards, comments to follow.

Section 10 Change log
There's lots of really useful info about why the design is as it is (eg the use of TLV rather than Options). It would be a shame if this was lost from the rfc - please can info be extracted into a section "how implementation experiences have influenced design decisions" or similar?

Thanks
phil

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of Scharf, Michael
Sent: 25 June 2019 17:39
To: [email-masked] Extensions <[email-masked]>
Cc: [email-masked]
Subject: [tcpm] WGLC for draft-ietf-tcpm-converters-08

Hi all,

Thanks a lot

Michael
(TCPM co-chair)

---

From: <[email-masked]>
Date: Fri, 28 Jun 2019 08:15:16 +0000

Hi Phil,

Thank you for the review. Much appreciated.

Changes to address almost all your comments (except the protocol model one) can be seen at:
https://github.com/obonaventure/draft-tcp-converters/pull/62/files 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : jeudi 27 juin 2019 17:58
> À : [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08
> 
> Are there any other protocols that claim rights on the first bytes of the
> bytestream? Even in the context of signalling as indicated by the port#
> (to be assigned), is this certain?

[Med] I'm not aware of any. The point here is to unambiguously identify Convert data. 

> Is it required that the Convert data is at a fixed point in the
> bytestream? Think you've assumed it's at the start?

[Med] Yes, we assume that Convert data is at the start. 

> (Also, I think you could delete 'upstream' and 'downstream' in the quoted
> sentence - in any case, presumably they should both be one or the other)
> 

[Med] Fixed. 

> Convert protocol:
> How do the messages with the Supported TCP Extensions TLV and Connect TLV
> relate to each other? Is it required to learn through the "Supported TCP
> Extensions" that a Converter supports a particular TCP option before
> sending a Connect with that Option? I assume not - and that it's just a
> MAY to send the Supported TCP Extensions - as it seems to me like an
> optimisation and not too much harm happens if you send a Connect for an
> unsupported extension.

[Med] Yes, this is optional. The expected behavior is covered by this text: 

   The Info TLV (Figure 12) is an optional TLV which can be sent by a
   Client to request the TCP extensions that are supported by a
   Transport Converter.  It is typically sent on the first connection                         
   that a Client establishes with a Transport Converter to learn its
   capabilities.  Assuming a Client is entitled to invoke the Transport
   Converter, the latter replies with the Supported TCP Extensions TLV
   described in Section 4.2.4.

[Med] Snipped. Will cover this one in a separate message

> Para " There are some situations..." I think you could slightly adjust the
> mention of PEPs. For example, a PEP that re-spaces TCP ACKs doesn't have
> anything to do with the problem mentioned in the first part of the para
> (about the difficulty of ensuring both clients and servers are upgraded)

[Med] What about updating it as follows: 

OLD:
   Performance Enhancing Proxies [RFC3135], and other
   service functions have been deployed as solutions to improve TCP
   performance over links with specific characteristics.

NEW:
   Some assistance from the network to make use of these features 
   is valuable. For example, Performance Enhancing Proxies [RFC3135], 
   and other service functions have been deployed as solutions 
   to improve TCP performance over links with specific characteristics.

> 
> Para " More recently, experimentation" I found the first sentence hard to
> parse. 

[Med] Will reword. 

The para seems to use latency to refer to two things (without
> pointing this out): packet forwarding latency and set-up signalling
> latency
> 
> List of bullets about what a transport converter achieves. I 'd add one to
> say it achieves 0-RTT - and to explain what 0-RTT means (quite a bit later
> before the reader discovers this) (and expand the RTT abbreviation)
> 

[Med] Good point. This will be introduced before that bullet list since that list is built in reference to RFC1919.

> Figure 2: explain "R"

[Med] Fixed. This refers to "router".

> I find the sentence a bit awkward. Maybe: Further, the architecture
> enables the use of new TCP extensions between the client and Transport
> Converter when they are not supported by a server.

[Med] What about the following: 

  Furthermore, the architecture enables the use of 
  new TCP extensions by the clients even if those are 
  not supported by a given server. This is achieved 
  owing to the assistance of a Transport Converter.

> 
> Figure 3: I didn't understand why the note is needed "* TLS messages
> exhanged between the Client and the Server are not shown."

[Med] This is to make it clear that the TLS connection is handled directly between the client and the server. The converter does not interfere with that. 

> Para under figure 3: This mentions Connect TLVs, which is a mystery

[Med] changes to "Convert messages".

> Section 1 mostly says TCP extensions, with an occasional TCP options. Be

[Med] OK

> Figure 5: in the figure title there's "(1)" - what does this mean or is it

[Med] Fixed. We used to have two figures with the same title (1) and (2).

> "external address" - what does 'external' mean?

[Med] Changed to "source". 

"external" was used in reference to the source address of a packet as relayed by a converter. This is further discussed in 3.4.

> 
> Section 4
> Should there be a new Section 4.1 that explains the use of port # (to be
> assigned) to identify Convert protocol messages?

[Med] Fixed. 

> "fixed header" - is "fixed" needed?

[Med] It is fixed because it is present in all convert messages. Do you prefer "common" ?

> I think the first "(optional)" should be deleted (ie in bytes 3 & 4)

[Med] Deleted the second one. 

> better, something like: If necessary, Value MUST be padded with zeroes so
> that the length of the TLV is a multiple of 32 bits.
> 

[Med] That is better. Thanks. 

> 'As a general rule' seems to conflict with 'MUST'

[Med] Fixed. 

> I couldn't parse the second part of the sentence ("and that it...")

[Med] Changed to:

" A Transport Converter SHOULD include in
this list the TCP options that it accepts from Clients; these options are 
included by the Transport Converter in the SYN packets that it sends to initiate connections."

Better? 

> Replace: The list of Supported TCP Extensions MUST be padded with 0 to end

[Med] Deal!

> Section 6
> This section actually only discusses one type of middlebox (removes SYN).
> Can the discussion be widened slightly

[Med] This section only focuses on SYN/SYN-ACK because these are used by the Convert protocol.

Do you have in mind a particular case (specific to the Convert protocol) that may be problematic?

 - or maybe simply say that if
> middlebox interference detected, then MUST stop using the Converter (with
> SYN removal given as an example)?
> 
> There's lots of really useful info about why the design is as it is (eg
> the use of TLV rather than Options). It would be a shame if this was lost
> from the rfc - please can info be extracted into a section "how
> implementation experiences have influenced design decisions" or similar?
> 
> Thanks
> phil
> 
> Therefore, this e-mail starts a working group last call (WGLC) for draft-
> ietf-tcpm-converters-08 that will run until ***July 14, 2019***.
> 
> Please let us know if there are any remaining open issues regarding this
> document. Statements supporting publication are also welcome. In absence
> of feedback we will assume that the TCPM consensus is to move the document
> to the IESG. As discussed in the past, the intended status of the document
> is experimental.
> 
> Thanks a lot
> 
> Michael
> (TCPM co-chair)
>

---

From: <[email-masked]>
Date: Fri, 28 Jun 2019 09:27:03 +0000

Re-,

Focusing on this part of the review. 

Please see inline. 

Cheers,
Med

> I think it would be great if Section 3 was expanded into a "protocol
> model" https://tools.ietf.org/html/rfc4101 in particular to expand on

[Med] Section 3 is purposely edited "to quickly grasp the essence of" the convert protocol. It focuses on the main design rationale that is use one single SYN to supply data to a converter. That supplied data is unambiguously distinguished by means of TLVs and location within the payload.  

> <<   2. What messages are being transmitted and what do they mean?>> -
> figures show the basic msg exchanges (info, connect, extended, supported,
> cookie and error)

[Med] There is a risk to be redundant with Section 4 (4.2.2, in particular) + discuss messages that are not defined yet. We may consider adding figures to section 4, though. 

> <<   3. What are the important, but unobvious, features of the protocol?>>
> eg use of assigned port# ; use of first bytes of bytestream ;etc.

[Med] Again, there is a risk to be redundant here. Will think about this further. 

> 
> I think you could distinguish more carefully between: the initiator of the
> TCP convert protocol and the other 'legacy' end point versus the end
> device downstream on a broadband line and the server upstream in the
> internet. The language of the doc basically assumes that a "Client"
> fulfils both the first roles and a "Server" fulfils both the last roles,
> but this needs not always be the case. I realised this reading Section
> 4.2.8, but I suspect it's true in many other places.

[Med] I agree with the comment. 

The assumption are as follows:
* The default communication direction is assumed to be from a host (Client role) to a remote host (Server role): denoted as "outgoing"
* A host (which is used to be a client for outgoing connections) may accept incoming connections because it embeds an application server. We called that "client" too for simplification reasons. 

Point taken, we will need to figure out how to make this better.

---

From: "Scharf, Michael" <[email-masked]>
Date: Sat, 29 Jun 2019 11:58:49 +0000

Dear authors,

The document shepherd has to ensure compliance with the IPR guidelines of the IETF.

Can each author please confirm that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

Note that an answer is required from all authors of the document. The TCPM lists is added in CC for the sake of transparency.

Thanks

Michael

Von: Scharf, Michael<mailto:[email-masked]>
Gesendet: Dienstag, 25. Juni 2019 18:39
An: [email-masked] Extensions<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Betreff: WGLC for draft-ietf-tcpm-converters-08

Hi all,

Thanks a lot

Michael
(TCPM co-chair)