Re: [tcpm] WGLC comments addressed in draft-ietf-tcpm-converters-09?
<mohamed.boucadair@orange.com> Fri, 04 October 2019 07:42 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 998A312002E; Fri, 4 Oct 2019 00:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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] 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 MiGxixI89vyw; Fri, 4 Oct 2019 00:42:29 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8E4120018; Fri, 4 Oct 2019 00:42:29 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 46l2034PXmzFq2M; Fri, 4 Oct 2019 09:42:27 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 46l2032x1jzCqkN; Fri, 4 Oct 2019 09:42:27 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d%21]) with mapi id 14.03.0468.000; Fri, 4 Oct 2019 09:42:27 +0200
From: mohamed.boucadair@orange.com
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "philip.eardley@bt.com" <philip.eardley@bt.com>, "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/AAm59BqABtWARIADZZt2AAIPmgnA=
Date: Fri, 04 Oct 2019 07:42:26 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933031338BA6@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> <787AE7BB302AE849A7480A190F8B93303132774E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D4746EE@rznt8114.rznt.rzdir.fht-esslingen.de>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4746EE@rznt8114.rznt.rzdir.fht-esslingen.de>
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/IK28uY-wyFlYVUasokcgKxMwS0A>
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, 04 Oct 2019 07:42:35 -0000
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:Michael.Scharf@hs-esslingen.de] > Envoyé : mardi 1 octobre 2019 19:23 > À : BOUCADAIR Mohamed TGI/OLN; philip.eardley@bt.com; tcpm@ietf.org > Cc : tcpm-chairs@ietf.org > 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: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com> > > Sent: Friday, September 27, 2019 11:08 AM > > To: philip.eardley@bt.com; Scharf, Michael <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, > > > > 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