Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converters-09?
<mohamed.boucadair@orange.com> Fri, 27 September 2019 09:08 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04F12009C; Fri, 27 Sep 2019 02:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il63Pesh68pZ; Fri, 27 Sep 2019 02:08:25 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5EE120024; Fri, 27 Sep 2019 02:08:25 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 46fmDR3dYgz1yHX; Fri, 27 Sep 2019 11:08:23 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 46fmDR2R3kzyPk; Fri, 27 Sep 2019 11:08:23 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([fe80::34b6:11d0:147f:6560%21]) with mapi id 14.03.0468.000; Fri, 27 Sep 2019 11:08:23 +0200
From: mohamed.boucadair@orange.com
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "Michael.Scharf@hs-esslingen.de" <Michael.Scharf@hs-esslingen.de>, "tcpm@ietf.org" <tcpm@ietf.org>
CC: "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
Thread-Topic: WGLC comments addressed in draft-ietf-tcpm-converters-09?
Thread-Index: AdVAY18GkuWfECVqQWaaLZInx1aQaQHJQcVQAAH6llAALWUTAAP9U2QAArkhrTAAONYfcAAftv/AAm59BqABtWARIA==
Date: Fri, 27 Sep 2019 09:08:22 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93303132774E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <6EC6417807D9754DA64F3087E2E2E03E2D3C0FC8@rznt8114.rznt.rzdir.fht-esslingen.de> <CWXP123MB2583E113996E40BCC57F62FBEBDF0@CWXP123MB2583.GBRP123.PROD.OUTLOOK.COM> <787AE7BB302AE849A7480A190F8B9330312ECAD3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312F9DD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <LNXP123MB25870E38482B5A045323ABEBEBAA0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM> <787AE7BB302AE849A7480A190F8B93303130B945@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <LNXP123MB2587A9B7D20B9BB53997D218EBBB0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM> <787AE7BB302AE849A7480A190F8B93303131A663@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <LNXP123MB2587A1D04B066B9F0D12A542EB8E0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <LNXP123MB2587A1D04B066B9F0D12A542EB8E0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/E_OZYNKnzDVXYCZfXHxABEKgwD4>
Subject: Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converters-09?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2019 09:08:29 -0000
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 : philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Envoyé : mercredi 18 septembre 2019 18:14 > À : BOUCADAIR Mohamed TGI/OLN; Michael.Scharf@hs-esslingen.de; > tcpm@ietf.org > Cc : tcpm-chairs@ietf.org > 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: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: 06 September 2019 12:45 > To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>; Michael.Scharf@hs- > esslingen.de; tcpm@ietf.org > Cc: tcpm-chairs@ietf.org > Subject: RE: WGLC comments addressed in draft-ietf-tcpm-converters-09? > > Hi Phil, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : philip.eardley@bt.com [mailto:philip.eardley@bt.com] Envoyé : > > jeudi 5 septembre 2019 18:03 À : BOUCADAIR Mohamed TGI/OLN; > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc : > > tcpm-chairs@ietf.org 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: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: 04 September 2019 15:32 > > To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>; > > Michael.Scharf@hs- esslingen.de; tcpm@ietf.org > > Cc: tcpm-chairs@ietf.org > > Subject: RE: WGLC comments addressed in draft-ietf-tcpm-converters-09? > > > > Hi Phil, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : philip.eardley@bt.com [mailto:philip.eardley@bt.com] Envoyé : > > > mercredi 21 août 2019 18:19 À : BOUCADAIR Mohamed TGI/OLN; > > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc : > > > tcpm-chairs@ietf.org 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:tcpm-bounces@ietf.org] De la part de > > > > mohamed.boucadair@orange.com Envoyé : jeudi 1 août 2019 10:58 À : > > > > philip.eardley@bt.com; Michael.Scharf@hs-esslingen.de; > > > > tcpm@ietf.org Cc : tcpm-chairs@ietf.org 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: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: 01 August 2019 09:58 > > > To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>; > > > Michael.Scharf@hs- esslingen.de; tcpm@ietf.org > > > Cc: tcpm-chairs@ietf.org > > > 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:tcpm-bounces@ietf.org] De la part de > > > > mohamed.boucadair@orange.com Envoyé : mercredi 31 juillet 2019 > > > > 14:22 À > > > > : philip.eardley@bt.com; Michael.Scharf@hs-esslingen.de; > > > > tcpm@ietf.org Cc : tcpm-chairs@ietf.org 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:tcpm-bounces@ietf.org] De la part de > > > > > philip.eardley@bt.com Envoyé : mercredi 31 juillet 2019 12:26 À : > > > > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc : > > > > > tcpm-chairs@ietf.org 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:Michael.Scharf@hs-esslingen.de] > > > > > Sent: 22 July 2019 09:01 > > > > > To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com> > > > > > Cc: tcpm-chairs@ietf.org > > > > > 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 <tcpm-bounces@ietf.org> On Behalf Of > > > > > internet-drafts@ietf.org > > > > > Sent: Monday, July 22, 2019 8:04 AM > > > > > To: i-d-announce@ietf.org > > > > > Cc: tcpm@ietf.org > > > > > 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 > > > > > tcpm@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > > > > _______________________________________________ > > > > > tcpm mailing list > > > > > tcpm@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > > _______________________________________________ > > > > tcpm mailing list > > > > tcpm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tcpm
- Re: [tcpm] WGLC comments addressed in draft-ietf-… philip.eardley
- Re: [tcpm] WGLC comments addressed in draft-ietf-… mohamed.boucadair
- Re: [tcpm] WGLC comments addressed in draft-ietf-… mohamed.boucadair
- Re: [tcpm] WGLC comments addressed in draft-ietf-… philip.eardley
- Re: [tcpm] WGLC comments addressed in draft-ietf-… mohamed.boucadair
- Re: [tcpm] WGLC comments addressed in draft-ietf-… philip.eardley
- Re: [tcpm] WGLC comments addressed in draft-ietf-… mohamed.boucadair
- Re: [tcpm] WGLC comments addressed in draft-ietf-… philip.eardley
- Re: [tcpm] WGLC comments addressed in draft-ietf-… philip.eardley
- Re: [tcpm] WGLC comments addressed in draft-ietf-… mohamed.boucadair
- Re: [tcpm] WGLC comments addressed in draft-ietf-… mohamed.boucadair
- Re: [tcpm] WGLC comments addressed in draft-ietf-… mohamed.boucadair
- Re: [tcpm] WGLC comments addressed in draft-ietf-… Scharf, Michael
- Re: [tcpm] WGLC comments addressed in draft-ietf-… philip.eardley
- Re: [tcpm] WGLC comments addressed in draft-ietf-… mohamed.boucadair