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

[<[e-mail]>]

Phil, 

While waiting for the feedback from Michael, we updated the draft to better address some of your pending concerns. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-11 

As already mentioned, we tried to avoid overloading the document with deployment and implementation-specific details. For example, whether a dedicated address pool is configured to the converter, address sharing ratio, routing/forwarding considerations if an address preservation mode is used, the structure of the state entries, etc. These details are really out of scope. A pointer to an external document is provided for readers wanting to have more information.

Hope this version is OK to move forward. 

Cheers,
Med

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]]
> Envoyé : mercredi 18 septembre 2019 18:14
> À : BOUCADAIR Mohamed TGI/OLN; [e-mail];
> [e-mail]
> Cc : [e-mail]
> Objet : RE: WGLC comments addressed in draft-ietf-tcpm-converters-09?
> 
> Med,
> I'm sorry this has turned into a lot of back and forth.
> 
> I really do want the work published but I think we just disagree about one
> point. So I think we need other views or for the doc shepherd to make a
> decision.
> 
> Med's view is that the document's purpose is only to describe the Convert
> protocol (the control protocol). My view is that the description of the
> actual proxy (the data plane operation) should also be described. I don't
> think a lengthy treatise is required, nor a description of all the corner
> cases, but I think a page or two would be better than the current couple
> of lines (which are spread over two sections). I don't think it's obvious
> how the proxy operates (well, at least there are various points below
> where I got things wrong) and I don't think it should be left as an
> exercise for the reader:
> -	I think you should add some statement about how the data is
> identified  - it isn't just that it's received on port TBA - it also must
> check that it isn't a convert-control message. I assume by reading the
> first 32 bytes of the bytestream?
> -	If I get it right, the converter must be on the default path (in
> some or all circumstances?). This is not stated in the doc. It is, in my
> opinion, a non-obvious restriction for an explicit proxy.
> -	I think you should give a description or example for the address
> preservation and address sharing modes, since operation is a bit
> different.
> -	At least something about failure modes, in particular where this is
> different from a normal proxy
> 
> On aspects that are more presentational than about the level of detail:
> -	I think there should be one section that describes the proxy
> operation, and is titled as such.
> -	I don't think it should be described as a relay. In my opinion, a
> "relay" doesn't do congestion control, error recovery, buffering, TCP-to-
> MPTCP conversion etc. It's a TCP proxy.
> 
> Best wishes,
> phil
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 06 September 2019 12:45
> To: Eardley,PL,Philip,TUD1 R <[e-mail]>; Michael.Scharf@hs-
> esslingen.de; [e-mail]
> Cc: [e-mail]
> Subject: RE: WGLC comments addressed in draft-ietf-tcpm-converters-09?
> 
> Hi Phil,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : [e-mail] [mailto:[e-mail]] Envoyé :
> > jeudi 5 septembre 2019 18:03 À : BOUCADAIR Mohamed TGI/OLN;
> > [e-mail]; [e-mail] Cc :
> > [e-mail] Objet : RE: WGLC comments addressed in
> > draft-ietf-tcpm-converters-09?
> >
> > Med,
> >
> > Thanks. the address usage clarification is useful and I'm ok on other
> > things that are editorial decisions.
> >
> 
> [Med] Great, thanks.
> 
> > However, I disagree that Section 3 is adequate to describe how the
> > converter handles data.
> 
> [Med] We really tried to focus on the external behavior and avoided
> elaborating on implementation/deployment considerations. As far as this
> scope is followed, I'm more than happy to add statements that you think
> are missing. Otherwise, I don't want to include details such a
> comprehensive description of how state entries are created, their
> structure, the processing of the first SYN, subsequent messages, etc. as
> we have done in: https://tools.ietf.org/html/draft-boucadair-mptcp-plain-
> mode-08#section-4.3. That would be a distinct document. This one is about
> specifying the Convert Protocol.
> 
>  Since we've gone round this loop several times,
> > let me try and explain in more detail why I don't like what the
> > document says, and propose some text, so at least there's something
> > specific to discuss.
> >
> > .	I dislike (very much) that info about how the converter handles data
> > is in a sub-section called "Theory of operation" in the "Architecture"
> > section (in my opinion it is hidden) - and that the point about how
> > the data-for-conversion is identified is somewhere else (ie that it's
> > sent to a port TBA)
> > .	I think you should add some statement about how the data is
> > identified  - it isn't just that it's received on port TBA - it also
> > must check that it isn't a convert-control message (I assume by
> > reading the first 32 bytes of the bytestream). Or do you hav some
> > other technique in mind?
> > .	I don't think it's acting as a simple relay. It's acting as a TCP
> > proxy (a relay, in my opinion, doesn't do congestion control, error
> > recovery, buffering, TCP-to-MPTCP conversion etc)
> > .	I think there should be a statement about what to do if the
> > converter has no entry for the client address/port sending the data.
> > This is not the usual case, but in case of an error (eg converter
> > loses entries due to a crash). Should it close the connection or discard
> the pkts?
> > (former seems safer)
> > .	I think you should add some warning that client-server e2e TCP
> > functionality is lost
> >
> > I think you should spell out what happens for the address sharing and
> > address preservation cases (more below).
> >
> >
> > Maybe something like this (which also checks what I misunderstand!):-
> >
> > --
> > The Converter acts as a TCP proxy between the client-converter and
> > converter-server TCP connections.
> 
> [Med] The draft already states that the converter is gluing two
> connections.
> 
> > The control messages, discussed in Section 4, establish state in the
> > Converter that will enable it to proxy between the two TCP connections.
> 
> [Med] Will update the text to make this explicit.
> 
> > Data is sent from the Client (from: IP address x, port a) to the
> > Converter
> > (to: IP address y, port TBA). Port TBA is a specific, well-known port
> > which indicates the data is for Conversion.
> >
> 
> [Med] This is redundant with:
> 
>    Clients send packets bound to connections eligible to the conversion
>    service to the provisioned Transport Converter using TBA as
>    destination port number.
> 
> > The Converter reads, for data arriving on port TBA, the first bytes of
> > the bytestream. If the first 32 bytes are not the convert fixed header
> > (Section 4.1), then the Converter looks up (IP address x, port a)
> 
> [Med] The lookup on (IP address x, port a) will fail for MPTCP if a
> secondary subflow is used.
> 
>  to
> > discover the server's (IP address z, port c) and what TCP extensions
> > are
> 
> [Med] All what the converter needs to do in this step is to determine the
> downstream connection.
> 
> > in use over the two TCP connections (for example, no TCP extension and
> > Multipath TCP). It then forwards the data to the Server (from: IP
> > address y, port TBA
> 
> [Med] No. The source IP address may be a distinct address than "y"
> (typically, when a pool of IP addresses is provisioned to the converter).
> Also, the source port is not TBA, it may be the one used by the Client or
> a new one assigned by the Converter if address sharing is used.
> 
> to: IP address z, port c) and modifies TCP extensions as
> > necessary.
> >
> > If the Converter finds no entry for (IP address x, port a) then it
> > SHOULD close the connection with the client.
> >
> 
> [Med] The lookup is not necessary on (IP address x, port a) (think about
> the MPTCP case). The external behavior is that the Converter must silently
> discard the message if no upstream connection is found. How the lookup is
> made is internal to the Converter.
> 
> > A similar process happens for data sent from the server. The converter
> > again acts as a TCP proxy and sends the data to the client.
> >
> > Since the Converter is an endpoint for both of the TCP connections, it
> > has to perform congestion control, error recovery and so on, and
> > buffers data if the outgoing connection is slower than the incoming one.
> 
> [Med] Do we really need to say this?
> 
> >
> > Note that the use of a Transport Converter means that there is no
> > end-to- end transport connection between the Client and Server.
> 
> [Med] Will add this.
> 
>  This could
> > potentially create problems in some scenarios, for example a failure
> > mode of the Converter where data was correctly received by the
> > converter from the client, but then it failed to forward the data on to
> the server.
> 
> [Med] This is not an issue for the Converter because it can inform the
> client by means of Network Failure (65) or Destination Unreachable (97).
> The Client can react to this error. This is not possible with PEPs.
> 
> > Similar issues are discussed in [PEP rfc]. The end point, or their
> > network administrator, can assess the benefit provided by the
> > Converter service versus the risk. This is one reason why the
> > Converter functionality has to be explicitly requested by the end point.
> > --
> >
> > I think the above should in any case be expanded for the two address
> > modes.
> 
> [Med] These are deployment considerations that are not required to
> implement the Convert Protocol.
> 
> > But anyway, I have a question about the text in your email:-
> >
> > <<
> > * The address sharing mode assumes that the converter uses a pool of
> > IP addresses to service the clients. That is, the external IP address
> > of packets relayed by the converter will belong to that pool. For
> > incoming packets, the converter will need to systematically rewrite
> > the destination IP address.
> > * The address preservation mode assumes that the converter will use
> > one of the client's IP addresses as source address when relaying
> > packets. For incoming packets, the converter does not need to rewrite
> > the destination address for the TCP case. For the MPTCP case, the
> > converter will rewrite the destination address of incoming packets
> > only if a subflow not bound to the preserved address is used to relay
> data.
> > >>
> >
> > For the address preservation mode, if the converter doesn't re-write
> > the destination address, does this require that the converter is
> > somehow guaranteed to be on the default path?
> 
> [Med] As noted in the draft-nam-mptcp-deployment-considerations, routing
> tweaks are needed to intercept incoming packets.
> 
> >
> > Thanks
> > phil
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > Sent: 04 September 2019 15:32
> > To: Eardley,PL,Philip,TUD1 R <[e-mail]>;
> > Michael.Scharf@hs- esslingen.de; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: WGLC comments addressed in draft-ietf-tcpm-converters-09?
> >
> > Hi Phil,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : [e-mail] [mailto:[e-mail]] Envoyé :
> > > mercredi 21 août 2019 18:19 À : BOUCADAIR Mohamed TGI/OLN;
> > > [e-mail]; [e-mail] Cc :
> > > [e-mail] Objet : RE: WGLC comments addressed in
> > > draft-ietf-tcpm-converters-09?
> > >
> > > Med,
> > > Coming back to this after hols...
> > > Thanks for the updates. In-line.
> > > phil
> > >
> > > > -----Message d'origine-----
> > > > De : tcpm [mailto:[e-mail]] De la part de
> > > > [e-mail] Envoyé : jeudi 1 août 2019 10:58 À :
> > > > [e-mail]; [e-mail];
> > > > [e-mail] Cc : [e-mail] Objet : Re: [tcpm] WGLC
> > > > comments addressed in draft-ietf-tcpm-converters- 09?
> > > >
> > > > Phil,
> > > >
> > > > I prepared an updated version with the following changes to
> > > > address your remaining comments:
> > > >
> > > > * Position Figure 1 right after the text about upstream/downstream
> > > > connections to avoid the confusion about the direction.
> > >
> > > [phil] thanks, this certainly helps. It's a shame that the two
> > > bullets that actually define upstream / downstream connection are
> > > several pages later at the bottom of page 9 (can it be moved?).
> >
> > [Med] The pointer to Figure 1 is sufficient IMO to understand what is
> > meant by upstream/downstream connections. This is a matter of
> > editorial taste.
> >
> > > One could also be pedantic about Figure 1 ("upstream" should be
> > > "upstream connection"; there's a missing space to the left of "Server"
> > > ;
> >
> > [Med] Can be fixed.
> >
> >  the two
> > > interfaces are kind of below the Converter - Fig 1 seems to be a
> > > physical boxes picture rather than a protocol pic). I know what you
> > > mean and asci art is tricky, and maybe it's ok or the rfc editor
> > > will
> > have suggestions.
> > >
> > > > * Delete "(1)" from Figure 5 caption
> > > > * Add text to clarify why "eventually" is used in the text.
> > > > Rearranged the text about address preservation/sharing modes,
> > accordingly.
> > >
> > > I like that you moved the para about address preservation /sharing,
> > > so that it appears a bit earlier.
> > > The sentence about "eventually" is, for me, no clearer - sorry.
> > > Can't you just explain the two address modes one at a time?
> >
> > [Med] The converter can behave in address preservation or address
> > sharing
> > modes:
> > * The address sharing mode assumes that the converter uses a pool of
> > IP addresses to service the clients. That is, the external IP address
> > of packets relayed by the converter will belong to that pool. For
> > incoming packets, the converter will need to systematically rewrite
> > the destination IP address.
> > * The address preservation mode assumes that the converter will use
> > one of the client's IP addresses as source address when relaying
> > packets. For incoming packets, the converter does not need to rewrite
> > the destination address for the TCP case. For the MPTCP case, the
> > converter will rewrite the destination address of incoming packets
> > only if a subflow not bound to the preserved address is used to relay
> data.
> >
> > These considerations are deployment-specific. A pointer to an external
> > document is provided for further information.
> >
> > >
> > > > * Section 3.2: remove the text about inserting Convert TLVs in
> > > > "subsequent messages".
> > > > * Section 3.3: add finally a side not to remind that RST does not
> > > > close an MPTCP connection, and hence is not reflected by the
> > > > converter on the TCP connection.
> > >
> > > Thanks
> > >
> > > > * Section 4 (Introduction): Clarified that both control and data
> > > > messages are sent over a relayed connection. I hesitated to add
> > > > the NEW text you proposed about relaying connections, but finally
> > > > discarded it because the behavior is already described in many
> > > > places in the documents. No need to be redundant.
> > >
> > > I still think that the actual basic operation of the converter for
> > > data packets is weakly described (assuming the description is just
> > > in this document and not somewhere else)
> > >
> > > S3.2 Theory of operation says " Any user data received by the
> > > Transport Converter over the upstream (or downstream) connection is
> > > relayed over the downstream (or upstream) connection." This is fine
> > > as a high level summary.
> >
> > [Med] This is all what the converter has to do with user data.
> >
> > > S4 is really about the control protocol messages, not the data plane.
> > > But it does say: " By default, the Transport Converter listens on
> > > TCP port number TBA  for Convert messages from Clients.  Clients
> > > send packets bound to connections eligible to the conversion service
> > > to the provisioned Transport Converter using TBA as destination port
> number.
> > > This applies for both control and data messages."
> > > As far as I can see, you don't actually say what the converter does
> > > with the data packets. Perhaps it is obvious, but it surely should
> > > be
> > stated.
> >
> > [Med] Already stated in Section 3. We don't have any additional
> > behavior to specify.
> >
> > > The behaviour for the other direction should be stated.
> >
> > [Med] Already covered in section 3. Section 4 is about the description
> > of Convert messages (which apply for both directions).
> >
> >  And some statement
> > > about the behaviour in the address preservation /sharing modes.
> >
> > [Med] How address sharing/preservation is implemented is out of scope.
> > That's said, the document includes a key requirement when address
> > sharing is used (Section 3).
> >
> > Also, what
> > > is done (MUST /SHOULD /MAY) if there's no 'conversion entry' for
> > > this client. Perhaps this can be partially done with a reference to
> > > a proxy RFC (presumably that would be an extra Normative ref).
> >
> > [Med] Do we really need to say that packets are discarded when no
> > entry is found? Especially, that the text in Section 3 says the
> following:
> >
> > "If the check is successful, ..."
> >
> > And
> >
> > "  Then, when the Converter receives an incoming SYN, it checks its
> >    mapping table to verify if there is an active mapping matching the
> >    destination IP address and destination port of that SYN.  If an entry
> >    is found, ..."
> >
> > > On minor points, I'd describe the data plane operation in its own
> > > sub- section.
> >
> > [Med] I don't think this is needed. Section 3 does already include the
> > required details.
> >
> > I'd say "data" rather than "data messages".
> >
> > [Med] Agree.
> >
> > >
> > > > * Update Figures 11/19
> > > > * Add an appendix to record the design considerations from the
> > > > changes log.
> > >
> > > Thanks
> > > phil
> > >
> > > >
> > > > I also made some other edits to fix some nits.
> > > >
> > > > You may check the full diff at:
> > > > https://www.ietf.org/rfcdiff?url1=draft-
> > > > ietf-tcpm-converters-09&url2=draft-ietf-tcpm-converters-10
> > > >
> > > > Thank you for the review.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > Sent: 01 August 2019 09:58
> > > To: Eardley,PL,Philip,TUD1 R <[e-mail]>;
> > > Michael.Scharf@hs- esslingen.de; [e-mail]
> > > Cc: [e-mail]
> > > Subject: RE: WGLC comments addressed in draft-ietf-tcpm-converters-09?
> > >
> > > Phil,
> > >
> > > I prepared an updated version with the following changes to address
> > > your remaining comments:
> > >
> > > * Position Figure 1 right after the text about upstream/downstream
> > > connections to avoid the confusion about the direction.
> > > * Delete "(1)" from Figure 5 caption
> > > * Add text to clarify why "eventually" is used in the text.
> > > Rearranged the text about address preservation/sharing modes,
> accordingly.
> > > * Section 3.2: remove the text about inserting Convert TLVs in
> > > "subsequent messages".
> > > * Section 3.3: add finally a side not to remind that RST does not
> > > close an MPTCP connection, and hence is not reflected by the
> > > converter on the TCP connection.
> > > * Section 4 (Introduction): Clarified that both control and data
> > > messages are sent over a relayed connection. I hesitated to add the
> > > NEW text you proposed about relaying connections, but finally
> > > discarded it because the behavior is already described in many
> > > places in the documents. No need to be redundant.
> > > * Update Figures 11/19
> > > * Add an appendix to record the design considerations from the
> > > changes log.
> > >
> > > I also made some other edits to fix some nits.
> > >
> > > You may check the full diff at:
> > > https://www.ietf.org/rfcdiff?url1=draft-
> > > ietf-tcpm-converters-09&url2=draft-ietf-tcpm-converters-10
> > >
> > > Thank you for the review.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : tcpm [mailto:[e-mail]] De la part de
> > > > [e-mail] Envoyé : mercredi 31 juillet 2019
> > > > 14:22 À
> > > > : [e-mail]; [e-mail];
> > > > [e-mail] Cc : [e-mail] Objet : Re: [tcpm] WGLC
> > > > comments addressed in draft-ietf-tcpm-converters- 09?
> > > >
> > > > Hi Phil,
> > > >
> > > > Thank you for double checking.
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : tcpm [mailto:[e-mail]] De la part de
> > > > > [e-mail] Envoyé : mercredi 31 juillet 2019 12:26 À :
> > > > > [e-mail]; [e-mail] Cc :
> > > > > [e-mail] 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.
> > > >
> > > >    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."
> > > >
> > > > 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:
> > > > > -------> upstream direction (outgoing connections)
> > > > > <------ downstream direction (incoming connections)
> > > > >
> > > >
> > > > [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.
> > > >
> > > > >
> > > > > Above Figure 6
> > > > > <<addresses and, eventually, the destination IP address and port
> > > number"
> > > > > 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).
> > > >
> > > > >
> > > > > 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)
> > > >
> > > > [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.
> > > >
> > > > > 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?
> > > >
> > > > [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
> > > > > a subsequent packet.
> > > >
> > > > [Med] The initial wording is correct.
> > > >
> > > > > 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).
> > > >
> > > > [Med] No problem (even if the last sentence is already stated in
> > > > previous sections).
> > > >
> > > > > >>
> > > > >
> > > > >
> > > > > 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)
> > > >
> > > > [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.
> > > >
> > > > >
> > > > > 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.)
> > > >
> > > > [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.
> > > >
> > > > > 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?
> > > >
> > > > [Med] Yes.
> > > >
> > > > >
> > > > > <<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.
> > > >
> > > > [Med] OK, added a new appendix to cover the key points.
> > > >
> > > > >
> > > > > Best wishes,
> > > > > phil
> > > > >
> > > > > -----Original Message-----
> > > > > From: Scharf, Michael [mailto:[e-mail]]
> > > > > Sent: 22 July 2019 09:01
> > > > > To: Eardley,PL,Philip,TUD1 R <[e-mail]>
> > > > > Cc: [e-mail]
> > > > > 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 <[e-mail]> On Behalf Of
> > > > > [e-mail]
> > > > > Sent: Monday, July 22, 2019 8:04 AM
> > > > > To: [e-mail]
> > > > > Cc: [e-mail]
> > > > > 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
> > > > > -0
> > > > > 9
> > > > >
> > > > > 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
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/tcpm
> > > > >
> > > > > _______________________________________________
> > > > > tcpm mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/tcpm
> > > >
> > > > _______________________________________________
> > > > tcpm mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/tcpm