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

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

Finishing my review...

Section 4.2.8 Error TLV
Resource exceeded & Network failure
" The
      Transport Converter may indicate in the Value field the suggested
      delay (in seconds) that the Client SHOULD wait before soliciting
      the Transport Converter for a new proxied connection.  A Value of
      zero corresponds to a default delay of at least 30 seconds."
Are there any circumstances in which a Transport Converter may want to suggest that the Client waits less than one second before re-trying?

Section 7.5 Multipath TCP-specific Considerations
" aggregation service" -> multipath TCP converter service?

" This method does not require any interaction
      with the Transport Converter." [twice]
You could say interaction of what (since something is interacting with it!)

Section 8 IANA Considerations
Convert TLVs 
It has a range assigned via IETF review, a range assigned via Specification required and a range for Private use. Wouldn't it be simpler to choose either IETF review or Specification required (plus private use)? I think Specification required would be ok, given the RFC will be Experimental.

Convert Error Messages
It has a range assigned via IETF review and a range assigned via Specification required. 
Same comment as above, except more strongly - for error messages, IETF review seems excessive to me.
Also, would it be useful to have some space for Private use?

Section 11 Example Socket API Changes to Support the 0-RTT Convert Protocol
" As an example, on Linux, a client can send the 0-RTT Convert message
   inside a SYN by using sendto with the MSG_FASTOPEN flag as shown in
   the example below"
Is this example right? Since Transport Converter now uses TLV messages rather than TFO?

Section 12
" A recently
   proposed extension to SOCKS also leverages the TFO option"
I think "also" should be deleted (since Transport Converter now uses TLV messages rather than TFO)

Section 13
[RFC6824]
Would be good to update to the bis document (which has currently completed IESG - I think waiting for AD follow-up)

Thanks - best wishes,
phil

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 27 June 2019 16:58
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08

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,

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) 

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

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

---

From: <[email-masked]>
Date: Tue, 2 Jul 2019 09:05:22 +0000

Hi Phil,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : lundi 1 juillet 2019 12:04
> À : [email-masked]; [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08
> 
> Finishing my review...
> 
> Section 4.2.8 Error TLV
> Are there any circumstances in which a Transport Converter may want to
> suggest that the Client waits less than one second before re-trying?

[Med] The errors we identified so far do not have such requirements. 

> " aggregation service" -> multipath TCP converter service?

[Med] OK.

> You could say interaction of what (since something is interacting with

[Med] added "... for authorization matters."

> It has a range assigned via IETF review, a range assigned via
> Specification required and a range for Private use. Wouldn't it be simpler
> to choose either IETF review or Specification required (plus private use)?
> I think Specification required would be ok, given the RFC will be
> Experimental.

[Med] We are simplifying the assignment for some code points while allowing for a range to be reserved to key extensions. This is simple compared to "Standards Action" I have seen in some experimental RFCs! 

> review seems excessive to me.

[Med] Why? The same considerations (interoperability) apply for the error codes and TLVs.  

> Also, would it be useful to have some space for Private use?

[Med] Makes sense. 

> Is this example right?

[Med] Yes. 

 Since Transport Converter now uses TLV messages
> rather than TFO?

[Med] This is about the control flags. 

> messages rather than TFO)

[Med] OK.

> IESG - I think waiting for AD follow-up)

[Med] Will consider this once the bis is sent to the RFC editor. 

FWIW, the changes to address this review can be seen at: https://github.com/obonaventure/draft-tcp-converters/pull/65/files

---

From: <[email-masked]>
Date: Fri, 5 Jul 2019 09:04:01 +0000

Hi Michael,

I am not aware of any undisclosed IPR relevant to this document.

Cheers,
Med

De : Scharf, Michael [mailto:[email-masked]]
Envoyé : samedi 29 juin 2019 13:59
À : [email-masked]
Cc : [email-masked] Extensions
Objet : IPR poll for draft-ietf-tcpm-converters

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)

---

From: SungHoon Seo <[email-masked]>
Date: Fri, 5 Jul 2019 09:22:01 +0000

Dear Scharf,

I confirm that there is no undisclosed IPR related to this document in my awareness.

Thank you,
SungHoon Seo

From: tcpm [mailto:[email-masked]] On Behalf Of Scharf, Michael
Sent: Saturday, June 29, 2019 8:59 PM
To: [email-masked]
Cc: [email-masked] Extensions <[email-masked]>
Subject: [tcpm] IPR poll for draft-ietf-tcpm-converters

Dear authors,

Thanks

Michael

Hi all,

Thanks a lot

Michael
(TCPM co-chair)

이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately.

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 8 Jul 2019 10:10:52 +0200

Michael,
> I am not aware of any undisclosed IPR relevant to this document.

Same for me

Olivier

-- 

Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>

---

From: Benjamin Hesmans <[email-masked]>
Date: Mon, 8 Jul 2019 12:21:43 +0200

Dear Michael,

I’m not aware of any undisclosed IPR related to this document

Best regards,

On Mon, Jul 8, 2019 at 10:11 AM Olivier Bonaventure <
[email-masked]> wrote:

> ------------------------------
>

-- 
 <http://www.tessares.net> Benjamin Hesmans | R&D
Engineer
[email-masked] | <benjamin.hesmans%40tessares.net>
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
<https://www.google.com/maps?q=1+Avenue+Jean+Monnet,+1348+Ottignies-Louvain-la-Neuve,+Belgium>

--

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 8 Jul 2019 14:15:54 +0000

Hi Michael,

I am not aware of any undisclosed IPR on this draft.

