From nobody Tue Oct 1 10:22:53 2019 Return-Path: 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 0385B12082D; Tue, 1 Oct 2019 10:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 pturO0Jv8Lfi; Tue, 1 Oct 2019 10:22:46 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129F2120811; Tue, 1 Oct 2019 10:22:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id CC6D925A14; Tue, 1 Oct 2019 19:22:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1569950563; bh=HUzMzU/q0dlLjcUnu+zF+BNu5OkQxyNbCZMLbcwrHXU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=DUGd6s1lRl5IgLNTvH3Bin6DVAhfS6Dp2hrxJGceVnYs+phfSsQwIkdSHSiVGKuhb TkF949MhjttlRJl7hgha0qFY1NpBJBNFDfBzo3sU6Q+gypBs+6vhI7+KZuFltw2WeH 73QTIUlbWr74t2LO7OTU13kae62Qj6LbjdICHTUQ= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQsgCtpOMcap; Tue, 1 Oct 2019 19:22:41 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 1 Oct 2019 19:22:41 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.252]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Tue, 1 Oct 2019 19:22:40 +0200 From: "Scharf, Michael" To: "mohamed.boucadair@orange.com" , "philip.eardley@bt.com" , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: WGLC comments addressed in draft-ietf-tcpm-converters-09? Thread-Index: AdVAY18GkuWfECVqQWaaLZInx1aQaQHJQcVQAAH6llAALWUTAAP9U2QAArkhrTAAONYfcAAftv/AAm59BqABtWARIADZZt2A Date: Tue, 1 Oct 2019 17:22:40 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4746EE@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D3C0FC8@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B9330312ECAD3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312F9DD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303130B945@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303131A663@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303132774E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303132774E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.63.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 17:22:52 -0000 As my feedback has been requested, here it is... As documented in the list archive (https://mailarchive.ietf.org/arch/msg/tc= pm/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 identi= fied, 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 p= lace describing the proxy behavior (i.e., after the convert protocol messag= es have been exchanged). That could also include references to other sectio= ns, 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-c= onsiderations-01, which is an expired I-D. Yet, I agree that draft-ietf-tcp= m-converters should not detail fully deployment-specific issues. I wonder i= f a short appendix could be added that briefly summarizes the different opt= ions and then references draft-nam-mptcp-deployment-considerations-01 for m= ore details? Maybe that would be a compromise? My 2 cents Michael =20 > -----Original Message----- > From: mohamed.boucadair@orange.com > Sent: Friday, September 27, 2019 11:08 AM > To: philip.eardley@bt.com; Scharf, Michael ; > tcpm@ietf.org > Cc: tcpm-chairs@ietf.org > Subject: RE: WGLC comments addressed in draft-ietf-tcpm-converters-09? >=20 > Phil, >=20 > While waiting for the feedback from Michael, we updated the draft to bett= er > address some of your pending concerns. A diff from the previous version i= s > available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-convert= ers-11 >=20 > 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 ra= tio, > routing/forwarding considerations if an address preservation mode is used= , the > structure of the state entries, etc. These details are really out of scop= e. A > pointer to an external document is provided for readers wanting to have m= ore > information. >=20 > Hope this version is OK to move forward. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Envoy=E9=A0: mercredi 18 septembre 2019 18:14 > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Michael.Scharf@hs-esslingen.de; > > tcpm@ietf.org > > Cc=A0: tcpm-chairs@ietf.org > > Objet=A0: 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 Conve= rt > > 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 corn= er > > cases, but I think a page or two would be better than the current coupl= e > > of lines (which are spread over two sections). I don't think it's obvio= us > > 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 mu= st > > 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 m= y > > 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-t= o- > > 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 ; 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=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Envoy=E9= =A0: > > > jeudi 5 septembre 2019 18:03 =C0=A0: BOUCADAIR Mohamed TGI/OLN; > > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc=A0: > > > tcpm-chairs@ietf.org Objet=A0: 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. a= s > > we have done in: https://tools.ietf.org/html/draft-boucadair-mptcp-plai= n- > > mode-08#section-4.3. That would be a distinct document. This one is abo= ut > > 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 dat= a > > > 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 disc= ard > > 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 connection= s. > > > > [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 o= f > > > the bytestream. If the first 32 bytes are not the convert fixed heade= r > > > (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 t= he > > downstream connection. > > > > > in use over the two TCP connections (for example, no TCP extension an= d > > > 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 abou= t > > the MPTCP case). The external behavior is that the Converter must silen= tly > > 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 converte= r > > > 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, i= t > > > has to perform congestion control, error recovery and so on, and > > > buffers data if the outgoing connection is slower than the incoming o= ne. > > > > [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 poi= nt. > > > -- > > > > > > 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, routin= g > > 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 ; > > > 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=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Envoy= =E9=A0: > > > > mercredi 21 ao=FBt 2019 18:19 =C0=A0: BOUCADAIR Mohamed TGI/OLN; > > > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc=A0: > > > > tcpm-chairs@ietf.org Objet=A0: 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=E9 : jeudi 1 ao=FBt 2019 10:58= =C0 : > > > > > 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/downstrea= m > > > > > 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 "Serv= er" > > > > ; > > > > > > [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 externa= l > > > 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 plan= e. > > > > 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 servic= e > > > > to the provisioned Transport Converter using TBA as destination por= t > > 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 descriptio= n > > > 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 en= try > > > 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 th= e > > > 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=3Ddraft- > > > > > ietf-tcpm-converters-09&url2=3Ddraft-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 ; > > > > 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=3Ddraft- > > > > ietf-tcpm-converters-09&url2=3Ddraft-ietf-tcpm-converters-10 > > > > > > > > Thank you for the review. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > > > > > mohamed.boucadair@orange.com Envoy=E9=A0: mercredi 31 juillet 201= 9 > > > > > 14:22 =C0 > > > > > : philip.eardley@bt.com; Michael.Scharf@hs-esslingen.de; > > > > > tcpm@ietf.org Cc=A0: tcpm-chairs@ietf.org Objet=A0: Re: [tcpm] WG= LC > > > > > comments addressed in draft-ietf-tcpm-converters- 09? > > > > > > > > > > Hi Phil, > > > > > > > > > > Thank you for double checking. > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > > > > > > philip.eardley@bt.com Envoy=E9=A0: mercredi 31 juillet 2019 12:= 26 =C0=A0: > > > > > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc=A0: > > > > > > tcpm-chairs@ietf.org Objet=A0: Re: [tcpm] WGLC comments address= ed > > > > > > 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 > > > > > > < > > > > > 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 numbe= r > > TBA > > > > > for Convert protocol (Convert, for short) messages from Client= s. > > > > > > > > > > Clients send packets that are eligible to the conversion servi= ce > > to > > > > > the provisioned Transport Converter using TBA as destination p= ort > > > > > number. Additional information is supplied by Clients to the > > > > > Transport Converter by means of Convert messages as detailed i= n > > 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 t= he > > > > > Transport Converter. > > > > > > > > > > o the downstream connection is between the Transport Converte= r > > 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 > > > > > > < > > > 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 TC= P > > > > > connection by using FIN segments. > > > > > > > > > > The text covers exclusively the cases that lead to the terminatio= n > > > > > 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 MPTC= P > > > leg). > > > > > > > > > > > > > > > > > Section 4 intro > > > > > > > > > > > > << This section describes the messages that are exchanged betwe= en > > 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 th= e > > > > > > 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 fi= xed > > > > > > 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 I= P > > > > > 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 ma= y > > be > > > > > the same. > > > > > > > > > > > Stress that ALL convert msgs start with the same header. > > > > > > I think the "Clients send packets..." para is better re-arrange= d. > > > > > > > > > > > > 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 essentiall= y > > > > > > the same sentence is repeated two sentences later.) is the ide= a > > > > > > 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. T= he > > > > > payload of this SYN contains the address and port number of th= e > > > > > 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 th= e > > > > > 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 packe= t > > > that > > > > > it sent shortly after the SYN+ACK. > > > > > > > > > > NEW: > > > > > The Client sends a SYN destined to the Transport Converter. T= he > > > > > payload of this SYN contains the address and port number of th= e > > > > > 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 th= e > > > > > Server. > > > > > > > > > > > > > > > > > > > > > > Question: the text says "Clients send packets that are eligible > > > > > > to the conversion service to the provisioned Transport Converte= r > > > > > > 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 se= t > > > > > > to zero by the transmitter and > > > > > > ignored by the receiver. These bits are available for futur= e > > use > > > > > > [RFC8126]." > > > > > > Comment: I heard in ietf-105 about problems for extensibility o= f > > > > > > 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 wit= h > > > > > > 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 t= o > > 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. > > > > > > > > > > > > > > > > > < > > > > > 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, coul= d > > > > > > 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 > > > > > > 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 WGL= C > > > > > comments > > > > > > are addressed? > > > > > > > > > > > > If not, please follow-up on the mailing list. > > > > > > > > > > > > Thanks > > > > > > > > > > > > Michael > > > > > > > > > > > > -----Original Message----- > > > > > > From: tcpm 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 Transpo= rt > > > > > > Converter, to assist the deployment of TCP extensions such a= s > > > > > > 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 prox= y > > 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-converter= s > > > > > > -0 > > > > > > 9 > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-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 From nobody Thu Oct 3 00:50:02 2019 Return-Path: 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 4EBED120825; Thu, 3 Oct 2019 00:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com 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 OypYjvrBvorb; Thu, 3 Oct 2019 00:49:57 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB87120288; Thu, 3 Oct 2019 00:49:56 -0700 (PDT) Received: from tpw09926dag08h.domain1.systemhost.net (10.9.202.47) by RDW083A009ED65.bt.com (10.187.98.35) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 3 Oct 2019 08:45:12 +0100 Received: from tpw09926dag14e.domain1.systemhost.net (10.9.212.14) by tpw09926dag08h.domain1.systemhost.net (10.9.202.47) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 3 Oct 2019 08:49:52 +0100 Received: from bwp09926085.bt.com (10.36.82.116) by tpw09926dag14e.domain1.systemhost.net (10.9.212.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 3 Oct 2019 08:49:52 +0100 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.52) by smtpe1.intersmtp.com (10.36.82.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 3 Oct 2019 08:49:48 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bQJ4LMURoHgEiNjG21DpsfgLopKOaQKrIoHNxBR+7AJrA1/u+ajAd2sfhzEFnrrqHOQcTRjvpBVJt8ZPf9N4UoKLPtPgEMXhhvhllZYMwEMGBdBFe7bx89WN8EeI4o32fiPjga19urufDBVTyShbkFmGwbk+RnTtiTLwhCov9sGSFK8LnOCCMqAxjnih1KP7LjLAgBV6kXhEZUK50LKfQi1uEz+bTrwJc8QsGPL8JVfaiI/t4QdZw3WEuVPjqhlI5DANOOo3Dg/MYta/miglegT9qx9rn+NcAT8Gaj3dyYcRD5cHuAbGdINyGVnSas3sn9j9dntWhwWie9Qfj+0ogw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0nb8Wp7htacZvjDaYtXPuGddDZoNXloPSyIdhSTtrDA=; b=lVchPSlCo2eoAdaQxBKNn7ISl+bvB/3wDFPJJR3DlUD7JTMm5iYzQ0cxibsmKJ9AfSvGT+LvQCRrn/TuOhfwRNUoSeHcdHr5e5wVO4ZzZPQg7eIFuW5Qr6rPbaPmNp8GYWzyE7R7BMkzsKXQsrMWWK8V/serR3Vo7fEmTyS9494RoKYfZG4bpNzlCHGH1WnkPYQMzI5ZnpiZOkkZ1wXte9YjAC1lVkLIIeKnyhW3g7qi6hNhlH4KFRna582YARa0WLumvmVklo3KmdJY57wfK3DrRhALrOp7aIuQGlpouFt31f1aMdOM7DqiKYV6Ac5OQeUPhPxhKIq/XCcTl2OMyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0nb8Wp7htacZvjDaYtXPuGddDZoNXloPSyIdhSTtrDA=; b=YUunxmQArH19FhUmmB0GXPqn/mK1xMLcO0Jg61domN8jM+R1l259dEf1s+7OqK6r8AcJCPodLgUoQnTUSHy5Qdgthqt1m3+Iyq/C/dzEEVdlPd8ye0DL0jAcSbI72GvahJo+5gOaR1Ip8nyLUb+kVMEskFMkPhiVnEC4ljohbuQ= Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB2459.GBRP123.PROD.OUTLOOK.COM (20.179.131.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Thu, 3 Oct 2019 07:49:50 +0000 Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::3c93:795d:a7d6:15c2]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::3c93:795d:a7d6:15c2%5]) with mapi id 15.20.2305.023; Thu, 3 Oct 2019 07:49:50 +0000 From: To: , , CC: Thread-Topic: WGLC comments addressed in draft-ietf-tcpm-converters-09? Thread-Index: AdVAY18GkuWfECVqQWaaLZInx1aQaQHJQcVQAAH6llAALWUTAAP9U2QAArkhrTAAONYfcAAftv/AAm5pb3AAHad1QAGXvS0gASt9MEA= Date: Thu, 3 Oct 2019 07:49:50 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D3C0FC8@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B9330312ECAD3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312F9DD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303130B945@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303131A663@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933031323026@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933031327733@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031327733@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 25da2286-738e-4254-da70-08d747d64569 x-ms-traffictypediagnostic: LNXP123MB2459: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(346002)(136003)(376002)(13464003)(189003)(199004)(71190400001)(71200400001)(316002)(478600001)(256004)(966005)(14444005)(55016002)(74316002)(6436002)(110136005)(9686003)(6306002)(305945005)(7736002)(2501003)(33656002)(229853002)(3846002)(6116002)(66446008)(66476007)(66556008)(66946007)(64756008)(6246003)(8936002)(2906002)(81166006)(81156014)(8676002)(25786009)(76116006)(4326008)(5660300002)(186003)(14454004)(476003)(99286004)(66066001)(26005)(7696005)(76176011)(86362001)(486006)(2201001)(52536014)(102836004)(6506007)(11346002)(53546011)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB2459; H:LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SB/MRtH7CyCqiNyHQpzQOINdeStmfjiQD7VDVicd1xfvqjHY7JMprneFJ3x8rxSq4zxTZsvcSeu2h4IYPEqAXRy5vQQqjy/C7xgPRIcGeTK5Uw+2FO0gfvPCCuniklEILCzZm/ssKrLnqCrG/Zi92GXpzJ32EQs82r/I5RisI9GemO5tpl4zSOvcvvNoGisVG654KAdtNcLBjxLpQEFdpsg7CeKH3GaintWYxFrC8t/EEUVzgEKZ06ePgQIQL7wEpsXrDVxunCE0WCoP26kYwmts1Zx83ousgbTSmM/fHSWEi5sx3f8c37jp2WUjXREJcLGyFx1c9j4BWckDLubtyZ4Qskb/PQ1yGqZJynBslQuCmm5K/GOb9HbNRxXokNgA913K2+lGlB2Nmaf6T79N0GxGUxSusgPqj5ebaiFvRdzICb7PmCBm7v8l5ApjsdaeqSH/YmlMQoPQ832YCDn3kA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 25da2286-738e-4254-da70-08d747d64569 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2019 07:49:50.8073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UDlh3liaw8t6Kn4yc1vpbCq4AG3ppXn+h5E93tpE7AH4T9mXQhmSK7D9ZD6sOMlLm7VxfCqkz/KLTl25J5wl6Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2459 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Report: 4 Rules triggered * 0.1 -- GEN_SPAM_FEATRE * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6646 X-NAI-Spam-Version: 2.2.0.9309 : core <6646> : inlines <7149> : streams <1834526> : uri <2915560> X-OriginatorOrg: bt.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 07:50:00 -0000 Med - Nice one, thanks -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: 27 September 2019 09:56 To: Eardley,PL,Philip,TUD1 R ; Michael.Scharf@hs-ess= lingen.de; tcpm@ietf.org Cc: tcpm-chairs@ietf.org Subject: RE: WGLC comments addressed in draft-ietf-tcpm-converters-09? Hi Phil,=20 We submitted -11 with this NEW text to address your comment:=20 The use of a Transport Converter means that there is no end-to-end transport connection between the client and server. This could potentially create problems in some scenarios such as those discussed in Section 4 of [RFC3135]. Some of these problems may not be applicable, for example, a Transport Converter can inform a client by means of Network Failure (65) or Destination Unreachable (97) error messages (Section 4.2.8) that it encounters a failure problem; the client can react accordingly. An endpoint, or its network administrator, can assess the benefit provided by the Transport Converter service versus the risk. This is one reason why the Transport Converter functionality has to be explicitly requested by an endpoint. Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de=20 > mohamed.boucadair@orange.com Envoy=E9=A0: jeudi 19 septembre 2019 08:20 = =C0=A0 > : philip.eardley@bt.com; Michael.Scharf@hs-esslingen.de; tcpm@ietf.org=20 > Cc=A0: tcpm-chairs@ietf.org Objet=A0: Re: [tcpm] WGLC comments addressed= =20 > in draft-ietf-tcpm-converters- 09? >=20 > Hi Phil, >=20 > Will add these notes. Thanks. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Envoy=E9=A0= :=20 > > mercredi 18 septembre 2019 18:12 =C0=A0: BOUCADAIR Mohamed TGI/OLN;=20 > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc=A0:=20 > > tcpm-chairs@ietf.org Objet=A0: RE: WGLC comments addressed in=20 > > draft-ietf-tcpm-converters-09? > > > > A specific point > > > > -----Original Message----- > > > > > > > > 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=20 > > > failure mode of the Converter where data was correctly received by=20 > > > the converter from the client, but then it failed to forward the=20 > > > data on > to > > the server. > > > > >[Med] This is not an issue for the Converter because it can inform=20 > > >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. > > > > [phil] It would be good to point this out. > > But note this doesn't work if the Converter can't send these msgs.=20 > > The point is that the potential failure modes are slightly different=20 > > for the Converter case vs the e2e transport connection. > > > > >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Oct 3 04:31:37 2019 Return-Path: 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 69E7B120091 for ; Thu, 3 Oct 2019 04:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 X_YFOmgkBodD for ; Thu, 3 Oct 2019 04:31:34 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079C112003F for ; Thu, 3 Oct 2019 04:31:34 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id AAA7B30031; Thu, 3 Oct 2019 14:31:31 +0300 (EEST) Received: from slate.eggert.org (Slate.eggert.org [172.19.235.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 229D6841F08; Thu, 3 Oct 2019 14:31:27 +0300 (EEST) From: Lars Eggert Message-Id: <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_5AE2071B-C548-4E2D-8586-63ECF444A4C9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 3 Oct 2019 14:31:26 +0300 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> Cc: "tcpm@ietf.org" To: "Scharf, Michael" References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> X-MailScanner-ID: 229D6841F08.A42CB X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] On allocating reserved bits in the TCP header X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 11:31:36 -0000 --Apple-Mail=_5AE2071B-C548-4E2D-8586-63ECF444A4C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2019-9-10, at 13:50, Scharf, Michael = wrote: > In my reading of RFC 2780 and RFC 8126, it would be a policy violation = to allocate a bit in the main TCP header to an experiment without a = proper standards track document allowing this experimentation. I am = convinced that for bits in the main TCP header the IETF should just = follow its own rules. Agreed. Lars --Apple-Mail=_5AE2071B-C548-4E2D-8586-63ECF444A4C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl2V3A4ACgkQVLXDCb9w wVfMBxAApQuSNJMW1Zytn+kquhN7pcyZY8m9WooysKczOSACxONP01f9CECbikf4 8DpjssgzquJATSg/ZBuqRfk9Gn/crxewzB8StT9KSWBeHXqutKTS/BrCxfOhwKfG 4KvOUsinshYSoisMADSmc9/NFZR+cuIi9zakMzKZK8qK4qplT45DnSJHqJ6TbBJI vrQOBJHUoADBZ2dCn9h84NiuXfvmuDPM7zY9IDfgohyLAKZ6Ox6XMca4oJIiDyO5 kE/6DkE7rQg5qO2Qx4qzuK6UnDKsZmJuPciM5vbkZlQF6eDwGKdGXX+YVbwHqeHR xof7BWDkYac5h25xXMwbnZCI6uZ3KGqQH5WTo96NBn8Gv4alsUCIQ7ULT1rg3F0O PXEhlsq9Yx8V59rhKeMF9uzP2cCP9SEP3X8r4MmiPvKILmfbqB08/x2FSYGep0Zf 1thqXiMDLR92jyl8zDqig1Di0R9nO5NznQ440PytBi5PYTAhK3h/HJKn4irivFKH qYX9RFbhOhciH4+4BUD8XjyIRn4WPqp9Bs6Wk9rOBQKmInRQPgzfTbExpFrTTFsw kRQ1DRQmDK/JGJ/RHPZ9B+H/9QIUsxqciZSh1/umGVCLP+JhOC1lJxqqPrrN3j9x 8mSlI0WOrSGgV89PFuArQznnDxCWY2jsnmm6zdG9r5TqM8mZ8EI= =WRJy -----END PGP SIGNATURE----- --Apple-Mail=_5AE2071B-C548-4E2D-8586-63ECF444A4C9-- From nobody Fri Oct 4 00:42:36 2019 Return-Path: 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: To: "Scharf, Michael" , "philip.eardley@bt.com" , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: WGLC comments addressed in draft-ietf-tcpm-converters-09? Thread-Index: AdVAY18GkuWfECVqQWaaLZInx1aQaQHJQcVQAAH6llAALWUTAAP9U2QAArkhrTAAONYfcAAftv/AAm59BqABtWARIADZZt2AAIPmgnA= Date: Fri, 4 Oct 2019 07:42:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031338BA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2D3C0FC8@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B9330312ECAD3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312F9DD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303130B945@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303131A663@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 07:42:35 -0000 Hi Michael,=20 Thank you for sharing your thoughts. Will proceed with your suggestions, i.= e.,:=20 * add a short section about data processing by the proxy * add a short appendix with some text about address management.=20 Cheers, Med > -----Message d'origine----- > De=A0: Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] > Envoy=E9=A0: mardi 1 octobre 2019 19:23 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; philip.eardley@bt.com; tcpm@ietf.org > Cc=A0: tcpm-chairs@ietf.org > Objet=A0: RE: WGLC comments addressed in draft-ietf-tcpm-converters-09? >=20 > As my feedback has been requested, here it is... >=20 > 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. >=20 > 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? >=20 > My 2 cents >=20 > Michael >=20 >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > Sent: Friday, September 27, 2019 11:08 AM > > To: philip.eardley@bt.com; Scharf, Michael 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=3Ddraft-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=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Envoy=E9=A0: mercredi 18 septembre 2019 18:14 > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Michael.Scharf@hs-esslingen.de; > > > tcpm@ietf.org > > > Cc=A0: tcpm-chairs@ietf.org > > > Objet=A0: RE: WGLC comments addressed in draft-ietf-tcpm-converters-0= 9? > > > > > > 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 abou= t > 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 th= e > > > 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 ; > 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=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Envoy= =E9=A0: > > > > jeudi 5 septembre 2019 18:03 =C0=A0: BOUCADAIR Mohamed TGI/OLN; > > > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc=A0: > > > > tcpm-chairs@ietf.org Objet=A0: 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 als= o > > > > 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 th= e > > > > 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 extension= s > > > > 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 Clien= t > 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 looku= p > 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 failur= e > > > > mode of the Converter where data was correctly received by the > > > > converter from the client, but then it failed to forward the data o= n > to > > > the server. > > > > > > [Med] This is not an issue for the Converter because it can inform th= e > > > 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 addres= s > > > > 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 o= f > > > > 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-writ= e > > > > 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 ; > > > > 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=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Envoy= =E9=A0: > > > > > mercredi 21 ao=FBt 2019 18:19 =C0=A0: BOUCADAIR Mohamed TGI/OLN; > > > > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc=A0: > > > > > tcpm-chairs@ietf.org Objet=A0: 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=E9 : jeudi 1 ao=FBt 2019 10:= 58 =C0 > : > > > > > > 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 o= f > > > > 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 dat= a > > > > > > 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 fo= r > > > > > data packets is weakly described (assuming the description is jus= t > > > > > 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 shoul= d > > > > > 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=3Ddraft- > > > > > > ietf-tcpm-converters-09&url2=3Ddraft-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 ; > > > > > 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/downstrea= m > > > > > 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=3Ddraft- > > > > > ietf-tcpm-converters-09&url2=3Ddraft-ietf-tcpm-converters-10 > > > > > > > > > > Thank you for the review. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > > > > > > mohamed.boucadair@orange.com Envoy=E9=A0: mercredi 31 juillet 2= 019 > > > > > > 14:22 =C0 > > > > > > : philip.eardley@bt.com; Michael.Scharf@hs-esslingen.de; > > > > > > tcpm@ietf.org Cc=A0: tcpm-chairs@ietf.org Objet=A0: 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=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > > > > > > > philip.eardley@bt.com Envoy=E9=A0: mercredi 31 juillet 2019 1= 2:26 > =C0=A0: > > > > > > > Michael.Scharf@hs-esslingen.de; tcpm@ietf.org Cc=A0: > > > > > > > tcpm-chairs@ietf.org Objet=A0: 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 > > > > > > > < > > > > > > 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 th= e > > > > > > 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 th= e > > > > > > connection > > > > > > > (in other words, it is an outgoing connection); the scenario > > > > > > > with an incoming connection is discussed in a couple of place= s > > > > [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 > > > > > > > < 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 - sinc= e > > > > > > > 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 end= s > > > 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 th= e > > > > > > > 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 i= t > > > > > > indicated when creating a mapping in the converter to allow for > > > > > > incoming connections. This is needed to demux services hosted o= n > > > > > > 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 th= e > > > > > > > bytestream, either directly in the SYN+ACK or in a subsequent > > > > > > > packet." (this information is "about the TCP options that wer= e > > > > > > > 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 th= e > > > > 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 th= e > > > > 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 t= o > > > > > > > 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 i= n > > > > > > 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 zeroe= s > > > > > > > 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 Conver= t > > > > 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. > > > > > > > > > > > > > > > > > > > > < > > > > > > 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 > > > > > > > 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 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=3Ddraft-ietf-tcpm-converter= s- > 09 > > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the tim= e > > > > > > > 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 >=20 From nobody Fri Oct 4 08:16:12 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 505E61208AF; Fri, 4 Oct 2019 08:16:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <157020217020.1400.989960668789303006@ietfa.amsl.com> Date: Fri, 04 Oct 2019 08:16:10 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 15:16:11 -0000 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-12.txt Pages : 52 Date : 2019-10-04 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. -- Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: [This-RFC] Please update TBA statements with the port number to be assigned to the 0-RTT TCP Convert Protocol. 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-12 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/ From nobody Fri Oct 4 08:19:58 2019 Return-Path: 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 E8B8A1208DB for ; Fri, 4 Oct 2019 08:19:56 -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 vhgEf0NkoJr2 for ; Fri, 4 Oct 2019 08:19:51 -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 A070C1208EE for ; Fri, 4 Oct 2019 08:19:48 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 46lD7l296xz1yBM; Fri, 4 Oct 2019 17:19:47 +0200 (CEST) Received: from localhost.localdomain (unknown [127.0.0.1]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 46lD7l1qDbzyQB; Fri, 4 Oct 2019 17:19:47 +0200 (CEST) Received: from opfednr05.rouen.francetelecom.fr by opfednr05.rouen.francetelecom.fr with queue id 1711958-12; Fri, 04 Oct 2019 15:19:47 GMT Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 46lD7l1S4PzyQH; Fri, 4 Oct 2019 17:19:47 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Fri, 4 Oct 2019 17:19:47 +0200 From: To: "philip.eardley@bt.com" , "Scharf, Michael (Michael.Scharf@hs-esslingen.de)" CC: "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt Thread-Index: AQHVesauwzHu5O3rE0C+qUDcGDDbAqdKmEGw Date: Fri, 4 Oct 2019 15:19:46 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031338ED7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <157020217020.1400.989960668789303006@ietfa.amsl.com> In-Reply-To: <157020217020.1400.989960668789303006@ietfa.amsl.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: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 15:19:57 -0000 Hi Phil, Michael,=20 This version implements the suggestions discussed so far: add a new section= to discuss data processing once a state is created + appendix to discuss a= ddress sharing/preservation modes.=20 I think this version solves the concerns raised by Phil.=20 Looking forward to advance the document.=20 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: vendredi 4 octobre 2019 17:16 > =C0=A0: i-d-announce@ietf.org > Cc=A0: tcpm@ietf.org > Objet=A0: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt >=20 >=20 > 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. >=20 > Title : 0-RTT TCP Convert Protocol > Authors : Olivier Bonaventure > Mohamed Boucadair > Sri Gundavelli > SungHoon Seo > Benjamin Hesmans > Filename : draft-ietf-tcpm-converters-12.txt > Pages : 52 > Date : 2019-10-04 >=20 > 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). >=20 > This specification assumes an explicit model, where the proxy is > explicitly configured on hosts. >=20 > -- Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: [This-RFC] >=20 > Please update TBA statements with the port number to be assigned to > the 0-RTT TCP Convert Protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-converters-12 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-12 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Oct 20 21:08:53 2019 Return-Path: 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 6253A1200C1 for ; Sun, 20 Oct 2019 21:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qoBCCY4bKeeL for ; Sun, 20 Oct 2019 21:08:50 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83DD11200B8 for ; Sun, 20 Oct 2019 21:08:50 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id c2so6887133wrr.10 for ; Sun, 20 Oct 2019 21:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=K44+EnbxEBzCr41wVpYO2CHAOH5vcVw3oVJZ3Ctqe0Q=; b=IkvzGE14+q9w5VYIM+gnLshMx3k9LpIb9yu2eCC9P+MySS6UPFfipwELT3xzen+u3w 4IbvEPRjneRb6DFyflAvYrD1QAnwauszhOw7mAJkaFhP7yZ8J6BLNxMUYw6GxqKyPgwg VQdMO0AXPLHlhFt4JTKDJHtGgZI0ORWQSfysVClqUY74PMQUeemhwQDmT+RrW1zkl8sI GrUxusYzIq9A+mCvkVQ5LtpFIDslUITPvrxiqoOoJEBtj/hB84WpSmZGLwUs+UAFJjOW aj3wbf1SyVqHof/m+pFD6t5HEOI+Q61T7fDLA3eVK7MoyNBNCSgpgc1KKcl7QZs5ZeD/ 9iVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=K44+EnbxEBzCr41wVpYO2CHAOH5vcVw3oVJZ3Ctqe0Q=; b=S2TsBJA6smV9GsMbRfQm40GyBNTJpXQ2wsqY80XkkgqlbVaGXp7/O7MwFlt+ZDQUHE +ryihzoFVZvm5f6OpPOUBhuFbtK/q1GtFtQRouDjbIa7fbAwNjY6hydTXL4MIpzljT3L VTGBdmyfZwr3sN+4tC3saobrJWfYk997hD7sk6vPyHZJuBnaqhxy1tuxrHp7Z4yGm79v QAqgnVI3ZmcgRBijGWLY2BGJTMY4LkZjqteJVpWxj62RC4fOQkU79wazaEw3xcdjResS dJOvplt8BYYB4nSKjVuT03sJes1y06K0O+p+KrXHIBXJDE1eF8ECbDOwhl6b0TLgumKP 2qAQ== X-Gm-Message-State: APjAAAVpAHg+qpyEXUn27iAWLT9L5OkZpcVv3cNsWVQt5f6plW6NvnkO EiRNDM6mAvLAmPBaVCRu+mbfbH1OG9EO/rTOElAfRNPS X-Google-Smtp-Source: APXvYqwJzNrY8aiKIeXQOG6bWEII++Jr+0QfGVuLgH0ZWqA3hyY4zJXnBKMIgRLUOWwgVmRfhQFPYI6lIWNr4c+72UM= X-Received: by 2002:adf:9185:: with SMTP id 5mr742512wri.389.1571630928806; Sun, 20 Oct 2019 21:08:48 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Sun, 20 Oct 2019 21:08:37 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000003aca3c059563d778" Archived-At: Subject: [tcpm] Agenda request for Singapore meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 04:08:52 -0000 --0000000000003aca3c059563d778 Content-Type: text/plain; charset="UTF-8" Hello, According to the current agenda ( https://datatracker.ietf.org/meeting/106/agenda.html), our WG meeting is scheduled on Friday (11/22) 10:00-12:00. (please note this is still preliminary and might be changed later) If you are planning to present something, please let the chairs know the following information. * Title / draft name * Presenter's name * Total time (including Q/A) * Require meetecho support or not Thanks, -- tcpm co-chairs --0000000000003aca3c059563d778 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

According to the current=C2=A0agenda=C2= =A0(https:= //datatracker.ietf.org/meeting/106/agenda.html), our WG meeting is sche= duled on Friday (11/22) 10:00-12:00. (please note this is still preliminary= and might be changed later)
If you are planning to present somet= hing, please let the chairs know the following information.

* Title= / draft name
* Presenter's name
* Total time (including Q/A)
* Require meetecho support or not

Tha= nks,
--
tcpm co-chairs
--0000000000003aca3c059563d778-- From nobody Mon Oct 21 03:37:12 2019 Return-Path: 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 1AB261201DB for ; Mon, 21 Oct 2019 03:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 YevkqDL0mex4 for ; Mon, 21 Oct 2019 03:37:09 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EC71201DC for ; Mon, 21 Oct 2019 03:37:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 293E625A25; Mon, 21 Oct 2019 12:37:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1571654227; bh=nDlUGMCT6SjMSqyV/UBedfSrikZRjTPRgVJNcyZ0D8U=; h=From:To:CC:Subject:Date:From; b=Lr7NFXvV7ANcBgFKKolKe8qNfqUOO21xqq+UYZRI4kdHG8sM1Cxn15Isb2kSFzBTg BKUQKoIsDB5tLB5WRDkE4FD7nHJe4lPKlnqe3mzDmwjevrS26yuA2VCsANpSWH1B61 j93muedS/nGDUG+YyNeAQy2zVjpZabCjtRQ4rSQw= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoZkdTs0_4Ha; Mon, 21 Oct 2019 12:37:06 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 21 Oct 2019 12:37:06 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 21 Oct 2019 12:37:06 +0200 From: "Scharf, Michael" To: Wesley Eddy CC: "tcpm@ietf.org" Thread-Topic: 793bis wording on TCP keep-alives Thread-Index: AdWH+eHSZJ72bo5bT1KmKh8OwI3e1A== Date: Mon, 21 Oct 2019 10:37:05 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4AF868@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] 793bis wording on TCP keep-alives X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 10:37:11 -0000 Hi Wes, after reading Section 3.8.4. "TCP Keep-Alives" in 793bis, I would suggest t= o copy a bit more text from RFC 1122 to better define keep-alives. Background: RFC 1122 does not formally define "keep-alive" in the normative= part, but it mentions implementation behavior in the DISCUSSION text: =20 Some TCP implementations, however, have included a keep-alive mechanism. To confirm that an idle connection is still active, these implementations send a probe segment designed to elicit a response from the peer TCP. Such a segment generally contains SEG.SEQ =3D SND.NXT-1 and may or may not contain one garbage octet of data.=20 =20 In RFC 1122, only this DISCUSSION text describes what a "probe segment" cou= ld be and what "garbage octet" implies. Currently 793bis only copies the normative text from RFC 1122, and therefor= e it does not define these concepts. My proposal would be to copy also the cited text from RFC 1122 to 793bis to= provide more background, e.g., along the lines of: =20 793bis OLD: =20 Implementors MAY include "keep-alives" in their TCP implementations (MAY-5), although this practice is not universally accepted. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection (MUST-24), and they MUST default to off (MUST-25). [... and more sections on probe segments and garbage octet...] =20 793bis NEW: =20 Implementors MAY include "keep-alives" in their TCP implementations (MAY-5), although this practice is not universally accepted. Some TCP implementations, however, have included a keep-alive mechanism. To confirm that an idle connection is still active, these implementation= s send a probe segment designed to elicit a response from the peer TCP. Such a segment generally contains SEG.SEQ =3D SND.NXT-1 and may or may n= ot contain one garbage octet of data. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection (MUST-24), and they MUST default to off (MUST-25). [... rest of existing text...] =20 The additional text is literally taken from RFC 1122 and therefore should n= ot be problematic. Thanks =20 Michael From nobody Mon Oct 21 04:13:29 2019 Return-Path: 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 3525812002E for ; Mon, 21 Oct 2019 04:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 J2GGDQN8VEF8 for ; Mon, 21 Oct 2019 04:13:25 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3952F120013 for ; Mon, 21 Oct 2019 04:13:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 2E38F25A25; Mon, 21 Oct 2019 13:13:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1571656403; bh=AR+a4vr9jt8wJkV+3rxc5CUFdQC+rxYyKAevoHZuxBs=; h=From:To:CC:Subject:Date:From; b=nX2u2OCtzcIjPElUhX0sM+Zh6+xggUDmXQNH1NIGxq2MPWH+NFjUAyg0sl3cvXziZ 5jNyyqbNjE8jSM9zmtxgIaXHAiG09KlqpwEShn0OySMs+whgkfNjcypcvrRKH8PYTa gRNCihX/QSj6y8hEYdqhg7c4r7q2IBWjVBTdTDjY= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDGXdELhlfcv; Mon, 21 Oct 2019 13:13:22 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 21 Oct 2019 13:13:22 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 21 Oct 2019 13:13:21 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" Thread-Topic: New keep-alive text in draft-ietf-netconf-tcp-client-server-03 Thread-Index: AdWIAGYiqBCjfZ91R4qPbWgZa5WWlg== Date: Mon, 21 Oct 2019 11:13:21 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4AF9B7@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] New keep-alive text in draft-ietf-netconf-tcp-client-server-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 11:13:27 -0000 Hi all, As outlined below, the draft draft-ietf-netconf-tcp-client-server was updat= ed. The new version can be found at https://tools.ietf.org/html/draft-ietf-= netconf-tcp-client-server-03 and a diff is available at https://www.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-netconf-tcp-client-server-03 . In the new version, I have tried to address comments from the last TCPM mee= ting. Note that this document is owned the NETCONF working group, but we tr= y to keep TCPM in the loop. In -03, I have drafted a new section with guidance on use of TCP keep-alive= s. It reuses some text from a related earlier discussion on the TSVAREA lis= t: 3.2. Usage Guidelines for Configuring TCP Keep-Alives Network stacks may include "keep-alives" in their TCP implementations, although this practice is not universally accepted. If keep-alives are included, [RFC1122] [RFC793bis] mandates that the application MUST be able to turn them on or off for each TCP connection, and that they MUST default to off. Keep-alive mechanisms exist in many protocols. Depending on the protocol stack, TCP keep-alives may only be one out of several alternatives. Which mechanism to use depends on the use case and application requirements. If keep-alives are needed by an application, it is RECOMMENDED that the aliveness check happens at the highest protocol layer possible that is meaningful to the application, in order to maximize the depth of the aliveness check. A TCP keep-alive mechanism should only be invoked in server applications that might otherwise hang indefinitely and consume resources unnecessarily if a client crashes or aborts a connection during a network failure [RFC1122]. TCP keep-alives may consume significant resources both in the network and in endpoints (e.g., battery power). In addition, frequent keep-alives risk network congestion. The higher the frequency of keep-alives, the higher the overhead. Given the cost of keep-alives, parameters have to be configured carefully: o The default idle interval (leaf "idle-time") MUST default to no less than two hours, i.e., 7200 seconds [RFC1122]. A lower value MAY be configured, but keep-alive messages SHOULD NOT be transmitted more frequently than once every 15 seconds. Longer intervals SHOULD be used when possible. o The maximum number of sequential keep-alive probes that can fail (leaf "max-probes") trades off responsiveness and robustness against packet loss. ACK segments that contain no data are not reliably transmitted by TCP. Consequently, if a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection [RFC1122]. Typically a single-digit number should suffice. o TCP implementations may include a parameter for the number of seconds between TCP keep-alive probes (leaf "probe-interval"). In order to avoid congestion, the time interval between probes MUST NOT be smaller than one second. Significantly longer intervals SHOULD be used. It is important to note that keep-alive probes (or replies) can get dropped due to network congestion. Sending further probe messages into a congested path after a short interval, without backing off timers, could cause harm and result in a congestion collapse. Therefore it is essential to pick a large, conservative value for this interval. The lower bound of 15 seconds is taken from RFC 8085. Also, I have tried to= use text from RFC 1122 as far as possible. Any thoughts? Thanks Michael (as contributor) -----Original Message----- From: Kent Watsen =20 Sent: Saturday, October 19, 2019 12:28 AM To: netconf@ietf.org Cc: Scharf, Michael ; Wang Haiguang ; Frank Xialiang Subject: updates to the client/server suite of drafts Below are the change-logs for the updates just posted. Not yet incorporated: 1. a resolution to the "algorithms" problem in the crypto-types draft. (IANA templates?) 2. an update to the Truststore draft to add support for PSK and raw keys. 3. an update to the Keystore draft to add support for PSK and raw keys. (Henk's response pending) 4. an update to the SSH and TLS drafts to reflect the final outcome to (1). Kent =3D=3D=3D=3D=3D change logs =3D=3D=3D=3D=3D crypto-types: - Added a "key-format" identity. - Added symmetric keys to the example in the Examples section. truststore: - Editorial changes only. keystore: - Updated examples to incorporate new "key-format" identities. - Made the two "generate-*-key" RPCs be "action" statements instead. tcp-client-server: (changes from co-author Micheal Scharf) - Moved the common model section to be before the client and server specific sections. - Added sections "Model Scope" and "Usage Guidelines for Configuring TCP Keep-Alives" to the Common Model section. ssh-client-server: - Updated examples to reflect ietf-crypto-types change (e.g., identities --> enumerations) - Updated "server-authentication" and "client-authentication" nodes from being a leaf of type "ts:host-keys-ref" or=20 "ts:certificates-ref" to a container that uses=20 "ts:local-or-truststore-host-keys-grouping" or=20 "ts:local-or-truststore-certs-grouping". tls-client-server: - Updated "server-authentication" and "client-authentication" nodes from being a leaf of type "ts:certificates-ref" to a container that uses "ts:local-or-truststore-certs-grouping". - Note: this update needed by the TCPM WG. http-client-server: - in ietf-http-client, removed all but the "basic"=20 authentication scheme. - in ietf-http-client, factored out a "client-identity-grouping" grouping, which is now used in both the primary and proxy configuration models. - in ietf-http-server under /client-authentication/local, added an ability to configure authentication credentials for the "basic" authentication scheme. - Note: this update was blocking the adoption call from before. netconf-client-server: - Refactored both the client and server modules similar to how the ietf-restconf-server module was refactored in -13=20 presented in Montreal. restconf-client-server: - Refactored both the client and server modules similar to how the ietf-restconf-server module was refactored in -13=20 presented in Montreal. - Added missing "or https-listen" clause in a "must" expression. Kent // contributor From nobody Mon Oct 21 06:10:15 2019 Return-Path: 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 23B31120033 for ; Mon, 21 Oct 2019 06:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com 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 R7_QfHd4WInn for ; Mon, 21 Oct 2019 06:10:10 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0656A12004D for ; Mon, 21 Oct 2019 06:10:10 -0700 (PDT) Received: from tpw09926dag11f.domain1.systemhost.net (10.9.212.19) by BWP09926082.bt.com (10.36.82.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Mon, 21 Oct 2019 14:10:04 +0100 Received: from tpw09926dag18g.domain1.systemhost.net (10.9.212.34) by tpw09926dag11f.domain1.systemhost.net (10.9.212.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 21 Oct 2019 14:10:07 +0100 Received: from bwp09926079.bt.com (10.36.82.110) by tpw09926dag18g.domain1.systemhost.net (10.9.212.34) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 21 Oct 2019 14:10:07 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.52) by smtpe1.intersmtp.com (10.36.82.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Mon, 21 Oct 2019 14:10:05 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nz7cujndNJKZrhzN2vHsDvuP5jiWPVUycNKpwl+veqjMT/Fp6y+vssKHxPCAJTeQzvWaRAmhSjqOkjR6tVdFpz3pUPX93NGHBAK9MycV7FWvd3bbxDCPQiabGEmXlSNy8pE/hRgW0NQHeA1P3aTgG5UtWFj4y7JQCfhHoms2t32FDAp8j+u53INfGKkjboGGFqMMPcXY0QOPu/mG2uMgLKNCT6hcWI9ki+mp0535FwNXcZzpTrKF1qYQNtHLq+uK5OxLxTY1y2gdPvBvKC7yMKHRlgmiDQy6UIjxn3IDIbqoLqoXpWeNIs3gc/keBWPWCwEOrPIdepDsoymhA+RWRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qG+tXSlMwMpcp+DzLwININj8OA/kWrul3mL7ArNFY9A=; b=TCjuOp/oNm2p8c2ctUoTyJ8xOVuRx92ZHfKhuVazm4zYnRhZQdED5sz5+c8uoGCpvxNvMzinBIeNz3EKkBmrCpgMWLnc+/zUXgAlBAgbicqZwkF04f5PmSr017rgqysTJH9OfBTNU8TJUs/Kpd5ufUK1MEbdY2hGLhz6YfvhtcbobIfxL2BA0ZlFYq5+BYs80MRtl/lrWacdHAYAgfvcs5hMXdJF9SuU1EPHcOmRN+vDlD+em3LiZHYaWwAxNusklcYw09Q4NDSl6kQtAYksaje0RNV2q2ISRpk+XXaro63ec9JfORrQolNwZ3NE5TDkxqVR9B3Hyh147DJQ80TcFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qG+tXSlMwMpcp+DzLwININj8OA/kWrul3mL7ArNFY9A=; b=TQxvOmrJ+2SA9gtJqoi+vy9YbuF2tizmcnhqpSfaAkFrPWP11b6mHBX32E33UTZKvVqHPqnFsh0uVQk2CmMcE+Xr1+V8dbrTcJVjQjAHqep4NyZPLRhhUhxt2lnSmwPfQqlpMw8D2UyBfiixIv5vPflPjiYLcUwO88Unb0SZNO0= Received: from CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM (20.176.58.79) by CWLSPR01MB0010.GBRP123.PROD.OUTLOOK.COM (20.176.40.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.20; Mon, 21 Oct 2019 13:10:06 +0000 Received: from CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM ([fe80::5c43:4d65:4081:f8a8]) by CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM ([fe80::5c43:4d65:4081:f8a8%5]) with mapi id 15.20.2347.029; Mon, 21 Oct 2019 13:10:05 +0000 From: To: , CC: Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt Thread-Index: AQHVesazxMnJ0MpTtUGYTCO0/wPXnKdKmMEAgBqMdbA= Date: Mon, 21 Oct 2019 13:10:04 +0000 Message-ID: References: <157020217020.1400.989960668789303006@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933031338ED7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031338ED7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f99fd45-736a-47f7-d864-08d75627fd63 x-ms-traffictypediagnostic: CWLSPR01MB0010: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0197AFBD92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(39860400002)(346002)(366004)(136003)(189003)(199004)(13464003)(66476007)(476003)(71190400001)(256004)(66556008)(305945005)(66946007)(76116006)(26005)(76176011)(316002)(7696005)(53546011)(6506007)(110136005)(11346002)(446003)(99286004)(102836004)(14444005)(64756008)(66446008)(6246003)(9686003)(8676002)(6436002)(81156014)(81166006)(2501003)(66574012)(55016002)(6306002)(71200400001)(486006)(25786009)(7736002)(229853002)(966005)(5660300002)(8936002)(52536014)(74316002)(3846002)(14454004)(6116002)(186003)(66066001)(478600001)(4326008)(33656002)(86362001)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:CWLSPR01MB0010; H:CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eUrHxl4nZOZblIkTC5c6Ro53mW79FXv3CRKy4qrdSulgG/GbzOOVTkBCTXDXtlbqaCTeel5UavBG65tqSDzTN3zptW/WxIpN7Z8kHDwvsS0WdeP/7SRSdO9xafKLKlXK1TmYovDPN8NDMvWPiFcsBg6SFv9YIyAvGhB6LYGZrBIFVCd6wg2pZn1oG4hBeB2/QA4IwaBdQylCdtUNEMEet1M5/L7ODZURli85mUHhnfQ0aeziMHvNAyGB1grurkG/j2pZEZ3lsdlbYCBJQsRdeEuOkgDme5dWaZHlXHicS6Vo4iDRsE7GZBMpb08Kt8P5R4F13ok8jKYA+Q2eT3CjAMhmdNvGVAQOky1lOmcRekPvnxdHq586RNrnZjghuUkUKIAa2CS1rdhUjSxAGw0CIRQqMSHv/VUovMS3b6Z4I/lPX97zlocsX0+2pQ50rwdOO/Hc85Rc1jipVFr8fiL0xpX2qxfISjqgSTk5OxNL81k= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5f99fd45-736a-47f7-d864-08d75627fd63 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2019 13:10:04.9807 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p0WGKjbWYiO8ow8jTlgeiMies4A75eh0mx1gYV05MGEtl769h17igePOv8bnKCB0dod2a+E1dc9mL/nuTNvj3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLSPR01MB0010 X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Report: 3 Rules triggered * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6659 X-NAI-Spam-Version: 2.2.0.9309 : core <6659> : inlines <7155> : streams <1836268> : uri <2925444> X-OriginatorOrg: bt.com Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 13:10:13 -0000 Med, Thanks for creating these new pieces of text, I think they're helpful and i= t's looking good! Comments: Section 3.3 <> Better: User data is unambiguously distinguished from Convert TLVs by a Transport C= onverter by the Convert Fixed Header (Figure 12) in the Convert messages In Section 3.3, I think you should move the text about MPTCP out of S3.3 (i= nto S3.4, maybe with some renumbering of S3.4 & 3.5 to make a section about= mptcp) [this is the text "Note that for the Multipath TCP case..." to the Figure 8= caption and the bullet "In reference to Figure 8"] Reason: handle the general case first, then the MPTCP variant.=20 << Note that for the Multipath TCP case, the Transport Converter identifies= an MPTCP connection by means, e.g., of the token assigned to the MPTCP con= nection.>> If I get it right, this is nothing to do with the token defined in MPTCP, b= ut is simply an identifier internal to the Converter (to help it keep toget= her entries for the same Client). Ie this token is not seen on the wire. Pl= ease could you re-phrase the para and the definition of "token" in the Figu= re 8 caption.=20 Section 4.1 In the Figure 12 caption, I suggest deleting "-Sized" (so: "Figure 12: The = Fixed Header of the Convert Protocol" or even "Figure 12: The Convert Fixed= Header") Section D.2 Appendix D.1 has a final paragraph which doesn't appear at the end of D.2 (= <>) I assume the same text is true for the IPv4 address sharing model. I sugges= t adding a comment at the end of D.2 that the same considerations apply (or= repeating the paragraph, possibly with "IP address" changed to "IP address= prefix") I also suggest changing the title "IPv4 Address Sharing" to "Address Sharin= g" Best wishes, phil -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: 04 October 2019 16:20 To: Eardley,PL,Philip,TUD1 R ; Scharf, Michael (Mich= ael.Scharf@hs-esslingen.de) Cc: tcpm@ietf.org Subject: RE: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt Hi Phil, Michael,=20 This version implements the suggestions discussed so far: add a new section= to discuss data processing once a state is created + appendix to discuss a= ddress sharing/preservation modes.=20 I think this version solves the concerns raised by Phil.=20 Looking forward to advance the document.=20 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de internet-=20 > drafts@ietf.org Envoy=E9=A0: vendredi 4 octobre 2019 17:16 =C0=A0:=20 > i-d-announce@ietf.org Cc=A0: tcpm@ietf.org Objet=A0: [tcpm] I-D Action:=20 > draft-ietf-tcpm-converters-12.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the TCP Maintenance and Minor Extensions=20 > WG of the IETF. >=20 > Title : 0-RTT TCP Convert Protocol > Authors : Olivier Bonaventure > Mohamed Boucadair > Sri Gundavelli > SungHoon Seo > Benjamin Hesmans > Filename : draft-ietf-tcpm-converters-12.txt > Pages : 52 > Date : 2019-10-04 >=20 > 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). >=20 > This specification assumes an explicit model, where the proxy is > explicitly configured on hosts. >=20 > -- Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: [This-RFC] >=20 > Please update TBA statements with the port number to be assigned to > the 0-RTT TCP Convert Protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-converters-12 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-12 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Oct 21 06:59:40 2019 Return-Path: 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 2C9371200C4 for ; Mon, 21 Oct 2019 06:59:39 -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 7UKWaLUQeBkc for ; Mon, 21 Oct 2019 06:59:36 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345791200A3 for ; Mon, 21 Oct 2019 06:59:36 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 46xdYL4YXMz2xpP; Mon, 21 Oct 2019 15:59:34 +0200 (CEST) Received: from localhost.localdomain (unknown [127.0.0.1]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 46xdYL41JzzCqkV; Mon, 21 Oct 2019 15:59:34 +0200 (CEST) Received: from opfedar00.bagnolet.francetelecom.fr by opfedar00.bagnolet.francetelecom.fr with queue id 1158788-21; Mon, 21 Oct 2019 13:59:34 GMT Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 46xdYL3fRmzCqkT; Mon, 21 Oct 2019 15:59:34 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6F.corporate.adroot.infra.ftgroup ([fe80::c489:b768:686a:545b%23]) with mapi id 14.03.0468.000; Mon, 21 Oct 2019 15:59:34 +0200 From: To: "philip.eardley@bt.com" , "Michael.Scharf@hs-esslingen.de" CC: "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt Thread-Index: AQHVesazxMnJ0MpTtUGYTCO0/wPXnKdKmMEAgBqMdbCAAAraUA== Date: Mon, 21 Oct 2019 13:59:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031342F0D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <157020217020.1400.989960668789303006@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933031338ED7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: 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: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 13:59:39 -0000 Hi Phil, Thank you for double checking.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Envoy=E9=A0: lundi 21 octobre 2019 15:10 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Michael.Scharf@hs-esslingen.de > Cc=A0: tcpm@ietf.org > Objet=A0: RE: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt >=20 > Med, > Thanks for creating these new pieces of text, I think they're helpful and > it's looking good! >=20 > Comments: > Section 3.3 > < Converter owing to the Total Length field in the Convert messages>> > Better: > User data is unambiguously distinguished from Convert TLVs by a Transport > Converter by the Convert Fixed Header (Figure 12) in the Convert messages >=20 [Med] The OLD wording insisted on the importance of Total Length field to d= isambiguate TLVs when user data is also present, but OK to change as follow= s if you think this is better: =20 User data is unambiguously distinguished from Convert TLVs by a Transport Converter owing to the Convert Fixed Header in the Convert messages (Section 4.1). > In Section 3.3, I think you should move the text about MPTCP out of S3.3 > (into S3.4, maybe with some renumbering of S3.4 & 3.5 to make a section > about mptcp) > [this is the text "Note that for the Multipath TCP case..." to the Figure= 8 > caption and the bullet "In reference to Figure 8"] > Reason: handle the general case first, then the MPTCP variant. [Med] No problem to rearrange the text if you think that is better.=20 >=20 > << Note that for the Multipath TCP case, the Transport Converter identifi= es > an MPTCP connection by means, e.g., of the token assigned to the MPTCP > connection.>> > If I get it right, this is nothing to do with the token defined in MPTCP, [Med] ", e.g., of the token assigned to the MPTCP connection." refers to th= e token defined in MPTCP:=20 Token: A locally unique identifier given to a multipath connection by a host. May also be referred to as a "Connection ID". Any issue with that? > but is simply an identifier internal to the Converter (to help it keep > together entries for the same Client). Ie this token is not seen on the > wire. Please could you re-phrase the para and the definition of "token" i= n > the Figure 8 caption. >=20 > Section 4.1 > In the Figure 12 caption, I suggest deleting "-Sized" (so: "Figure 12: Th= e > Fixed Header of the Convert Protocol" or even "Figure 12: The Convert Fix= ed > Header") [Med] OK, changed to "Figure 12: The Convert Fixed Header)". >=20 > Section D.2 > Appendix D.1 has a final paragraph which doesn't appear at the end of D.2 > (< traffic.>>) [Med] D2.2 has already the following text:=20 Adequate forwarding policies are enforced so that traffic destined to an address of such pool is intercepted by the appropriate Transport Converter. > I assume the same text is true for the IPv4 address sharing model. I > suggest adding a comment at the end of D.2 that the same considerations > apply (or repeating the paragraph, possibly with "IP address" changed to > "IP address prefix") > I also suggest changing the title "IPv4 Address Sharing" to "Address > Sharing" [Med] Changed the title to "Address/Prefix Sharing" to cover both IPv4 and = IPv6. Thank you. >=20 > Best wishes, > phil >=20 >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: 04 October 2019 16:20 > To: Eardley,PL,Philip,TUD1 R ; Scharf, Michael > (Michael.Scharf@hs-esslingen.de) > Cc: tcpm@ietf.org > Subject: RE: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt >=20 > Hi Phil, Michael, >=20 > This version implements the suggestions discussed so far: add a new secti= on > to discuss data processing once a state is created + appendix to discuss > address sharing/preservation modes. >=20 > I think this version solves the concerns raised by Phil. >=20 > Looking forward to advance the document. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de internet- > > drafts@ietf.org Envoy=E9=A0: vendredi 4 octobre 2019 17:16 =C0=A0: > > i-d-announce@ietf.org Cc=A0: tcpm@ietf.org Objet=A0: [tcpm] I-D Action: > > draft-ietf-tcpm-converters-12.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-12.txt > > Pages : 52 > > Date : 2019-10-04 > > > > 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. > > > > -- Editorial Note (To be removed by RFC Editor) > > > > Please update these statements with the RFC number to be assigned to > > this document: [This-RFC] > > > > Please update TBA statements with the port number to be assigned to > > the 0-RTT TCP Convert Protocol. > > > > > > 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-12 > > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-12 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-12 > > > > > > 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 From nobody Mon Oct 21 19:25:13 2019 Return-Path: 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 097E1120AEB for ; Mon, 21 Oct 2019 19:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com 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 fcP_xEAmf9YX for ; Mon, 21 Oct 2019 19:25:09 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38D4120AEA for ; Mon, 21 Oct 2019 19:25:09 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id t8so6928270qtc.6 for ; Mon, 21 Oct 2019 19:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=KRWfUDcyKkcbweGYzwjKFH3RMsHOqy159rLXkoc/UuY=; b=gXKTkiAsvIzw2AXoqI/WgAT/s4JL9RJJrYAdwB/K3ZFqKoolP7WtUa/Y0jsu6/SAmZ aolZpZ6l/YcBqMnZgjKQFwphi7NpcYdLLmbmbwWwmUaGSQ1ebrvEdJx2wgkDGP9rWfS9 ygnsFj/LKzmtnd6RLkL1M2USaKoqpNi1SQdrlKySI8P7XADktXsLmr69x07uvsB9CbOm s6a52z/xc9t02ohwP665fppv1E1r3lGXaM1Y7bmc24s7G/asLI2aGMPGjsPayB8qxrTj JDKPa90IxHdW3u6+ClG6U3YxGDN21KvNxaH/daQsbIoSlt/Tdf8VEJYIIn+aYalCnTP9 558A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KRWfUDcyKkcbweGYzwjKFH3RMsHOqy159rLXkoc/UuY=; b=pHfRj25NEsSZzVcc276CvnpWjxZPOQ0RiHUlMkrzNDaU34sTjwykE5QCXpdsIFgDkt Lg+Xg1MDaF1P3pCrNcu/MCX6dl0HmINh3YTqb7VRVAt1SzczYigjW41NFLcnjeZXVjpI gJuKUyGfIHBbw8vE+F/b86jN09gxtyUmzZzrll5DYYQ+9pOvibipXHMhN3MO4zoKO61e 2NJiTjtBIifpwi6QTjNem6nbnJn7qKGnSJb3z1Lj9eX2c7H1BqqkAvrO0HLKu5RxCdUI gnn3XRHJ3nXczGirALRTGTN/2LSqM5iQ0roI7dR7RsyBHszXq/2cHsGxI/8Qrkrcp02S +sMQ== X-Gm-Message-State: APjAAAUrI1+VKP/8Hi6Gah6BwXHdkjIRRIaDBSl0p9AaB0kXKW073cVF qMkWd07RCn0DWNpRcVH0//kuoUp0qdU= X-Google-Smtp-Source: APXvYqwdW4LqYKLPBG8FBkYp34KXCbF/HiyiQHUEUAscv/DbCq+zDAKiXXE+TLe7/uQB7rHEe+cAcg== X-Received: by 2002:aed:24f2:: with SMTP id u47mr1049407qtc.70.1571711108544; Mon, 21 Oct 2019 19:25:08 -0700 (PDT) Received: from [192.168.1.11] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id h3sm1344899qte.62.2019.10.21.19.25.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Oct 2019 19:25:08 -0700 (PDT) To: "Scharf, Michael" Cc: "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D4AF868@rznt8114.rznt.rzdir.fht-esslingen.de> From: Wesley Eddy Message-ID: Date: Mon, 21 Oct 2019 22:25:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4AF868@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] 793bis wording on TCP keep-alives X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 02:25:12 -0000 Hi Michael, I totally agree with your proposal on this.  The change is simple and adds clarity; thanks!  I will put this into my working copy, unless there is any disagreement raised in the meantime. On 10/21/2019 6:37 AM, Scharf, Michael wrote: > Hi Wes, > > after reading Section 3.8.4. "TCP Keep-Alives" in 793bis, I would suggest to copy a bit more text from RFC 1122 to better define keep-alives. > > Background: RFC 1122 does not formally define "keep-alive" in the normative part, but it mentions implementation behavior in the DISCUSSION text: > > Some TCP implementations, however, have included a > keep-alive mechanism. To confirm that an idle > connection is still active, these implementations send > a probe segment designed to elicit a response from the > peer TCP. Such a segment generally contains SEG.SEQ = > SND.NXT-1 and may or may not contain one garbage octet > of data. > > In RFC 1122, only this DISCUSSION text describes what a "probe segment" could be and what "garbage octet" implies. > > Currently 793bis only copies the normative text from RFC 1122, and therefore it does not define these concepts. > > My proposal would be to copy also the cited text from RFC 1122 to 793bis to provide more background, e.g., along the lines of: > > 793bis OLD: > > Implementors MAY include "keep-alives" in their TCP implementations > (MAY-5), although this practice is not universally accepted. If > keep-alives are included, the application MUST be able to turn them > on or off for each TCP connection (MUST-24), and they MUST default to > off (MUST-25). > > [... and more sections on probe segments and garbage octet...] > > 793bis NEW: > > Implementors MAY include "keep-alives" in their TCP implementations > (MAY-5), although this practice is not universally accepted. Some > TCP implementations, however, have included a keep-alive mechanism. > To confirm that an idle connection is still active, these implementations > send a probe segment designed to elicit a response from the peer TCP. > Such a segment generally contains SEG.SEQ = SND.NXT-1 and may or may not > contain one garbage octet of data. If keep-alives are included, the > application MUST be able to turn them on or off for each TCP connection > (MUST-24), and they MUST default to off (MUST-25). > > [... rest of existing text...] > > The additional text is literally taken from RFC 1122 and therefore should not be problematic. > > Thanks > > Michael From nobody Tue Oct 22 03:26:05 2019 Return-Path: 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 6B4A512008B for ; Tue, 22 Oct 2019 03:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com 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 DSs2O50Wvt1W for ; Tue, 22 Oct 2019 03:26:02 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3485120273 for ; Tue, 22 Oct 2019 03:26:01 -0700 (PDT) Received: from tpw09926dag07e.domain1.systemhost.net (10.9.202.34) by RDW083A012ED68.bt.com (10.187.98.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 22 Oct 2019 11:25:06 +0100 Received: from tpw09926dag05g.domain1.systemhost.net (10.9.202.28) by tpw09926dag07e.domain1.systemhost.net (10.9.202.34) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 22 Oct 2019 11:25:58 +0100 Received: from bwp09926077.bt.com (10.36.82.108) by tpw09926dag05g.domain1.systemhost.net (10.9.202.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 22 Oct 2019 11:25:58 +0100 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.59) by smtpe1.intersmtp.com (10.36.82.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 22 Oct 2019 11:25:41 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TKLTYJCdn9yrkYFC67Quuol36YuNkgYyRD/TqHuGCsmPdxBwKxsdM8GEv9BE4wXNPnPN2LaVa7huwJhtirylMfXNtp/T/UfX8BDYKNbkQOSsJe0mAiCXFcqo/Mu8QfEIFwK4hwOA3XV02cKsdi5mC5k7mbOsGAbh13P4qE3jSQcOaMhmy8pewghgeEJl06Q7muzSHfgdJf/NrHSbj2UHNP5wUui6U8B4Nb9NmjZsivf4h/M5vZ3BSB6AX/BQVXLwhlFo5Fi6LU3PUE2xzivNWjRD0vKGFhd3grVz9WW763KjaOj0gQA1Pg3++7zcR/FCVpbGjzfQeCZV7Xsb3Xz4WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MxRBG5vzJY3A3KxWCYGtbF+feHCAOYyLXOoZukc2W7k=; b=OM0ogoMhvpDCj6mMR96pB8JxD8l5pyFtPktEWxsowP5zTTNX26bqfy54oS77gqkH2aVvUpzVJQBUuFmtQwPs5diw+yMm+qExN7Fy5Ya3j24iiJxOqD6xNLaR/o+N6+HCoaOL8/h7vF7ZOIBs+Ptcses0+f6cqVpsKNO+LKdt8p0+KnzGnVuDxAlPAbD1MRA2oyfhjDtge8kB848mjBFa4dUCGPwi9IvlcTO4H39+h7SIeSWwC1F1kNtJ6vINENB0AHEysmw76jTZoS0/kMgy2kiU/6Z1Sv9s+eeMjnwPQc7eBCXkjudZ6ciNWoazoYjLOk/PMVxgkHX+ba6Kpripmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MxRBG5vzJY3A3KxWCYGtbF+feHCAOYyLXOoZukc2W7k=; b=lisblA1M6qzP/PbWNhADam7Avqf/oCqBS2PhJE/ctbYL3SHWbDdv4pMVVpvOLOFRLMQHb+Gulh3YpjiGGePbFsKhNvQXfy936JPJ1SyUOX0FY+K2XPiKlkp4GTBgtaQ42ZCAmn1FSv85fbYAtlnee+JsHDOjYG9LfP8CfJzFHdU= Received: from CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM (20.176.58.79) by CWLP123MB2756.GBRP123.PROD.OUTLOOK.COM (20.180.138.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.23; Tue, 22 Oct 2019 10:25:52 +0000 Received: from CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM ([fe80::5c43:4d65:4081:f8a8]) by CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM ([fe80::5c43:4d65:4081:f8a8%5]) with mapi id 15.20.2347.029; Tue, 22 Oct 2019 10:25:51 +0000 From: To: , CC: Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt Thread-Index: AQHVesazxMnJ0MpTtUGYTCO0/wPXnKdKmMEAgBqMdbCAAAraUIABVV+Q Date: Tue, 22 Oct 2019 10:25:51 +0000 Message-ID: References: <157020217020.1400.989960668789303006@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933031338ED7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933031342F0D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031342F0D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 740d5066-e3c7-4cab-f511-08d756da36e1 x-ms-traffictypediagnostic: CWLP123MB2756: x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(376002)(39860400002)(366004)(51444003)(13464003)(189003)(199004)(51914003)(54094003)(7696005)(53546011)(86362001)(6506007)(33656002)(256004)(446003)(11346002)(476003)(76176011)(14444005)(102836004)(26005)(2906002)(186003)(6246003)(110136005)(99286004)(8676002)(8936002)(486006)(6116002)(81166006)(2501003)(316002)(3846002)(81156014)(4326008)(478600001)(25786009)(76116006)(305945005)(66446008)(229853002)(6436002)(66066001)(14454004)(64756008)(52536014)(66946007)(71200400001)(71190400001)(74316002)(7736002)(66556008)(9686003)(5660300002)(66476007)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:CWLP123MB2756; H:CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NbzDDUcyU446Iv8hjZFc1vHOtZNczWiFGdb8v9oDrjUQHDawC2pw5MZvavXSBTEMMTYU3CU6tjCE08lmrWS5/ZE55WRNmOThn9f1AflfE51tVU+nbQxbqMcbYsIF/GnJkU2QhvdB6zjaKtZTMsDS7f2SAKjcgwuQjdppFxSlnHx6f4I1/OdgfC2mFjouXyteIhd6r0stSdPP2pp1TsEbLLlRdvpJ9pjKcb9mppvdu+On+eosV8xHmrv/AKLTz6gVerz5RIgIUmYd70uLaz8ls9QcaGr13u+4NMR9J7YxTG+Hh8uIcl7mE0jd6TvuVUiTMpC5LSD6D5VVhtRzqwKu0lgqulaeUk3IKMcjI2Pg1w13LbFnrb63d4YRLR9S3BHPwVl9hQqAaaoJdR1ZQ6edSsW9It6RSFOLnliAkppfW+N0DgyLmId47mwWKPSNiSxx x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 740d5066-e3c7-4cab-f511-08d756da36e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2019 10:25:51.8772 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RG+6RZ2Jh/Z+gcFsN0QQJ5t8hg4G5wyUBPtqxtCsUA5YqxoZJH753ecQXAszmvyE7PHNGH6/2JvvP1ZRJFZiYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP123MB2756 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Report: 4 Rules triggered * 0.1 -- GEN_SPAM_FEATRE * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6659 X-NAI-Spam-Version: 2.2.0.9309 : core <6659> : inlines <7155> : streams <1836353> : uri <2925924> X-OriginatorOrg: bt.com Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 10:26:04 -0000 Tiny follow-ups below. Thanks for your efforts on this, I think we're done phil -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: 21 October 2019 15:00 To: Eardley,PL,Philip,TUD1 R ; Michael.Scharf@hs-ess= lingen.de Cc: tcpm@ietf.org Subject: RE: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt Hi Phil, Thank you for double checking.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Envoy=E9=A0:= =20 > lundi 21 octobre 2019 15:10 =C0=A0: BOUCADAIR Mohamed TGI/OLN;=20 > Michael.Scharf@hs-esslingen.de Cc=A0: tcpm@ietf.org Objet=A0: RE: [tcpm]= =20 > I-D Action: draft-ietf-tcpm-converters-12.txt >=20 [Med] No problem to rearrange the text if you think that is better. [phil] thanks, yes I think that would definitely be better.=20 >=20 [Med] ", e.g., of the token assigned to the MPTCP connection." refers to th= e token defined in MPTCP:=20 Token: A locally unique identifier given to a multipath connection by a host. May also be referred to as a "Connection ID". Any issue with that? [phil] Thanks for the pointer.=20 I wonder if the following would be better (instead of the "Note that for th= e Multipath TCP case..." paragraph above Figure 8). I'll leave it to you to= decide.=20 Note that for the Multipath TCP (MPTCP) case, a connection between the Clie= nt and Transport Converter has multiple subflows (each with a different IP = address and/or port). In the MPTCP specification [ref], at each host an MPT= CP connection is identified by a token (a one-way hash of the MPTCP key). A= n implementation example of a MPTCP transport session entry maintained by a= Transport Converter is shown in Figure 7. The entry needs to be updated wh= enever subflows are added to, or deleted from, the MPTCP connection. As a r= eminder, the Convert TLVs are only exchanged during the establishment of th= e initial subflow. > Section D.2 > Appendix D.1 has a final paragraph which doesn't appear at the end of=20 > D.2 (< incoming > traffic.>>) [Med] D2.2 has already the following text:=20 Adequate forwarding policies are enforced so that traffic destined to an address of such pool is intercepted by the appropriate Transport Converter. [phil] I missed that, thanks.=20 In the sentence after the one you quote << Unlike Appendix D.1, the Transport Converter drops incoming packets which do match an active transport session entry.>> I assume it should be: "which do not match" From nobody Tue Oct 22 05:07:35 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1916A1201C6; Tue, 22 Oct 2019 05:07:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.107.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <157174604799.2854.1478201373925998572@ietfa.amsl.com> Date: Tue, 22 Oct 2019 05:07:28 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 12:07:28 -0000 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-13.txt Pages : 52 Date : 2019-10-22 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. -- Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: [This-RFC] Please update TBA statements with the port number to be assigned to the 0-RTT TCP Convert Protocol. 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-13 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-13 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/ From nobody Tue Oct 22 05:09:55 2019 Return-Path: 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 01B36120255 for ; Tue, 22 Oct 2019 05:09:54 -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 vym1WfDifW_G for ; Tue, 22 Oct 2019 05:09:52 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC251201C6 for ; Tue, 22 Oct 2019 05:09:52 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 46yC4H1YZTzBrYc; Tue, 22 Oct 2019 14:09:51 +0200 (CEST) Received: from localhost.localdomain (unknown [127.0.0.1]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 46yC4H11lDz3wbQ; Tue, 22 Oct 2019 14:09:51 +0200 (CEST) Received: from opfedar06.bagnolet.francetelecom.fr by opfedar06.bagnolet.francetelecom.fr with queue id 1166536-32; Tue, 22 Oct 2019 12:09:51 GMT Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 46yC4H0czhz3wb8; Tue, 22 Oct 2019 14:09:51 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([fe80::f04d:ad3c:61de:a175%21]) with mapi id 14.03.0468.000; Tue, 22 Oct 2019 14:09:50 +0200 From: To: "philip.eardley@bt.com" , "Michael.Scharf@hs-esslingen.de" CC: "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt Thread-Index: AQHVesazxMnJ0MpTtUGYTCO0/wPXnKdKmMEAgBqMdbCAAAraUIABVV+QgAAn4cA= Date: Tue, 22 Oct 2019 12:09:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031343914@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <157020217020.1400.989960668789303006@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933031338ED7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933031342F0D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: 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: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 12:09:54 -0000 Hi Phil,=20 Great! Thanks.=20 I submitted a new version which fixes the nits + rearranged text. =20 Cheers, Med > -----Message d'origine----- > De=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Envoy=E9=A0: mardi 22 octobre 2019 12:26 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Michael.Scharf@hs-esslingen.de > Cc=A0: tcpm@ietf.org > Objet=A0: RE: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt >=20 > Tiny follow-ups below. >=20 > Thanks for your efforts on this, I think we're done > phil >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: 21 October 2019 15:00 > To: Eardley,PL,Philip,TUD1 R ; Michael.Scharf@hs- > esslingen.de > Cc: tcpm@ietf.org > Subject: RE: [tcpm] I-D Action: draft-ietf-tcpm-converters-12.txt >=20 > Hi Phil, >=20 > Thank you for double checking. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Envoy=E9=A0= : > > lundi 21 octobre 2019 15:10 =C0=A0: BOUCADAIR Mohamed TGI/OLN; > > Michael.Scharf@hs-esslingen.de Cc=A0: tcpm@ietf.org Objet=A0: RE: [tcpm= ] > > I-D Action: draft-ietf-tcpm-converters-12.txt > > >=20 > [Med] No problem to rearrange the text if you think that is better. >=20 > [phil] thanks, yes I think that would definitely be better. >=20 > > >=20 > [Med] ", e.g., of the token assigned to the MPTCP connection." refers to > the token defined in MPTCP: >=20 > Token: A locally unique identifier given to a multipath connection > by a host. May also be referred to as a "Connection ID". >=20 > Any issue with that? >=20 > [phil] > Thanks for the pointer. >=20 > I wonder if the following would be better (instead of the "Note that for > the Multipath TCP case..." paragraph above Figure 8). I'll leave it to yo= u > to decide. >=20 > Note that for the Multipath TCP (MPTCP) case, a connection between the > Client and Transport Converter has multiple subflows (each with a differe= nt > IP address and/or port). In the MPTCP specification [ref], at each host a= n > MPTCP connection is identified by a token (a one-way hash of the MPTCP > key). An implementation example of a MPTCP transport session entry > maintained by a Transport Converter is shown in Figure 7. The entry needs > to be updated whenever subflows are added to, or deleted from, the MPTCP > connection. As a reminder, the Convert TLVs are only exchanged during the > establishment of the initial subflow. >=20 >=20 > > Section D.2 > > Appendix D.1 has a final paragraph which doesn't appear at the end of > > D.2 (< > incoming > > traffic.>>) >=20 > [Med] D2.2 has already the following text: >=20 > Adequate forwarding policies are enforced so that traffic destined to > an address of such pool is intercepted by the appropriate Transport > Converter. >=20 > [phil] I missed that, thanks. > In the sentence after the one you quote > << Unlike Appendix D.1, the Transport Converter drops > incoming packets which do match an active transport session entry.>> >=20 > I assume it should be: "which do not match" From nobody Fri Oct 25 14:12:52 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 513EF1208A7; Fri, 25 Oct 2019 14:12:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tcpm@ietf.org, ietf@kuehlewind.net X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203792232.2724.12582428830591243325.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:02 -0700 Archived-At: Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 106 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:12:03 -0000 Dear Michael Scharf, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tcpm Session 1 (2:00 requested) Friday, 22 November 2019, Morning Session I 1000-1200 Room Name: VIP A size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/tcpm.ics Request Information: --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: mptcp Technology Overlap: tsvwg quic taps tsvarea iccrg panrg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: Please avoid the last slot on Thursday afternoon/evening --------------------------------------------------------- From nobody Tue Oct 29 14:57:17 2019 Return-Path: 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 E3092120112; Tue, 29 Oct 2019 14:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 0I33DNARmmZI; Tue, 29 Oct 2019 14:57:12 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A67012001E; Tue, 29 Oct 2019 14:57:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 7AA3F25A20; Tue, 29 Oct 2019 22:57:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572386230; bh=HDPz3rgkFrghvPE68r8aZo7bjyNKibRcl66HoQTIkMo=; h=From:To:CC:Subject:Date:From; b=JqgZrfwtM8+ePA4jlywy8RaKM+eU6oWjNLA3id+nrCYRGR75TV3yAxCV6fzgKesFT NXwx0Afh7L+5dHatb87nRgWqaIoviVfGzn91ES+Yn9ZtGMk/gISdKIlWbIDDEZERWy /pJfqsN5YojH34D07d2DZZwM+iVF+wtqstRlzxh4= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ve2gbZD_iQJ; Tue, 29 Oct 2019 22:57:09 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 29 Oct 2019 22:57:09 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Tue, 29 Oct 2019 22:57:09 +0100 From: "Scharf, Michael" To: "tcpm@ietf.org Extensions" CC: "tcpm-chairs@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwhjHxyOg Date: Tue, 29 Oct 2019 21:57:08 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4C8635@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 21:57:15 -0000 Hi all, The WGLC now ends, given that Phil's comments seem resolved. This has taken= some document iterations, which is the root cause for the long delay. As next step I will complete the shepherd write-up. Thanks Michael > -----Original Message----- > From: Scharf, Michael > Sent: Tuesday, June 25, 2019 6:39 PM > To: tcpm@ietf.org Extensions > Cc: tcpm-chairs@ietf.org > Subject: WGLC for draft-ietf-tcpm-converters-08 >=20 > Hi all, >=20 > draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. >=20 > Therefore, this e-mail starts a working group last call (WGLC) for draft-= ietf- > tcpm-converters-08 that will run until ***July 14, 2019***. >=20 > Please let us know if there are any remaining open issues regarding this > document. Statements supporting publication are also welcome. In absence = of > feedback we will assume that the TCPM consensus is to move the document t= o > the IESG. As discussed in the past, the intended status of the document i= s > experimental. >=20 > Thanks a lot >=20 > Michael > (TCPM co-chair)