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

["Scharf, Michael" <[e-mail]>]

As my feedback has been requested, here it is...

As documented in the list archive (https://mailarchive.ietf.org/arch/msg/tcpm/LJYpdVKt4Dtp8XL1Obu5W-pw-bg), I have made a similar comment like Phil on describing the handling of data. In an earlier version of the I-D, it also took me some thinking to understand how a convert message is indeed identified, and whether the protocol spec is 100% comprehensive. That may not be obvious to a reader, even if one realizes after some time that the spec is indeed bullet-proof. Given that I ran into a related question myself, I don't think that a short dedicated section on the processing of data would be harmful. I believe for an implementer it would be just useful to have one place describing the proxy behavior (i.e., after the convert protocol messages have been exchanged). That could also include references to other sections, if needed.

Regarding address pools, the current wording of draft-ietf-tcpm-converters-11 is quite hard to understand without reading draft-nam-mptcp-deployment-considerations-01, which is an expired I-D. Yet, I agree that draft-ietf-tcpm-converters should not detail fully deployment-specific issues. I wonder if a short appendix could be added that briefly summarizes the different options and then references draft-nam-mptcp-deployment-considerations-01 for more details? Maybe that would be a compromise?

My 2 cents

Michael
 

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Friday, September 27, 2019 11:08 AM
> To: [e-mail]; Scharf, Michael <[e-mail]>;
> [e-mail]
> Cc: [e-mail]
> Subject: RE: WGLC comments addressed in draft-ietf-tcpm-converters-09?
> 
> 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