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

[<[e-mail]>]

Hi Michael, 

Thank you for sharing your thoughts. Will proceed with your suggestions, i.e.,: 

* add a short section about data processing by the proxy
* add a short appendix with some text about address management. 

Cheers,
Med

> -----Message d'origine-----
> De : Scharf, Michael [mailto:[e-mail]]
> Envoyé : mardi 1 octobre 2019 19:23
> À : BOUCADAIR Mohamed TGI/OLN; [e-mail]; [e-mail]
> Cc : [e-mail]
> Objet : RE: WGLC comments addressed in draft-ietf-tcpm-converters-09?
> 
> 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 <Michael.Scharf@hs-
> esslingen.de>;
> > [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
>