Regards
Sri

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 5, 2019 at 2:04 AM
To: "Scharf, Michael" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> Extensions" <[email-masked]<mailto:[email-masked]>>
Subject: RE: IPR poll for draft-ietf-tcpm-converters
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Friday, July 5, 2019 at 2:04 AM

Hi Michael,

Cheers,
Med

De : Scharf, Michael [mailto:[email-masked]]
Envoyé : samedi 29 juin 2019 13:59
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]> Extensions
Objet : IPR poll for draft-ietf-tcpm-converters

Dear authors,

Thanks

Michael

Hi all,

Thanks a lot

Michael
(TCPM co-chair)

---

From: <[email-masked]>
Date: Tue, 9 Jul 2019 10:07:59 +0000

Med,
Thanks, just following up a couple of points.
> "fixed header" - is "fixed" needed?

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

[phil] I'd prefer if you explicitly stated that all Convert messages have this header. 
In fact, I think you could start Section 4 with text to capture the key points:
"This section describes the messages that are exchanged between a Client and a Transport Converter. All Convert protocol messages MUST be sent on a SYN, ACK or SYN-ACK, to port [tba]. All Convert protocol messages MUST be sent as the first bytes of the bytestream and MUST use the header shown in Figure 9 and described in Section 4.1, followed by the message itself using the generic TLV format shown in Figure 10 and described in Section 4.2. "

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

[phil] Yes. Instead of "are included" you could say MUST /SHOULD /MAY

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

[phil] the section only discusses removal of SYN, and not other ways a middlebox could interfere with the SYN/ACK. 

Thanks
phil

---

From: <[email-masked]>
Date: Tue, 9 Jul 2019 10:12:43 +0000

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

[phil] that's exactly the purpose of a protocol model. The full protocol description is just for people who need to understand the details, implementers etc.
Anyway, I leave you to think about it and edit as you feel best.

---

From: <[email-masked]>
Date: Tue, 9 Jul 2019 10:32:58 +0000

Med - thanks - no follow-ups
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 02 July 2019 10:05
To: Eardley,PL,Philip,TUD1 R <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: WGLC for draft-ietf-tcpm-converters-08

Hi Phil,

Please see inline.

Cheers,
Med

> [email-masked] Envoyé : lundi 1 juillet 2019 12:04 À : 
> [email-masked]; [email-masked]; [email-masked] 
> Cc : [email-masked] Objet : Re: [tcpm] WGLC for 
> draft-ietf-tcpm-converters-08
> 
> Finishing my review...
> 
> Section 4.2.8 Error TLV

> 
> Section 7.5 Multipath TCP-specific Considerations " aggregation 
> service" -> multipath TCP converter service?

[Med] OK.

>       with the Transport Converter." [twice] You could say interaction 
> of what (since something is interacting with
> it!)

> Specification required and a range for Private use. Wouldn't it be 
> simpler to choose either IETF review or Specification required (plus private use)?

[Med] Makes sense. 

> 
> Section 11 Example Socket API Changes to Support the 0-RTT Convert 
> Protocol " As an example, on Linux, a client can send the 0-RTT 
> Convert message

[Med] Yes. 

[Med] OK.

> 
> Section 13
> [RFC6824]
> Would be good to update to the bis document (which has currently 
> completed IESG - I think waiting for AD follow-up)

---

From: <[email-masked]>
Date: Tue, 9 Jul 2019 13:49:46 +0000

Hi Phil,

Please see inline. 

Cheers,
Med

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : mardi 9 juillet 2019 12:08
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked];
> [email-masked]
> Objet : RE: WGLC for draft-ietf-tcpm-converters-08
> 
> Med,
> "This section describes the messages that are exchanged between a Client
> and a Transport Converter. All Convert protocol messages MUST be sent on a
> SYN, ACK or SYN-ACK, to port [tba]. All Convert protocol messages MUST be
> sent as the first bytes of the bytestream and MUST use the header shown in
> Figure 9 and described in Section 4.1, followed by the message itself
> using the generic TLV format shown in Figure 10 and described in Section
> 4.2. "

[Med] Thanks. Some of this proposed text is redundant with existing text, e.g.,

   The Client and the Transport Converter MUST send the fixed-sized
   header, shown in Figure 9, as the first four bytes of the bytestream.

While other part of the text may not be accurate for incoming connections (MUST be sent ...to port (TBA)).

Now that I see more your point, I made some tweaking to address your comment as shown in:
https://github.com/obonaventure/draft-tcp-converters/pull/63/files 

> [phil] Yes. Instead of "are included" you could say MUST /SHOULD /MAY

[Med] This would be redundant with the "SHOULD" in that text. 

> [phil] the section only discusses removal of SYN, and not other ways a
> middlebox could interfere with the SYN/ACK.

[Med] The following cases can be considered for SYN/ACKs: 

(1) a middlebox that drops SYN/ACKs having a payload is straightforward. The client won't naturally be able to establish the connection via the converter.  

(2) a middlebox that removes the payload of SYN/ACKs:
 2-a. If that middlebox removes also the payload of SYNs (which is likely), this would have been detected by the client as per the text already in the draft. 
 2-b. If that middlebox lets pass SYNs with their payload but removes the payload of SYN/ACKs (for some mysterious reasons): This can be easily handled by the client because it expects an Error or Extended TCP Header TLV in the response. If an Error TLV was included, a message to terminate the connection would be sent by the Converter. Otherwise, there is no reason to close the connection.  

Do you think that "2-b" is likely and is worth to be documented in the text? Thank you.