From iesg-secretary@ietf.org Tue May 15 11:22:49 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCCB21F8686; Tue, 15 May 2012 11:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBjuQhdNqzpg; Tue, 15 May 2012 11:22:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A22E21F8622; Tue, 15 May 2012 11:22:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120515182249.22423.80096.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 11:22:49 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] WG Review: Recharter of Multipath TCP (mptcp) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 18:22:49 -0000 A modified charter has been submitted for the Multipath TCP (mptcp) = working group in the Transport Area of the IETF. The IESG has not made = any determination as yet. The modified charter is provided below for = informational purposes only. Please send your comments to the IESG = mailing list (iesg@ietf.org) by Tuesday, May 22, 2012. Multipath TCP (mptcp) ---------------------------------------------------------- Status: Active Working Group Last updated: 2012-05-10 Chairs: Philip Eardley Yoshifumi Nishida Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing List: = Address: multipathtcp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ Description of Working Group: The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. Key goals for MPTCP are: to be deployable and usable without significant changes to existing Internet infrastructure; to be usable by unmodified applications; and to be stable and congestion-safe over the wide range of existing Internet paths, including NAT interactions. MPTCP assumes that both peers are modified and that one or both peers have multiple addresses, which often results in different network paths that are at least partially divergent (however, note there is no guarantee that the paths are divergent at all). In its initial charter the WG produced experimental or informational documents that defined: a. An architectural framework for congestion-dependent multipath transport protocols. It describes the motivations and the general approach that should be followed to enable congestion-dependent multipath transport. b. A security threat analysis for multipath TCP. c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control. d. Extensions to current TCP to support multi-addressed multipath TCP. This covers all on-the-wire changes required to create a two-ended MPTCP solution using multiple IP addresses at one or both ends. It includes a basic security solution. = e. Application Interface Considerations. It summarises the impact that MPTCP may have on applications, such as changes in performance. Also, it describes an optional, basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. The working group now re-charters to progress various aspects of MPTCP. The primary goal of the working group is to create a bis version of the protocol document on the Standards track. This develops the current Experimental document (item d above), incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM. There already exists a reference Linux implementation and other implementation and experimental activity is on-going and will continue during 2012, with the objective of progressing the protocol to Standards Track during 2013. The working group will document implementation advice. The current documents have several points where an implementer may benefit from guidance, for example about heuristics such as buffer sizing, or from advice about alternative implementations such as bump-in-the-stack. The working group will also explore and document results with several of the proposed use cases for MPTCP in more detail, to ensure that MPTCP works well in practice and that operational experiences and issues are understood and captured. Likely use cases are to offload traffic from 3G to WiFi, and to manage traffic within a data centre. Another scenario is to enable, without changing the MPTCP protocol, operation of a single-homed, MPTCP end host on a campus network that has multiple providers. Finally, the working group will explore whether an MPTCP-aware middlebox would be useful, where at least one end host is MPTCP-enabled. For example, potentially helping MPTCP=C3=95s incremental deployment by allowing only one end host to be MPTCP-enabled and the middlebox acts as an MPTCP proxy for the other end host, which runs TCP; and potentially helping some mobility scenarios, where the middlebox acts as an anchor between two MPTCP-enabled hosts. The working group will detail what real problems an MPTCP-enabled middlebox might solve, how it would impact the Multipath TCP architecture (RFC6182), what proxy approach might be justified as compared against alternative solutions to the problems, and the likely feasibility of solving the technical and security issues. Goals and Milestones: Dec 2012 Consensus on what high-level changes are needed to the current MPTCP Experimental document in order to progress it on the standards track April 2013 Implementation advice (Informational) to IESG August 2013 Use cases (Informational) to IESG Dec 2013 MPTCP-enabled middleboxes (Informational) to IESG Dec 2013 MPTCP standards track protocol to IESG Jan 2014 Re-charter or close From georg.hampel@alcatel-lucent.com Thu May 17 13:42:10 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF76821F87A4 for ; Thu, 17 May 2012 13:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.575 X-Spam-Level: X-Spam-Status: No, score=-9.575 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M3x439tH3ev for ; Thu, 17 May 2012 13:42:10 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E7B0F21F8792 for ; Thu, 17 May 2012 13:42:09 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q4HKg9Nt023568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 17 May 2012 15:42:09 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4HKg8sJ013856 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 17 May 2012 15:42:08 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 17 May 2012 15:42:08 -0500 From: "Hampel, K Georg (K Georg)" To: "multipathtcp@ietf.org" Date: Thu, 17 May 2012 15:42:07 -0500 Thread-Topic: subflow termination with FIN Thread-Index: Ac00bYa3D1R5CpkKSsKGz6CAPUIYJg== Message-ID: <154773479ED2314980CB638A48FC4434C45F200D@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC4434C45F200DUSNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [multipathtcp] subflow termination with FIN X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 20:42:10 -0000 --_000_154773479ED2314980CB638A48FC4434C45F200DUSNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I have a question on termination of individual MPTCP subflows: Multiple subflows are up with tcp_state =3D ESTABLISHED, when host A sends = TCP FIN on SFL1 and sets this subflow's tcp_state to FIN_WAIT1. When receiving FIN on SFL1, host B could simply enter tcp_state =3D CLOSE_W= AIT for this SFL and keep sitting there until the end of connection. Obviously, this is not desirable. If host A sends FIN on a SFL, host B shou= ld grant this request, stop scheduling new data on this SFL and respond wit= h FIN ASAP. I think this behavior should be discussed in the design doc. Thanks. Regards, Georg --_000_154773479ED2314980CB638A48FC4434C45F200DUSNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I have a question on termination of individual MPTCP sub= flows:

 

Multiple subflows are up with tcp_state =3D ESTABLISHED,= when host A sends TCP FIN on SFL1 and sets this subflow’s tcp_state to FIN= _WAIT1.

 

When receiving FIN on SFL1, host B could simply enter tc= p_state =3D CLOSE_WAIT for this SFL and keep sitting there until the end of connect= ion.

 

Obviously, this is not desirable. If host A sends FIN on= a SFL, host B should grant this request, stop scheduling new data on this SFL and respond with FIN ASAP.

 

I think this behavior should be discussed in the design = doc. Thanks.

 

Regards,

 

Georg

 

--_000_154773479ED2314980CB638A48FC4434C45F200DUSNAVSXCHMBSA2n_-- From nishida@sfc.wide.ad.jp Thu May 17 21:57:28 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2A521F85C9 for ; Thu, 17 May 2012 21:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UixcU5j9fpBN for ; Thu, 17 May 2012 21:57:28 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id AE0A321F8557 for ; Thu, 17 May 2012 21:57:27 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 953332780B5 for ; Fri, 18 May 2012 13:57:24 +0900 (JST) Received: by lagv3 with SMTP id v3so2050551lag.31 for ; Thu, 17 May 2012 21:57:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.112.161 with SMTP id ir1mr9612695lab.13.1337317042131; Thu, 17 May 2012 21:57:22 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Thu, 17 May 2012 21:57:22 -0700 (PDT) In-Reply-To: <154773479ED2314980CB638A48FC4434C45F200D@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC4434C45F200D@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Thu, 17 May 2012 21:57:22 -0700 Message-ID: From: Yoshifumi Nishida To: "Hampel, K Georg (K Georg)" Content-Type: multipart/alternative; boundary=f46d04088d7b3f926904c0486316 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] subflow termination with FIN X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 04:57:28 -0000 --f46d04088d7b3f926904c0486316 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Georg, In my understanding, host B still can use this connection to send data to host A if it wants and it doesn't break TCP's semantics. I'm guessing some implementations want to do this kind of things. I also agree that some implementations want to release resources quickly as you suggested. So, I might prefer to leave this to implementers. Thanks, -- Yoshifumi Nishida On Thu, May 17, 2012 at 1:42 PM, Hampel, K Georg (K Georg) < georg.hampel@alcatel-lucent.com> wrote: > All,**** > > ** ** > > I have a question on termination of individual MPTCP subflows:**** > > ** ** > > Multiple subflows are up with tcp_state =3D ESTABLISHED, when host A send= s > TCP FIN on SFL1 and sets this subflow=92s tcp_state to FIN_WAIT1. **** > > ** ** > > When receiving FIN on SFL1, host B could simply enter tcp_state =3D > CLOSE_WAIT for this SFL and keep sitting there until the end of connectio= n. > **** > > ** ** > > Obviously, this is not desirable. If host A sends FIN on a SFL, host B > should grant this request, stop scheduling new data on this SFL and respo= nd > with FIN ASAP. **** > > ** ** > > I think this behavior should be discussed in the design doc. Thanks.**** > > ** ** > > Regards,**** > > ** ** > > Georg**** > > ** ** > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --f46d04088d7b3f926904c0486316 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Georg,

In my understanding, host B still can use this connection = to send data to host A if it wants and it doesn't break TCP's seman= tics. I'm guessing some implementations want to do this kind of things.=

I also agree that some implementations want to release resources quickl= y as you suggested.
So, I might prefer to leave this to implementers.
Thanks,
--
Yoshifumi Nishida

On Thu, May 17, 2012 at 1:42 PM, Hampel, K Georg (K Georg) <= georg.hampel@alcatel-lucent.com> wrote:

All,

=A0

I have a question on termination of individual MPTCP su= bflows:

=A0

Multiple subflows are up with tcp_state =3D ESTABLISHED= , when host A sends TCP FIN on SFL1 and sets this subflow=92s tcp_state to FIN_WAI= T1.

=A0

When receiving FIN on SFL1, host B could simply enter t= cp_state =3D CLOSE_WAIT for this SFL and keep sitting there until the end of connect= ion.

=A0

Obviously, this is not desirable. If host A sends FIN o= n a SFL, host B should grant this request, stop scheduling new data on this SFL and respond with FIN ASAP.

=A0

I think this behavior should be discussed in the design= doc. Thanks.

=A0

Regards,

=A0

Georg

=A0


_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp


--f46d04088d7b3f926904c0486316-- From adrian@olddog.co.uk Fri May 18 13:57:00 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC5821F85CD; Fri, 18 May 2012 13:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-A60mZj9RxA; Fri, 18 May 2012 13:56:59 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id A55ED21F857A; Fri, 18 May 2012 13:56:55 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4IKukwk005411; Fri, 18 May 2012 21:56:46 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4IKuiJ0005390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 May 2012 21:56:45 +0100 From: "Adrian Farrel" To: , , References: <20120515182249.22423.80096.idtracker@ietfa.amsl.com> In-Reply-To: <20120515182249.22423.80096.idtracker@ietfa.amsl.com> Date: Fri, 18 May 2012 21:56:41 +0100 Message-ID: <0ea601cd3538$bab00170$30100450$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEJ1ImgU9qUeCYGaj2WTE0TjIJvOJhWx0YQ Content-Language: en-gb X-Mailman-Approved-At: Fri, 18 May 2012 14:13:15 -0700 Cc: iesg@ietf.org Subject: Re: [multipathtcp] WG Review: Recharter of Multipath TCP (mptcp) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 20:57:00 -0000 Hi, I am struggling with the MPTCP recharter and wonder whether you can help = me. Firstly, it seems to me that MPTCP is effectively inserting a small = session layer into the stack between the conventional transport layer = and the normal top-of-layer (presumably the sockets API). I understand = why this is convenient to the application used, as it is, to attaching = to a socket when it wants to send data, but I am not sure that "hiding" = this function is the best approach. But anyway, that is probably an = aside and is a decision long since made by the WG. I am worried that "multi-path" name may be a misnomer. AFAICS, there is = no certain way to keep the two TCP sessions on different paths through = the network. So "multi-session" might be a better name, and would = provide more clarity to the application that uses the feature. Clearly, there are some significant consequences to not keeping the = sessions on different paths, although I understand that there may still = be many benefits to running multiple parallel sessions. And, of course, = ECMP implementations stand a better chance of meaningfully = demultiplexing the data onto different flows if different sessions are = used. But still, it seems that MPTCP is less likely to take advantage of = available network resources than might initially appear to be the case = from its name. =20 How meaningful is MPTCP without MPTCP-aware load balancing routers in = the network? This would seem to be key to getting good use out of the = available resources by putting the multiple sessions into different = buckets. Are router vendors demonstrating interest in joining in the = experiment? Indeed, what can you tell me about the take-up of this experiment so = far? Obviously, there are a number of papers I can find by searching the = InterWeb; these demonstrate the theoretical viability of the work, and I = have read the notes on implementation and testing in the proposed = charter. Has the experimentation been conducted on large scale deployed = networks with live traffic? Has anyone put any thought into the risks associated with open = deployment? It is fair enough that "legacy" routers will not know the = difference, but do we know that there are no other risks or exposures? = Doesn't MPTCP result in an increase in the number of sessions in the = network? How does that impact on processes running on. in the network? Can you also tell me about the "hurry". The proposed charter suggests = that experimentation is "ongoing" in 2012. The protocol spec is on its = way to the IESG for consideration as an Experimental RFC. Normally it = would seem precipitous to start work on Standards Track documents so = soon. Is there a need or a strong push for this? I guess a "need" would = be represented by statements from the industry that a Standards Track = RFC is essential for some reason, or maybe a request from another SDO = for something they can reference. A "strong push" might come from = implementers building product, or from service providers / operators who = need to offer "fat-pipe" services and want to make better use of their = network resources. In short, who wants MPTCP? We (the IETF) do not have an established process for progressing from = Experimental to the Standards Track (compare with advancement on the = Standards Track) and I am NOT about to propose one or to impose hurdles = for that sort of change. Sometimes it is blatantly obvious that it is = time to make the change - I would cite PIM and the work in MANET as good = examples: real implementations and deployments existed, lessons had be = learned, and we were ready for real-time. In other cases it is less = obvious and it is helpful to put together some sort of summary of = experimental discoveries, tests undertaken, and deployments erm = deployed. This might be a short I-D that could be published as an RFC = for the historic record. [To be clear, I am not requiring this in the case of MPTCP, but it would certainly have helped me work out whether it = really is the right time to start work on Standards Track documents.] Thanks for your patience reading this, and for any explanations you can = offer. Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of IESG Secretary > Sent: 15 May 2012 19:23 > To: IETF Announcement List > Cc: multipathtcp@ietf.org; philip.eardley@bt.com; = nishida@sfc.wide.ad.jp > Subject: WG Review: Recharter of Multipath TCP (mptcp) >=20 > A modified charter has been submitted for the Multipath TCP (mptcp) > working group in the Transport Area of the IETF. The IESG has not = made > any determination as yet. The modified charter is provided below for > informational purposes only. Please send your comments to the IESG > mailing list (iesg@ietf.org) by Tuesday, May 22, 2012. >=20 > Multipath TCP (mptcp) > ---------------------------------------------------------- > Status: Active Working Group > Last updated: 2012-05-10 >=20 > Chairs: > Philip Eardley > Yoshifumi Nishida >=20 > Transport Area Directors: > Wesley Eddy > Martin Stiemerling >=20 > Transport Area Advisor: > Wesley Eddy >=20 > Mailing List: > Address: multipathtcp@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp > Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ >=20 > Description of Working Group: >=20 > The Multipath TCP (MPTCP) working group develops mechanisms that add = the > capability of simultaneously using multiple paths to a regular TCP > session. Key goals for MPTCP are: to be deployable and usable without > significant changes to existing Internet infrastructure; to be usable = by > unmodified applications; and to be stable and congestion-safe over the > wide range of existing Internet paths, including NAT interactions. = MPTCP > assumes that both peers are modified and that one or both peers have > multiple addresses, which often results in different network paths = that > are at least partially divergent (however, note there is no guarantee > that the paths are divergent at all). >=20 > In its initial charter the WG produced experimental or informational > documents that defined: >=20 > a. An architectural framework for congestion-dependent multipath > transport protocols. It describes the motivations and the general > approach that should be followed to enable congestion-dependent > multipath transport. >=20 > b. A security threat analysis for multipath TCP. >=20 > c. A coupled multipath-aware congestion control algorithm. This > algorithm is the multipath equivalent of SACK/NewReno congestion > control. >=20 > d. Extensions to current TCP to support multi-addressed multipath TCP. > This covers all on-the-wire changes required to create a two-ended = MPTCP > solution using multiple IP addresses at one or both ends. It includes = a > basic security solution. >=20 > e. Application Interface Considerations. It summarises the impact that > MPTCP may have on applications, such as changes in performance. Also, > it describes an optional, basic application interface for MPTCP-aware > applications that provides access to multipath address information and = a > level of control equivalent to regular TCP. >=20 >=20 > The working group now re-charters to progress various aspects of = MPTCP. >=20 > The primary goal of the working group is to create a bis version of = the > protocol document on the Standards track. This develops the current > Experimental document (item d above), incorporating experience from = (for > example) implementations, interoperability events, experiments, usage > scenarios, protocol corner cases, and feedback from TCPM. There = already > exists a reference Linux implementation and other implementation and > experimental activity is on-going and will continue during 2012, with > the objective of progressing the protocol to Standards Track during > 2013. >=20 > The working group will document implementation advice. The current > documents have several points where an implementer may benefit from > guidance, for example about heuristics such as buffer sizing, or from > advice about alternative implementations such as bump-in-the-stack. >=20 > The working group will also explore and document results with several > of the proposed use cases for MPTCP in more detail, to ensure that > MPTCP works well in practice and that operational experiences and > issues are understood and captured. Likely use cases are to offload > traffic from 3G to WiFi, and to manage traffic within a data centre. > Another scenario is to enable, without changing the MPTCP protocol, > operation of a single-homed, MPTCP end host on a campus network that = has > multiple providers. >=20 > Finally, the working group will explore whether an MPTCP-aware > middlebox would be useful, where at least one end host is = MPTCP-enabled. > For example, potentially helping MPTCP=C3=95s incremental deployment = by > allowing only one end host to be MPTCP-enabled and the middlebox acts = as > an MPTCP proxy for the other end host, which runs TCP; and potentially > helping some mobility scenarios, where the middlebox acts as an anchor > between two MPTCP-enabled hosts. The working group will detail what = real > problems an MPTCP-enabled middlebox might solve, how it would impact = the > Multipath TCP architecture (RFC6182), what proxy approach might be > justified as compared against alternative solutions to the problems, = and > the likely feasibility of solving the technical and security issues. >=20 > Goals and Milestones: >=20 > Dec 2012 Consensus on what high-level changes are needed to the > current MPTCP Experimental document in order to progress it on the > standards track >=20 > April 2013 Implementation advice (Informational) to IESG >=20 > August 2013 Use cases (Informational) to IESG >=20 > Dec 2013 MPTCP-enabled middleboxes (Informational) to IESG >=20 > Dec 2013 MPTCP standards track protocol to IESG >=20 > Jan 2014 Re-charter or close From nishida@sfc.wide.ad.jp Mon May 21 01:11:43 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6524F21F859E; Mon, 21 May 2012 01:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDYJaaOydG7S; Mon, 21 May 2012 01:11:41 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 1638721F857D; Mon, 21 May 2012 01:11:40 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BE1AC278097; Mon, 21 May 2012 17:11:36 +0900 (JST) Received: by lagv3 with SMTP id v3so3762457lag.31 for ; Mon, 21 May 2012 01:11:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.148.34 with SMTP id tp2mr18598662lab.47.1337587894121; Mon, 21 May 2012 01:11:34 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Mon, 21 May 2012 01:11:34 -0700 (PDT) In-Reply-To: <0ea601cd3538$bab00170$30100450$@olddog.co.uk> References: <20120515182249.22423.80096.idtracker@ietfa.amsl.com> <0ea601cd3538$bab00170$30100450$@olddog.co.uk> Date: Mon, 21 May 2012 01:11:34 -0700 Message-ID: From: Yoshifumi Nishida To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=e89a8f22c70548f3e204c08773e1 Cc: multipathtcp@ietf.org, iesg@ietf.org Subject: Re: [multipathtcp] WG Review: Recharter of Multipath TCP (mptcp) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 08:11:43 -0000 --e89a8f22c70548f3e204c08773e1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Adrian, Thanks for the feedbacks. We've discussed the "multi-path" naming from time to time, but there weren't strong opinions to change it yet. "Multi-session" might be better name for some people, but I'm afraid others might misunderstand that MPTCP allows multiple data streams in a single flow. IMO, I tend to think "path" in transport layer as a logical path which is not necessarily mapped to real network topologies. Multiple logical paths can be mapped to a single path in real networks, but it doesn't break MPTCP's concept at all. My feeling about milestone is we're just trying to not be lazy. As we've finished spec designs for experimental RFCs and have done some investigations for the potential risks in deployment and we've seen several implementing projects are running actively. Although I'm not sure they can be "strong push", MPTCP is getting some attentions from several communities. Based on these things, I'm not very sure if making a effort to produce a standard for two years from now is very hasty thing. I understand we will need really strong push when we publish a standard, but not very sure if we need it now. Regards, -- Yoshifumi Nishida On Fri, May 18, 2012 at 1:56 PM, Adrian Farrel wrote: > Hi, > > I am struggling with the MPTCP recharter and wonder whether you can help > me. > > Firstly, it seems to me that MPTCP is effectively inserting a small > session layer into the stack between the conventional transport layer and > the normal top-of-layer (presumably the sockets API). I understand why th= is > is convenient to the application used, as it is, to attaching to a socket > when it wants to send data, but I am not sure that "hiding" this function > is the best approach. But anyway, that is probably an aside and is a > decision long since made by the WG. > > I am worried that "multi-path" name may be a misnomer. AFAICS, there is n= o > certain way to keep the two TCP sessions on different paths through the > network. So "multi-session" might be a better name, and would provide mor= e > clarity to the application that uses the feature. > > Clearly, there are some significant consequences to not keeping the > sessions on different paths, although I understand that there may still b= e > many benefits to running multiple parallel sessions. And, of course, ECMP > implementations stand a better chance of meaningfully demultiplexing the > data onto different flows if different sessions are used. But still, it > seems that MPTCP is less likely to take advantage of available network > resources than might initially appear to be the case from its name. > > How meaningful is MPTCP without MPTCP-aware load balancing routers in the > network? This would seem to be key to getting good use out of the availab= le > resources by putting the multiple sessions into different buckets. Are > router vendors demonstrating interest in joining in the experiment? > > Indeed, what can you tell me about the take-up of this experiment so far? > Obviously, there are a number of papers I can find by searching the > InterWeb; these demonstrate the theoretical viability of the work, and I > have read the notes on implementation and testing in the proposed charter= . > Has the experimentation been conducted on large scale deployed networks > with live traffic? > > Has anyone put any thought into the risks associated with open deployment= ? > It is fair enough that "legacy" routers will not know the difference, but > do we know that there are no other risks or exposures? Doesn't MPTCP resu= lt > in an increase in the number of sessions in the network? How does that > impact on processes running on. in the network? > > Can you also tell me about the "hurry". The proposed charter suggests tha= t > experimentation is "ongoing" in 2012. The protocol spec is on its way to > the IESG for consideration as an Experimental RFC. Normally it would seem > precipitous to start work on Standards Track documents so soon. Is there = a > need or a strong push for this? I guess a "need" would be represented by > statements from the industry that a Standards Track RFC is essential for > some reason, or maybe a request from another SDO for something they can > reference. A "strong push" might come from implementers building product, > or from service providers / operators who need to offer "fat-pipe" servic= es > and want to make better use of their network resources. In short, who wan= ts > MPTCP? > > We (the IETF) do not have an established process for progressing from > Experimental to the Standards Track (compare with advancement on the > Standards Track) and I am NOT about to propose one or to impose hurdles f= or > that sort of change. Sometimes it is blatantly obvious that it is time to > make the change - I would cite PIM and the work in MANET as good examples= : > real implementations and deployments existed, lessons had be learned, and > we were ready for real-time. In other cases it is less obvious and it is > helpful to put together some sort of summary of experimental discoveries, > tests undertaken, and deployments erm deployed. This might be a short I-D > that could be published as an RFC for the historic record. [To be clear, = I > am not requiring this in the > case of MPTCP, but it would certainly have helped me work out whether it > really is the right time to start work on Standards Track documents.] > > Thanks for your patience reading this, and for any explanations you can > offer. > > Adrian > > -----Original Message----- > > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > > bounces@ietf.org] On Behalf Of IESG Secretary > > Sent: 15 May 2012 19:23 > > To: IETF Announcement List > > Cc: multipathtcp@ietf.org; philip.eardley@bt.com; nishida@sfc.wide.ad.j= p > > Subject: WG Review: Recharter of Multipath TCP (mptcp) > > > > A modified charter has been submitted for the Multipath TCP (mptcp) > > working group in the Transport Area of the IETF. The IESG has not made > > any determination as yet. The modified charter is provided below for > > informational purposes only. Please send your comments to the IESG > > mailing list (iesg@ietf.org) by Tuesday, May 22, 2012. > > > > Multipath TCP (mptcp) > > ---------------------------------------------------------- > > Status: Active Working Group > > Last updated: 2012-05-10 > > > > Chairs: > > Philip Eardley > > Yoshifumi Nishida > > > > Transport Area Directors: > > Wesley Eddy > > Martin Stiemerling > > > > Transport Area Advisor: > > Wesley Eddy > > > > Mailing List: > > Address: multipathtcp@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtc= p > > Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ > > > > Description of Working Group: > > > > The Multipath TCP (MPTCP) working group develops mechanisms that add th= e > > capability of simultaneously using multiple paths to a regular TCP > > session. Key goals for MPTCP are: to be deployable and usable without > > significant changes to existing Internet infrastructure; to be usable b= y > > unmodified applications; and to be stable and congestion-safe over the > > wide range of existing Internet paths, including NAT interactions. MPT= CP > > assumes that both peers are modified and that one or both peers have > > multiple addresses, which often results in different network paths that > > are at least partially divergent (however, note there is no guarantee > > that the paths are divergent at all). > > > > In its initial charter the WG produced experimental or informational > > documents that defined: > > > > a. An architectural framework for congestion-dependent multipath > > transport protocols. It describes the motivations and the general > > approach that should be followed to enable congestion-dependent > > multipath transport. > > > > b. A security threat analysis for multipath TCP. > > > > c. A coupled multipath-aware congestion control algorithm. This > > algorithm is the multipath equivalent of SACK/NewReno congestion > > control. > > > > d. Extensions to current TCP to support multi-addressed multipath TCP. > > This covers all on-the-wire changes required to create a two-ended MPTC= P > > solution using multiple IP addresses at one or both ends. It includes a > > basic security solution. > > > > e. Application Interface Considerations. It summarises the impact that > > MPTCP may have on applications, such as changes in performance. Also, > > it describes an optional, basic application interface for MPTCP-aware > > applications that provides access to multipath address information and = a > > level of control equivalent to regular TCP. > > > > > > The working group now re-charters to progress various aspects of MPTCP. > > > > The primary goal of the working group is to create a bis version of the > > protocol document on the Standards track. This develops the current > > Experimental document (item d above), incorporating experience from (fo= r > > example) implementations, interoperability events, experiments, usage > > scenarios, protocol corner cases, and feedback from TCPM. There alread= y > > exists a reference Linux implementation and other implementation and > > experimental activity is on-going and will continue during 2012, with > > the objective of progressing the protocol to Standards Track during > > 2013. > > > > The working group will document implementation advice. The current > > documents have several points where an implementer may benefit from > > guidance, for example about heuristics such as buffer sizing, or from > > advice about alternative implementations such as bump-in-the-stack. > > > > The working group will also explore and document results with several > > of the proposed use cases for MPTCP in more detail, to ensure that > > MPTCP works well in practice and that operational experiences and > > issues are understood and captured. Likely use cases are to offload > > traffic from 3G to WiFi, and to manage traffic within a data centre. > > Another scenario is to enable, without changing the MPTCP protocol, > > operation of a single-homed, MPTCP end host on a campus network that ha= s > > multiple providers. > > > > Finally, the working group will explore whether an MPTCP-aware > > middlebox would be useful, where at least one end host is MPTCP-enabled= . > > For example, potentially helping MPTCP=D5s incremental deployment by > > allowing only one end host to be MPTCP-enabled and the middlebox acts a= s > > an MPTCP proxy for the other end host, which runs TCP; and potentially > > helping some mobility scenarios, where the middlebox acts as an anchor > > between two MPTCP-enabled hosts. The working group will detail what rea= l > > problems an MPTCP-enabled middlebox might solve, how it would impact th= e > > Multipath TCP architecture (RFC6182), what proxy approach might be > > justified as compared against alternative solutions to the problems, an= d > > the likely feasibility of solving the technical and security issues. > > > > Goals and Milestones: > > > > Dec 2012 Consensus on what high-level changes are needed to the > > current MPTCP Experimental document in order to progress it on the > > standards track > > > > April 2013 Implementation advice (Informational) to IESG > > > > August 2013 Use cases (Informational) to IESG > > > > Dec 2013 MPTCP-enabled middleboxes (Informational) to IESG > > > > Dec 2013 MPTCP standards track protocol to IESG > > > > Jan 2014 Re-charter or close > > --e89a8f22c70548f3e204c08773e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Adrian,

Thanks for the feedbacks.
We've discussed the &= quot;multi-path" naming from time to time, but there weren't stron= g opinions to change it yet.=A0
"Multi-session" might be bett= er name for some people, but I'm afraid others might =A0misunderstand t= hat MPTCP allows multiple data streams in a single flow.

IMO, I tend to think "path" in transport laye= r as a logical path which is not necessarily mapped to real network topolog= ies. Multiple logical paths can be mapped to a single path in real networks= , but it doesn't break MPTCP's concept at all.


My feeling about milestone is we're just trying to not be lazy.=A0A= s we've finished spec designs for experimental RFCs and have done some = investigations for the potential risks in deployment=A0and we've seen s= everal implementing projects are running actively.
Although I'm not sure they can be "strong push",=A0MPTCP= is getting some attentions from several communities.=A0
Based on= these things, =A0I'm not very sure if making a effort to produce a sta= ndard for two years from now is very hasty thing.
=A0
I understand we will need really strong push when we pub= lish a standard, but not very sure if we need it now.=A0

Rega= rds,
--
Yoshifumi Nishida


On Fri, May 18, 2012 at 1:56 PM, Adrian Farrel <adrian@olddog.co.uk&= gt; wrote:
Hi,

I am struggling with the MPTCP recharter and wonder whether you can help me= .

Firstly, it seems to me that MPTCP is effectively inserting a small session= layer into the stack between the conventional transport layer and the norm= al top-of-layer (presumably the sockets API). I understand why this is conv= enient to the application used, as it is, to attaching to a socket when it = wants to send data, but I am not sure that "hiding" this function= is the best approach. But anyway, that is probably an aside and is a decis= ion long since made by the WG.

I am worried that "multi-path" name may be a misnomer. AFAICS, th= ere is no certain way to keep the two TCP sessions on different paths throu= gh the network. So "multi-session" might be a better name, and wo= uld provide more clarity to the application that uses the feature.

Clearly, there are some significant consequences to not keeping the session= s on different paths, although I understand that there may still be many be= nefits to running multiple parallel sessions. And, of course, ECMP implemen= tations stand a better chance of meaningfully demultiplexing the data onto = different flows if different sessions are used. But still, it seems that MP= TCP is less likely to take advantage of available network resources than mi= ght initially appear to be the case from its name.

How meaningful is MPTCP without MPTCP-aware load balancing routers in the n= etwork? This would seem to be key to getting good use out of the available = resources by putting the multiple sessions into different buckets. Are rout= er vendors demonstrating interest in joining in the experiment?

Indeed, what can you tell me about the take-up of this experiment so far? O= bviously, there are a number of papers I can find by searching the InterWeb= ; these demonstrate the theoretical viability of the work, and I have read = the notes on implementation and testing in the proposed charter. Has the ex= perimentation been conducted on large scale deployed networks with live tra= ffic?

Has anyone put any thought into the risks associated with open deployment? = It is fair enough that "legacy" routers will not know the differe= nce, but do we know that there are no other risks or exposures? Doesn't= MPTCP result in an increase in the number of sessions in the network? How = does that impact on processes running on. in the network?

Can you also tell me about the "hurry". The proposed charter sugg= ests that experimentation is "ongoing" in 2012. The protocol spec= is on its way to the IESG for consideration as an Experimental RFC. Normal= ly it would seem precipitous to start work on Standards Track documents so = soon. Is there a need or a strong push for this? I guess a "need"= would be represented by statements from the industry that a Standards Trac= k RFC is essential for some reason, or maybe a request from another SDO for= something they can reference. A "strong push" might come from im= plementers building product, or from service providers / operators who need= to offer "fat-pipe" services and want to make better use of thei= r network resources. In short, who wants MPTCP?

We (the IETF) do not have an established process for progressing from Exper= imental to the Standards Track (compare with advancement on the Standards T= rack) and I am NOT about to propose one or to impose hurdles for that sort = of change. Sometimes it is blatantly obvious that it is time to make the ch= ange - I would cite PIM and the work in MANET as good examples: real implem= entations and deployments existed, lessons had be learned, and we were read= y for real-time. In other cases it is less obvious and it is helpful to put= together some sort of summary of experimental discoveries, tests undertake= n, and deployments erm deployed. This might be a short I-D that could be pu= blished as an RFC for the historic record. [To be clear, I am not requiring= this in the
case of MPTCP, but it would certainly have helped me work out whether it re= ally is the right time to start work on Standards Track documents.]

Thanks for your patience reading this, and for any explanations you can off= er.

Adrian
> -----Original Message-----
> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
> bounces@ietf.org= ] On Behalf Of IESG Secretary
> Sent: 15 May 2012 19:23
> To: IETF Announcement List
> Cc: multipa= thtcp@ietf.org; philip.eardley@bt.com; nishida@sfc.wide.ad.jp
> Subject: WG Review: Recharter of Multipath TCP (mptcp)
>
> A modified charter has been submitted for the Multipath TCP (mptcp) > working group in the Transport Area of the IETF. =A0The IESG has not m= ade
> any determination as yet. =A0The modified charter is provided below fo= r
> informational purposes only. =A0Please send your comments to the IESG<= br> > mailing list (iesg@= ietf.org) by Tuesday, May 22, 2012.
>
> Multipath TCP (mptcp)
> ----------------------------------------------------------
> Status: Active Working Group
> Last updated: 2012-05-10
>
> Chairs:
> =A0 =A0 Philip Eardley <philip.eardley@bt.com>
> =A0 =A0 Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
>
> Transport Area Directors:
> =A0 =A0 Wesley Eddy <wes@mti-systems.com>
> =A0 =A0 Martin Stiemerling <martin.stiemerling@neclab.eu>
>
> Transport Area Advisor:
> =A0 =A0 Wesley Eddy <wes@mti-systems.com>
>
> Mailing List:
> =A0Address: =A0 =A0 multipathtcp@ietf.org
> =A0To Subscribe: =A0 =A0 =A0 =A0https://www.ietf.org/mailman/lis= tinfo/multipathtcp
> =A0Archive: =A0 =A0 http://www.ietf.org/mail-archive/web/multipa= thtcp/
>
> Description of Working Group:
>
> The Multipath TCP (MPTCP) working group develops mechanisms that add t= he
> capability of simultaneously using multiple paths to a regular TCP
> session. =A0Key goals for MPTCP are: to be deployable and usable witho= ut
> significant changes to existing Internet infrastructure; to be usable = by
> unmodified applications; and to be stable and congestion-safe over the=
> wide range of existing Internet paths, including NAT interactions. =A0= MPTCP
> assumes that both peers are modified and that one or both peers have > multiple addresses, which often results in different network paths tha= t
> are at least partially divergent (however, note there is no guarantee<= br> > that the paths are divergent at all).
>
> In its initial charter the WG produced experimental or informational > documents that defined:
>
> a. An architectural framework for congestion-dependent multipath
> transport protocols. It describes the motivations and the general
> approach that should be followed to enable congestion-dependent
> multipath transport.
>
> b. A security threat analysis for multipath TCP.
>
> c. A coupled multipath-aware congestion control algorithm. This
> algorithm is the multipath equivalent of SACK/NewReno congestion
> control.
>
> d. Extensions to current TCP to support multi-addressed multipath TCP.=
> This covers all on-the-wire changes required to create a two-ended MPT= CP
> solution using multiple IP addresses at one or both ends. It includes = a
> basic security solution.
>
> e. Application Interface Considerations. It summarises the impact that=
> MPTCP may have on applications, such as changes in performance. =A0Als= o,
> it describes an optional, basic application interface for MPTCP-aware<= br> > applications that provides access to multipath address information and= a
> level of control equivalent to regular TCP.
>
>
> The working group now re-charters to progress various aspects of MPTCP= .
>
> The primary goal of the working group is to create a bis version of th= e
> protocol document on the Standards track. This develops the current > Experimental document (item d above), incorporating experience from (f= or
> example) implementations, interoperability events, experiments, usage<= br> > scenarios, protocol corner cases, and feedback from TCPM. =A0There alr= eady
> exists a reference Linux implementation and other implementation and > experimental activity is on-going and will continue during 2012, with<= br> > the objective of progressing the protocol to Standards Track during > 2013.
>
> The working group will document implementation advice. The current
> documents have several points where an implementer may benefit from > guidance, for example about heuristics such as buffer sizing, or from<= br> > advice about alternative implementations such as bump-in-the-stack. >
> The working group will also explore and document results with several<= br> > of the proposed use cases for MPTCP in more detail, to ensure that
> MPTCP works well in practice and that operational experiences and
> issues are understood and captured. =A0Likely use cases are to offload=
> traffic from 3G to WiFi, and to manage traffic within a data centre. > Another scenario is to enable, without changing the MPTCP protocol, > operation of a single-homed, MPTCP end host on a campus network that h= as
> multiple providers.
>
> Finally, the working group will explore whether an MPTCP-aware
> middlebox would be useful, where at least one end host is MPTCP-enable= d.
> For example, potentially helping MPTCP=D5s incremental deployment by > allowing only one end host to be MPTCP-enabled and the middlebox acts = as
> an MPTCP proxy for the other end host, which runs TCP; and potentially=
> helping some mobility scenarios, where the middlebox acts as an anchor=
> between two MPTCP-enabled hosts. The working group will detail what re= al
> problems an MPTCP-enabled middlebox might solve, how it would impact t= he
> Multipath TCP architecture (RFC6182), what proxy approach might be
> justified as compared against alternative solutions to the problems, a= nd
> the likely feasibility of solving the technical and security issues. >
> Goals and Milestones:
>
> Dec 2012 =A0Consensus on what high-level changes are needed to the
> current MPTCP Experimental document in order to progress it on the
> standards track
>
> April 2013 =A0Implementation advice (Informational) to IESG
>
> August 2013 Use cases (Informational) to IESG
>
> Dec 2013 MPTCP-enabled middleboxes (Informational) to IESG
>
> Dec 2013 =A0MPTCP standards track protocol to IESG
>
> Jan 2014 Re-charter or close


--e89a8f22c70548f3e204c08773e1-- From philip.eardley@bt.com Mon May 21 02:23:20 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B814F21F854E; Mon, 21 May 2012 02:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.584 X-Spam-Level: X-Spam-Status: No, score=-100.584 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbqIvqPIbe5c; Mon, 21 May 2012 02:23:14 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 619FE21F8446; Mon, 21 May 2012 02:23:13 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 21 May 2012 10:23:06 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.15]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 21 May 2012 10:23:06 +0100 From: To: , Date: Mon, 21 May 2012 10:23:06 +0100 Thread-Topic: WG Review: Recharter of Multipath TCP (mptcp) Thread-Index: Ac03KV7/MJy+MdI7S9qDpMh6Czwk2gAAUusP Message-ID: <9510D26531EF184D9017DF24659BB87F33C43DF606@EMV65-UKRD.domain1.systemhost.net> References: <20120515182249.22423.80096.idtracker@ietfa.amsl.com> <0ea601cd3538$bab00170$30100450$@olddog.co.uk>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F33C43DF606EMV65UKRDdoma_" MIME-Version: 1.0 Cc: multipathtcp@ietf.org, iesg@ietf.org Subject: Re: [multipathtcp] WG Review: Recharter of Multipath TCP (mptcp) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 09:23:21 -0000 --_000_9510D26531EF184D9017DF24659BB87F33C43DF606EMV65UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adrian, thanks for your comments On the "hiding" question - you're right, this was decided long ago - before= chartering we agreed that it should look like TCP, as far as posible, to a= pplications and the network in order to help ease deployability on the different paths - the WG has assumed that MPTCP's multiple paths are= identified by the end host using different addresses. yes, this means that= the paths can be overlapping - the congestion control algorithm is designe= d to work "safely" even if this is true (ie not get more than single path t= cp would over the bottleneck link, whilst having at least the same throughp= ut). if the end host has interfaces to different ISPs (eg 3G, WiFi) then th= e paths are likely to be disjoint (except perhaps near the other end). we've also had some discussion about other ways that the paths might be ide= ntified - and (normal) ECMP could be used here (again, no guarantee that pa= ths are disjoint) neither of these approaches needs "MPTCP-aware load balancing routers in th= e network". some examples of experiments to date https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-i= mplementing-deployable-multipath-tcp - large scale experiments to test pote= ntial impact of middleboxes on mptcp http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p266.pdf "Improv= ing Datacenter Performance and Robustness with Multipath TCP" - extensive s= imulations plus experiemtns on EC2 there's also a paper from Louvain, accepted for Sigcomm Cellnet, experiment= s about "Exploring Mobile/WiFi Handover with Multipath TCP" [don't think th= is is public yet, but olivier can probably send off-list Olivier.Bonaventur= e@uclouvain.be] Georg Hampel (Alcatel-Lucent) has also been doing an implementation and mob= ility experiments - see slides eg http://tools.ietf.org/agenda/83/slides/sl= ides-83-mptcp-5.pdf so although there's been quite a bit of experiments, I'm not sure this yet = meets your "experimentation .. conducted on large scale deployed networks w= ith live traffic" I expect that further experiments and experience over the next year will su= ggest some tweaks to the current protocol. <> mptcp is designed to look like tcp. today end end hosts create many tcp ses= sions - which has impacted processes in the network. i don't think mptcp ch= anges the scale of this issue. but I agree that one of the aims of further experiments should be to identi= fy if there are unexpected effects on 'things in the network' As regards what "push" there is, I believe that the Louvain guys are now co= ncentrating on trying to get it into the Linux mainline. also, a couple of = meetings ago Oracle said they were about to start work on Solaris. swinburn= e is now working on freeBSD http://caia.swin.edu.au/urp/newtcp/mptcp/ best wishes, phil ________________________________ From: Yoshifumi Nishida [nishida@sfc.wide.ad.jp] Sent: 21 May 2012 09:11 To: adrian@olddog.co.uk Cc: multipathtcp@ietf.org; Eardley,PL,Philip,DUB8 R; iesg@ietf.org Subject: Re: WG Review: Recharter of Multipath TCP (mptcp) Hello Adrian, Thanks for the feedbacks. We've discussed the "multi-path" naming from time to time, but there weren'= t strong opinions to change it yet. "Multi-session" might be better name for some people, but I'm afraid others= might misunderstand that MPTCP allows multiple data streams in a single f= low. IMO, I tend to think "path" in transport layer as a logical path which is n= ot necessarily mapped to real network topologies. Multiple logical paths ca= n be mapped to a single path in real networks, but it doesn't break MPTCP's= concept at all. My feeling about milestone is we're just trying to not be lazy. As we've fi= nished spec designs for experimental RFCs and have done some investigations= for the potential risks in deployment and we've seen several implementing = projects are running actively. Although I'm not sure they can be "strong push", MPTCP is getting some atte= ntions from several communities. Based on these things, I'm not very sure if making a effort to produce a s= tandard for two years from now is very hasty thing. I understand we will need really strong push when we publish a standard, bu= t not very sure if we need it now. Regards, -- Yoshifumi Nishida On Fri, May 18, 2012 at 1:56 PM, Adrian Farrel > wrote: Hi, I am struggling with the MPTCP recharter and wonder whether you can help me= . Firstly, it seems to me that MPTCP is effectively inserting a small session= layer into the stack between the conventional transport layer and the norm= al top-of-layer (presumably the sockets API). I understand why this is conv= enient to the application used, as it is, to attaching to a socket when it = wants to send data, but I am not sure that "hiding" this function is the be= st approach. But anyway, that is probably an aside and is a decision long s= ince made by the WG. I am worried that "multi-path" name may be a misnomer. AFAICS, there is no = certain way to keep the two TCP sessions on different paths through the net= work. So "multi-session" might be a better name, and would provide more cla= rity to the application that uses the feature. Clearly, there are some significant consequences to not keeping the session= s on different paths, although I understand that there may still be many be= nefits to running multiple parallel sessions. And, of course, ECMP implemen= tations stand a better chance of meaningfully demultiplexing the data onto = different flows if different sessions are used. But still, it seems that MP= TCP is less likely to take advantage of available network resources than mi= ght initially appear to be the case from its name. How meaningful is MPTCP without MPTCP-aware load balancing routers in the n= etwork? This would seem to be key to getting good use out of the available = resources by putting the multiple sessions into different buckets. Are rout= er vendors demonstrating interest in joining in the experiment? Indeed, what can you tell me about the take-up of this experiment so far? O= bviously, there are a number of papers I can find by searching the InterWeb= ; these demonstrate the theoretical viability of the work, and I have read = the notes on implementation and testing in the proposed charter. Has the ex= perimentation been conducted on large scale deployed networks with live tra= ffic? Has anyone put any thought into the risks associated with open deployment? = It is fair enough that "legacy" routers will not know the difference, but d= o we know that there are no other risks or exposures? Doesn't MPTCP result = in an increase in the number of sessions in the network? How does that impa= ct on processes running on. in the network? Can you also tell me about the "hurry". The proposed charter suggests that = experimentation is "ongoing" in 2012. The protocol spec is on its way to th= e IESG for consideration as an Experimental RFC. Normally it would seem pre= cipitous to start work on Standards Track documents so soon. Is there a nee= d or a strong push for this? I guess a "need" would be represented by state= ments from the industry that a Standards Track RFC is essential for some re= ason, or maybe a request from another SDO for something they can reference.= A "strong push" might come from implementers building product, or from ser= vice providers / operators who need to offer "fat-pipe" services and want t= o make better use of their network resources. In short, who wants MPTCP? We (the IETF) do not have an established process for progressing from Exper= imental to the Standards Track (compare with advancement on the Standards T= rack) and I am NOT about to propose one or to impose hurdles for that sort = of change. Sometimes it is blatantly obvious that it is time to make the ch= ange - I would cite PIM and the work in MANET as good examples: real implem= entations and deployments existed, lessons had be learned, and we were read= y for real-time. In other cases it is less obvious and it is helpful to put= together some sort of summary of experimental discoveries, tests undertake= n, and deployments erm deployed. This might be a short I-D that could be pu= blished as an RFC for the historic record. [To be clear, I am not requiring= this in the case of MPTCP, but it would certainly have helped me work out whether it re= ally is the right time to start work on Standards Track documents.] Thanks for your patience reading this, and for any explanations you can off= er. Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of IESG Secretary > Sent: 15 May 2012 19:23 > To: IETF Announcement List > Cc: multipathtcp@ietf.org; philip.eardley@b= t.com; nishida@sfc.wide.ad.jp > Subject: WG Review: Recharter of Multipath TCP (mptcp) > > A modified charter has been submitted for the Multipath TCP (mptcp) > working group in the Transport Area of the IETF. The IESG has not made > any determination as yet. The modified charter is provided below for > informational purposes only. Please send your comments to the IESG > mailing list (iesg@ietf.org) by Tuesday, May 22, 20= 12. > > Multipath TCP (mptcp) > ---------------------------------------------------------- > Status: Active Working Group > Last updated: 2012-05-10 > > Chairs: > Philip Eardley > > Yoshifumi Nishida > > > Transport Area Directors: > Wesley Eddy > > Martin Stiemerling > > > Transport Area Advisor: > Wesley Eddy > > > Mailing List: > Address: multipathtcp@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp > Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ > > Description of Working Group: > > The Multipath TCP (MPTCP) working group develops mechanisms that add the > capability of simultaneously using multiple paths to a regular TCP > session. Key goals for MPTCP are: to be deployable and usable without > significant changes to existing Internet infrastructure; to be usable by > unmodified applications; and to be stable and congestion-safe over the > wide range of existing Internet paths, including NAT interactions. MPTCP > assumes that both peers are modified and that one or both peers have > multiple addresses, which often results in different network paths that > are at least partially divergent (however, note there is no guarantee > that the paths are divergent at all). > > In its initial charter the WG produced experimental or informational > documents that defined: > > a. An architectural framework for congestion-dependent multipath > transport protocols. It describes the motivations and the general > approach that should be followed to enable congestion-dependent > multipath transport. > > b. A security threat analysis for multipath TCP. > > c. A coupled multipath-aware congestion control algorithm. This > algorithm is the multipath equivalent of SACK/NewReno congestion > control. > > d. Extensions to current TCP to support multi-addressed multipath TCP. > This covers all on-the-wire changes required to create a two-ended MPTCP > solution using multiple IP addresses at one or both ends. It includes a > basic security solution. > > e. Application Interface Considerations. It summarises the impact that > MPTCP may have on applications, such as changes in performance. Also, > it describes an optional, basic application interface for MPTCP-aware > applications that provides access to multipath address information and a > level of control equivalent to regular TCP. > > > The working group now re-charters to progress various aspects of MPTCP. > > The primary goal of the working group is to create a bis version of the > protocol document on the Standards track. This develops the current > Experimental document (item d above), incorporating experience from (for > example) implementations, interoperability events, experiments, usage > scenarios, protocol corner cases, and feedback from TCPM. There already > exists a reference Linux implementation and other implementation and > experimental activity is on-going and will continue during 2012, with > the objective of progressing the protocol to Standards Track during > 2013. > > The working group will document implementation advice. The current > documents have several points where an implementer may benefit from > guidance, for example about heuristics such as buffer sizing, or from > advice about alternative implementations such as bump-in-the-stack. > > The working group will also explore and document results with several > of the proposed use cases for MPTCP in more detail, to ensure that > MPTCP works well in practice and that operational experiences and > issues are understood and captured. Likely use cases are to offload > traffic from 3G to WiFi, and to manage traffic within a data centre. > Another scenario is to enable, without changing the MPTCP protocol, > operation of a single-homed, MPTCP end host on a campus network that has > multiple providers. > > Finally, the working group will explore whether an MPTCP-aware > middlebox would be useful, where at least one end host is MPTCP-enabled. > For example, potentially helping MPTCP=D5s incremental deployment by > allowing only one end host to be MPTCP-enabled and the middlebox acts as > an MPTCP proxy for the other end host, which runs TCP; and potentially > helping some mobility scenarios, where the middlebox acts as an anchor > between two MPTCP-enabled hosts. The working group will detail what real > problems an MPTCP-enabled middlebox might solve, how it would impact the > Multipath TCP architecture (RFC6182), what proxy approach might be > justified as compared against alternative solutions to the problems, and > the likely feasibility of solving the technical and security issues. > > Goals and Milestones: > > Dec 2012 Consensus on what high-level changes are needed to the > current MPTCP Experimental document in order to progress it on the > standards track > > April 2013 Implementation advice (Informational) to IESG > > August 2013 Use cases (Informational) to IESG > > Dec 2013 MPTCP-enabled middleboxes (Informational) to IESG > > Dec 2013 MPTCP standards track protocol to IESG > > Jan 2014 Re-charter or close --_000_9510D26531EF184D9017DF24659BB87F33C43DF606EMV65UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Adrian,
 
thanks for your comments
 
On the "hiding" question - you're righ= t, this was decided long ago - before chartering we agreed that it should l= ook like TCP, as far as posible, to applications and the network in order t= o help ease deployability
 
on the different paths - the WG has = assumed that MPTCP's multiple paths are identified by the end host using di= fferent addresses. yes, this means that the paths can be overlapping - the = congestion control algorithm is designed to work "safely" even if this is true (ie not get more than sing= le path tcp would over the bottleneck link, whilst having at least the same= throughput). if the end host has interfaces to different ISPs (eg 3G, WiFi= ) then the paths are likely to be disjoint (except perhaps near the other end).
we've also had some discussion about= other ways that the paths might be identified - and (normal) ECMP could be= used here (again, no guarantee that paths are disjoint)
neither of these approaches needs &q= uot;MPTCP-aware load balancing routers in the network".
 
some examples of experiments to= date
https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-design= ing-and-implementing-deployable-multipath-tcp - large scale experiments to test potential impact of middleboxes on mptcp=

http://co= nferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p266.pdf "<= font size=3D"5" face=3D"Helvetica-Bold">Improving Datacenter Performance and Robustness with Multipa= th TCP" - extensive simulations plus experiemtns on EC2

there's also a paper from Louvain, accepted for Si= gcomm Cellnet, experiments about "Exploring = Mobile/WiFi Handover with Multipath TCP" [don't think this is public yet, but olivier can probably send off-list Olivier.Bonaventure@uclouvain.be]

Georg Hampel (Alcatel-Lucent) has also been doing an imple= mentation and mobility experiments - see slides eg http://tools.ietf.org/agenda/83/slides/slides-83-mptcp-5.pdf
 
so although there's been quite a bit= of experiments, I'm not sure this yet meets your "experimentation .. = conducted on large scale deployed networks with live traffic"
 
I expect that further experiments an= d experience over the next year will suggest some tweaks to the curren= t protocol.
 
<<Doesn't MPTCP result in an i= ncrease in the number of sessions in the network? How does that impact on p= rocesses running on. in the network?>>
mptcp is designed to look like tcp. = today end end hosts create many tcp sessions - which has impacted processes= in the network. i don't think mptcp changes the scale of this issue.<= /font>
but I agree that one of the aims of = further experiments should be to identify if there are unexpected effects o= n 'things in the network'
 
As regards what "push" the= re is, I believe that the Louvain guys are now concentrating on trying to g= et it into the Linux mainline. also, a couple of meetings ago Oracle said t= hey were about to start work on Solaris. swinburne is now working on freeBSD http://caia.swin.edu.au/urp/newtcp/mptcp/
 
best wishes,
phil
 
 
From: Yoshifumi N= ishida [nishida@sfc.wide.ad.jp]
Sent: 21 May 2012 09:11
To: adrian@olddog.co.uk
Cc: multipathtcp@ietf.org; Eardley,PL,Philip,DUB8 R; iesg@ietf.org Subject: Re: WG Review: Recharter of Multipath TCP (mptcp)

Hello Adrian,

Thanks for the feedbacks.
We've discussed the "multi-path" naming from time to time, but th= ere weren't strong opinions to change it yet. 
"Multi-session" might be better name for some people, but I'= m afraid others might  misunderstand that MPTCP allows multiple data s= treams in a single flow.

IMO, I tend to think "path" in transport layer as a logical = path which is not necessarily mapped to real network topologies. Multiple l= ogical paths can be mapped to a single path in real networks, but it doesn'= t break MPTCP's concept at all.


My feeling about milestone is we're just trying to not be lazy. As we'= ve finished spec designs for experimental RFCs and have done some investiga= tions for the potential risks in deployment and we've seen several imp= lementing projects are running actively.
Although I'm not sure they can be "strong push", MPTCP = is getting some attentions from several communities. 
Based on these things,  I'm not very sure if making a effort to p= roduce a standard for two years from now is very hasty thing.
 
I understand we will need really strong push when we publish a standar= d, but not very sure if we need it now. 

Regards,
--
Yoshifumi Nishida


On Fri, May 18, 2012 at 1:56 PM, Adrian Farrel <= span dir=3D"ltr"> <adrian@olddog.co.uk> wrote:
Hi,

I am struggling with the MPTCP recharter and wonder whether you can help me= .

Firstly, it seems to me that MPTCP is effectively inserting a small session= layer into the stack between the conventional transport layer and the norm= al top-of-layer (presumably the sockets API). I understand why this is conv= enient to the application used, as it is, to attaching to a socket when it wants to send data, but I am no= t sure that "hiding" this function is the best approach. But anyw= ay, that is probably an aside and is a decision long since made by the WG.<= br>
I am worried that "multi-path" name may be a misnomer. AFAICS, th= ere is no certain way to keep the two TCP sessions on different paths throu= gh the network. So "multi-session" might be a better name, and wo= uld provide more clarity to the application that uses the feature.

Clearly, there are some significant consequences to not keeping the session= s on different paths, although I understand that there may still be many be= nefits to running multiple parallel sessions. And, of course, ECMP implemen= tations stand a better chance of meaningfully demultiplexing the data onto different flows if different ses= sions are used. But still, it seems that MPTCP is less likely to take advan= tage of available network resources than might initially appear to be the c= ase from its name.

How meaningful is MPTCP without MPTCP-aware load balancing routers in the n= etwork? This would seem to be key to getting good use out of the available = resources by putting the multiple sessions into different buckets. Are rout= er vendors demonstrating interest in joining in the experiment?

Indeed, what can you tell me about the take-up of this experiment so far? O= bviously, there are a number of papers I can find by searching the InterWeb= ; these demonstrate the theoretical viability of the work, and I have read = the notes on implementation and testing in the proposed charter. Has the experimentation been conducted on= large scale deployed networks with live traffic?

Has anyone put any thought into the risks associated with open deployment? = It is fair enough that "legacy" routers will not know the differe= nce, but do we know that there are no other risks or exposures? Doesn't MPT= CP result in an increase in the number of sessions in the network? How does that impact on processes running on. in = the network?

Can you also tell me about the "hurry". The proposed charter sugg= ests that experimentation is "ongoing" in 2012. The protocol spec= is on its way to the IESG for consideration as an Experimental RFC. Normal= ly it would seem precipitous to start work on Standards Track documents so soon. Is there a need or a strong push for this? I gues= s a "need" would be represented by statements from the industry t= hat a Standards Track RFC is essential for some reason, or maybe a request = from another SDO for something they can reference. A "strong push" might come from implementers building product, o= r from service providers / operators who need to offer "fat-pipe"= services and want to make better use of their network resources. In short,= who wants MPTCP?

We (the IETF) do not have an established process for progressing from Exper= imental to the Standards Track (compare with advancement on the Standards T= rack) and I am NOT about to propose one or to impose hurdles for that sort = of change. Sometimes it is blatantly obvious that it is time to make the change - I would cite PIM and the work= in MANET as good examples: real implementations and deployments existed, l= essons had be learned, and we were ready for real-time. In other cases it i= s less obvious and it is helpful to put together some sort of summary of experimental discoveries, tests un= dertaken, and deployments erm deployed. This might be a short I-D that coul= d be published as an RFC for the historic record. [To be clear, I am not re= quiring this in the
case of MPTCP, but it would certainly have helped me work out whether it re= ally is the right time to start work on Standards Track documents.]

Thanks for your patience reading this, and for any explanations you can off= er.

Adrian
> -----Original Message-----
> From: ietf-announce-= bounces@ietf.org [mailto:ietf-announc= e-
> bounces@ietf.org] On Behalf Of= IESG Secretary
> Sent: 15 May 2012 19:23
> To: IETF Announcement List
> Cc: multipathtcp@ietf.org= ; philip.eardley@bt.com; nishid= a@sfc.wide.ad.jp
> Subject: WG Review: Recharter of Multipath TCP (mptcp)
>
> A modified charter has been submitted for the Multipath TCP (mptcp) > working group in the Transport Area of the IETF.  The IESG has no= t made
> any determination as yet.  The modified charter is provided below= for
> informational purposes only.  Please send your comments to the IE= SG
> mailing list (iesg@ietf.org) by T= uesday, May 22, 2012.
>
> Multipath TCP (mptcp)
> ----------------------------------------------------------
> Status: Active Working Group
> Last updated: 2012-05-10
>
> Chairs:
>     Philip Eardley <philip.eardley@bt.com>
>     Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
>
> Transport Area Directors:
>     Wesley Eddy <w= es@mti-systems.com>
>     Martin Stiemerling <martin.stiemerling@neclab.eu>
>
> Transport Area Advisor:
>     Wesley Eddy <w= es@mti-systems.com>
>
> Mailing List:
>  Address:     = multipathtcp@ietf.org
>  To Subscribe:        https://www.ietf.= org/mailman/listinfo/multipathtcp
>  Archive:     http://www.ietf.org/mail-archive/web/multipathtcp/
>
> Description of Working Group:
>
> The Multipath TCP (MPTCP) working group develops mechanisms that add t= he
> capability of simultaneously using multiple paths to a regular TCP
> session.  Key goals for MPTCP are: to be deployable and usable wi= thout
> significant changes to existing Internet infrastructure; to be usable = by
> unmodified applications; and to be stable and congestion-safe over the=
> wide range of existing Internet paths, including NAT interactions. &nb= sp;MPTCP
> assumes that both peers are modified and that one or both peers have > multiple addresses, which often results in different network paths tha= t
> are at least partially divergent (however, note there is no guarantee<= br> > that the paths are divergent at all).
>
> In its initial charter the WG produced experimental or informational > documents that defined:
>
> a. An architectural framework for congestion-dependent multipath
> transport protocols. It describes the motivations and the general
> approach that should be followed to enable congestion-dependent
> multipath transport.
>
> b. A security threat analysis for multipath TCP.
>
> c. A coupled multipath-aware congestion control algorithm. This
> algorithm is the multipath equivalent of SACK/NewReno congestion
> control.
>
> d. Extensions to current TCP to support multi-addressed multipath TCP.=
> This covers all on-the-wire changes required to create a two-ended MPT= CP
> solution using multiple IP addresses at one or both ends. It includes = a
> basic security solution.
>
> e. Application Interface Considerations. It summarises the impact that=
> MPTCP may have on applications, such as changes in performance.  = Also,
> it describes an optional, basic application interface for MPTCP-aware<= br> > applications that provides access to multipath address information and= a
> level of control equivalent to regular TCP.
>
>
> The working group now re-charters to progress various aspects of MPTCP= .
>
> The primary goal of the working group is to create a bis version of th= e
> protocol document on the Standards track. This develops the current > Experimental document (item d above), incorporating experience from (f= or
> example) implementations, interoperability events, experiments, usage<= br> > scenarios, protocol corner cases, and feedback from TCPM.  There = already
> exists a reference Linux implementation and other implementation and > experimental activity is on-going and will continue during 2012, with<= br> > the objective of progressing the protocol to Standards Track during > 2013.
>
> The working group will document implementation advice. The current
> documents have several points where an implementer may benefit from > guidance, for example about heuristics such as buffer sizing, or from<= br> > advice about alternative implementations such as bump-in-the-stack. >
> The working group will also explore and document results with several<= br> > of the proposed use cases for MPTCP in more detail, to ensure that
> MPTCP works well in practice and that operational experiences and
> issues are understood and captured.  Likely use cases are to offl= oad
> traffic from 3G to WiFi, and to manage traffic within a data centre. > Another scenario is to enable, without changing the MPTCP protocol, > operation of a single-homed, MPTCP end host on a campus network that h= as
> multiple providers.
>
> Finally, the working group will explore whether an MPTCP-aware
> middlebox would be useful, where at least one end host is MPTCP-enable= d.
> For example, potentially helping MPTCP=D5s incremental deployment by > allowing only one end host to be MPTCP-enabled and the middlebox acts = as
> an MPTCP proxy for the other end host, which runs TCP; and potentially=
> helping some mobility scenarios, where the middlebox acts as an anchor=
> between two MPTCP-enabled hosts. The working group will detail what re= al
> problems an MPTCP-enabled middlebox might solve, how it would impact t= he
> Multipath TCP architecture (RFC6182), what proxy approach might be
> justified as compared against alternative solutions to the problems, a= nd
> the likely feasibility of solving the technical and security issues. >
> Goals and Milestones:
>
> Dec 2012  Consensus on what high-level changes are needed to the<= br> > current MPTCP Experimental document in order to progress it on the
> standards track
>
> April 2013  Implementation advice (Informational) to IESG
>
> August 2013 Use cases (Informational) to IESG
>
> Dec 2013 MPTCP-enabled middleboxes (Informational) to IESG
>
> Dec 2013  MPTCP standards track protocol to IESG
>
> Jan 2014 Re-charter or close


--_000_9510D26531EF184D9017DF24659BB87F33C43DF606EMV65UKRDdoma_-- From olivier.bonaventure@uclouvain.be Mon May 21 03:23:48 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C816B21F8625; Mon, 21 May 2012 03:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q-st+M8LzHd; Mon, 21 May 2012 03:23:47 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6588721F861F; Mon, 21 May 2012 03:23:47 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 2744D11E45F; Mon, 21 May 2012 12:23:37 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 2744D11E45F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1337595817; bh=yA0cqjOfiP6QGmYIelqn6qGuqtNVoPf7d78hE9XPdl4=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=RItvAVL+nwVam+7KTSiVPFUNN8brsVtMgHwzKx9jn/yCFflieSszt4zV6Jyf76skU Iika8NTFqDSKgC2cgbCCkxAlRnVHHfNFdzmnCCooChar3bcAUx/qBh0rhocbNMXJKB o4fTLTRl5ExZXLSWheY1f+zUHSv07TddMEUav6yU= Message-ID: <4FBA17A8.1030100@uclouvain.be> Date: Mon, 21 May 2012 12:23:36 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <20120515182249.22423.80096.idtracker@ietfa.amsl.com> <0ea601cd3538$bab00170$30100450$@olddog.co.uk> In-Reply-To: <0ea601cd3538$bab00170$30100450$@olddog.co.uk> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 2744D11E45F.A4B83 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org, iesg@ietf.org Subject: Re: [multipathtcp] WG Review: Recharter of Multipath TCP (mptcp) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 10:23:48 -0000 Adrian, > > I am struggling with the MPTCP recharter and wonder whether you can help me. > > Firstly, it seems to me that MPTCP is effectively inserting a small session layer into the stack between the conventional transport layer and the normal top-of-layer (presumably the sockets API). I understand why this is convenient to the application used, as it is, to attaching to a socket when it wants to send data, but I am not sure that "hiding" this function is the best approach. The main advantage of this approach is that existing applications do not have to be modified. SCTP took a different approach by changing the protocol number in the IP header and the socket API. This made SCTP very difficult to be deployed. MPTCP can be incrementally deployed. > But anyway, that is probably an aside and is a decision long since made by the WG. > I am worried that "multi-path" name may be a misnomer. I tend to agree. A few weeks ago, I discussed with a routing researcher who saw Multipath TCP as a way to "virtualise" a TCP connection. In fact, Multipath TCP decouples a TCP connection from its IP endpoints. In the 1970s, the designers of TCP/IP chose to couple TCP and IP by introducing the pseudo-header in the checksum computation. In this long term, this proved to be a bad design decision that forces TCP connections to be reset every time a host changes its IP address. > AFAICS, there is no certain way to keep the two TCP sessions on different paths through the network. Agreed, there is no guarantee that two TCP connections between the same IP addresses will follow a different path. In many networks, this is likely. When one of the endpoints uses different IP adresses (e.g. an IPv4 and an IPv6 address or a WiFi and a 3G interface), then the TCP connections use different paths. >So "multi-session" might be a better name, and would provide more clarity to the application that uses the feature. Maybe, but I'm not sure that changing the name is necessary. > Clearly, there are some significant consequences to not keeping the sessions on different paths, although I understand that there may still be many benefits to running multiple parallel sessions. And, of course, ECMP implementations stand a better chance of meaningfully demultiplexing the data onto different flows if different sessions are used. But still, it seems that MPTCP is less likely to take advantage of available network resources than might initially appear to be the case from its name. > > How meaningful is MPTCP without MPTCP-aware load balancing routers in the network? This would seem to be key to getting good use out of the available resources by putting the multiple sessions into different buckets. Are router vendors demonstrating interest in joining in the experiment? Note that MPTCP does not require any MPTCP-awareness in the network. MPTCP was designed with existing networks in mind and can exploit current paths or fallback to regular TCP when strange middleboxes interfere. See "Is it still possible to extend TCP" presented at IMC and available from http://www.micchie.net/publications.html Two interesting case studies : - a host with IPv4 and IPv6 can open a TCP connection over IPv4 and learn through MPTCP that the server also supports IPv6 and use both IPv4 and IPv6 to retrieve data over a single MPTCP conenction - a smartphone with WiFi and 3G interfaces can use Multipath TCP to switch from WiFi to 3G when WiFi fails and the opposite. See http://inl.info.ucl.ac.be/publications/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp A video of the smartphone case study is available at http://mptcp.info.ucl.ac.be > Indeed, what can you tell me about the take-up of this experiment so far? Obviously, there are a number of papers I can find by searching the InterWeb; these demonstrate the theoretical viability of the work, and I have read the notes on implementation and testing in the proposed charter. Has the experimentation been conducted on large scale deployed networks with live traffic? The Linux kernel implementation is available from the website above. We have conducted successful experiments in labs, through two 3G providers, through several ADSL providers and are using MPTCP over the global Internet. > Has anyone put any thought into the risks associated with open deployment? It is fair enough that "legacy" routers will not know the difference, but do we know that there are no other risks or exposures? Doesn't MPTCP result in an increase in the number of sessions in the network? This is a function on how the MPTCP implementation is configured. A web client can open a large number of TCP connections. An MPTCP implementation can open one or more TCP subflows per MPTCP connection. Smartphones could open a single TCP subflow and use it mainly for handover. Servers could use more subflows depending on the network conditions. > How does that impact on processes running on. in the network? > > Can you also tell me about the "hurry". The proposed charter suggests that experimentation is "ongoing" in 2012. The protocol spec is on its way to the IESG for consideration as an Experimental RFC. Normally it would seem precipitous to start work on Standards Track documents so soon. Is there a need or a strong push for this? I guess a "need" would be represented by statements from the industry that a Standards Track RFC is essential for some reason, or maybe a request from another SDO for something they can reference. A "strong push" might come from implementers building product, or from service providers / operators who need to offer "fat-pipe" services and want to make better use of their network resources. In short, who wants MPTCP? > We have seen a growing interest in using Multipath TCP to support 3G/WiFi offload and the Linux implementation supports this. Georg Hampl is also working on another implementation for this environment. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From john@jlc.net Mon May 21 05:44:01 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DCE21F8649 for ; Mon, 21 May 2012 05:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBadWQ0fb+Dx for ; Mon, 21 May 2012 05:44:00 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 46FF521F8648 for ; Mon, 21 May 2012 05:44:00 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4848F33C22; Mon, 21 May 2012 08:43:59 -0400 (EDT) Date: Mon, 21 May 2012 08:43:59 -0400 From: John Leslie To: Adrian Farrel Message-ID: <20120521124359.GA95486@verdi> References: <20120515182249.22423.80096.idtracker@ietfa.amsl.com> <0ea601cd3538$bab00170$30100450$@olddog.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ea601cd3538$bab00170$30100450$@olddog.co.uk> User-Agent: Mutt/1.4.1i Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Review: Recharter of Multipath TCP (mptcp) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 12:44:01 -0000 Adrian Farrel wrote: > > I am struggling with the MPTCP recharter and wonder whether you can help me. I'd be happy to try... > Firstly, it seems to me that MPTCP is effectively inserting a small > session layer into the stack between the conventional transport layer > and the normal top-of-layer (presumably the sockets API). I guess that's one way to think of it... Myself, I think of TCP as a "transport" layer; and MPTCP is careful to look exactly like a transport layer to the network and almost-exactly like a transport layer to the endpoints, with some magic so that the network may see more than one connection matching the single logical connection of the endpoints. > I understand why this is convenient to the application used, as it is, > to attaching to a socket when it wants to send data, but I am not sure > that "hiding" this function is the best approach. "Hiding" from the network is, alas, essential. (And it's really none of its business, anyway!) "Hiding" from the application layer is not essential; and I fully expect that as time progresses, there will be less of it. > But anyway, that is probably an aside and is a decision long since made > by the WG. > > I am worried that "multi-path" name may be a misnomer. Likewise, a decision long-since-made. Re-naming it at this stage is not reasonable. > AFAICS, there is no certain way to keep the two TCP sessions on > different paths through the network. True, but irrelevant, IMHO. Besides, _all_ names are optimistic! > So "multi-session" might be a better name, and would provide more > clarity to the application that uses the feature. I don't agree it would be a better name. Multi "path" better expresses the aim of MPTCP; and (IMHO) it's a better thing to aim for. > Clearly, there are some significant consequences to not keeping the > sessions on different paths, I don't follow... There is no way we could ensure separate paths. There are too many cases where enterprises have been paying telcos for separate-path T-1s only to learn they weren't separate at all! > although I understand that there may still be many benefits to > running multiple parallel sessions. Perhaps the most important benefit is being able to bring up and take down paths as conditions change. > ... But still, it seems that MPTCP is less likely to take advantage > of available network resources than might initially appear to be the > case from its name. That's not a fair criticism. MPTCP will take advantage of network resorces that _are_ available. There's a chicken-and-egg issue of why the resources would _be_ available before there's a practical way to use them. > How meaningful is MPTCP without MPTCP-aware load balancing routers > in the network? 100% (I can't quite conceive of anything for such an animal to _do_...) > This would seem to be key to getting good use out of the available > resources by putting the multiple sessions into different buckets. MPTCP isn't aiming there, if I understand your issue. MPTCP is aiming at being able to move traffic over a less-congested path (or off of a failed path) without requiring application-layer action. It also holds promise of easing a transition from IPv4 to IPv6. Bonding "equal" paths really isn't an aim -- that's better done at a lower layer. > ... Has the experimentation been conducted on large scale deployed > networks with live traffic? The point, IMHO, is that we're nearing the stage where the "experiment" can't be backed out. (And this will pretty much happen regardless of what the IESG may do.) Most of the WG participants are convinced there's been enough experimenting to show that MPTCP can be safely deployed in the big-I internet. > Has anyone put any thought into the risks associated with open > deployment? Yes. (Quite a bit of thought, actually.) > It is fair enough that "legacy" routers will not know the difference, > but do we know that there are no other risks or exposures? Omniscience isn't a pre-requisite in the IETF. (Not even for IESG members!) > Doesn't MPTCP result in an increase in the number of sessions in the > network? How does that impact on processes running on. in the network? I don't understand the question. A network layer, by definition, doesn't worry about "sessions" -- it moves "packets". > ... The protocol spec is on its way to the IESG for consideration as > an Experimental RFC. Normally it would seem precipitous to start work > on Standards Track documents so soon. That's not a helpful norm. Work on Standards Track should _start_ as soon as the experiment wants to run on the big-I internet. It will, of course, typically take more than a year to finish... > Is there a need or a strong push for this? I guess a "need" would be > represented by statements from the industry that a Standards Track > RFC is essential for some reason, or maybe a request from another SDO > for something they can reference. That's a funny way to define "need" (IMHO). There was a time when "Experimental" status meant "Please go away." That time has passed. Now "Experimental" status means "not (necessarily) safe to use on the big-I internet". It's something we'd like to be able to back out if it proves dangerous. I see a "need" for Standards-track coming as early as we admit the experiment _won't_ be backed out. And IMHO MPTCP is really-close to that point. Delaying the start of Standards-track won't delay the point where we can't back it out -- it will only make it harder to avoid danger points. > ... We (the IETF) do not have an established process for progressing > from Experimental to the Standards Track... Sometimes it is blatantly > obvious... In other cases it is less obvious and it is helpful to put > together some sort of summary of experimental discoveries, tests > undertaken, and deployments erm deployed. Those things belong in the revised charter, certainly. > ... it would certainly have helped me work out whether it really is > the right time to start work on Standards Track documents. (Omniscience isn't a pre-requisite for IESG members.) IMHO, trying to "time" the "start" of such work belongs to the Responsible AD, not the other IESG members; and even the Responsible AD shouldn't aim to time it very exactly. If there are folks willing to do the work and a benefit is reasonably likely, it seems to me chartering such work is entirely proper. -- John Leslie From nishida@sfc.wide.ad.jp Fri May 25 01:11:18 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5C121F855D for ; Fri, 25 May 2012 01:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zkl0wwtgFvu for ; Fri, 25 May 2012 01:11:17 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 95DD221F855F for ; Fri, 25 May 2012 01:11:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 343392780B9 for ; Fri, 25 May 2012 17:11:13 +0900 (JST) Received: by lagv3 with SMTP id v3so511047lag.31 for ; Fri, 25 May 2012 01:11:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.39.135 with SMTP id p7mr1104006lbk.78.1337933471574; Fri, 25 May 2012 01:11:11 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Fri, 25 May 2012 01:11:11 -0700 (PDT) Date: Fri, 25 May 2012 01:11:11 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] vancouver meeting slot X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 08:11:18 -0000 Hello folks, Phil and I are thinking about the WG meeting slot at vancouver. If you are planning to make a presentation at vancouver meeting, or, if you have some topics to be discussed at the meeting, please let us know. Thanks, -- Yoshifumi & Phil From internet-drafts@ietf.org Fri May 25 03:15:39 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E7521F8611; Fri, 25 May 2012 03:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9PMiPe9IQJw; Fri, 25 May 2012 03:15:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D9121F85D9; Fri, 25 May 2012 03:15:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120525101539.22947.11282.idtracker@ietfa.amsl.com> Date: Fri, 25 May 2012 03:15:39 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-08.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 10:15:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IE= TF. Title : TCP Extensions for Multipath Operation with Multiple Add= resses Author(s) : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-multiaddressed-08.txt Pages : 62 Date : 2012-05-25 TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ From alanford@cisco.com Fri May 25 03:17:13 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5992921F85F9 for ; Fri, 25 May 2012 03:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEUYSicNaFJo for ; Fri, 25 May 2012 03:17:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 99AEF21F85F8 for ; Fri, 25 May 2012 03:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=15746; q=dns/txt; s=iport; t=1337941028; x=1339150628; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=1iH4s4/guOiRX9vP+F8QFLW4rH6lqjWozvwMSX8mMFA=; b=SDXx0fNcmdHzA+cwvwYVF9mKIchIpBpHzT57ukW6mCpUN6m/7VZEYHXA YPaC1RR9rrXw0dlL/V0dyMT2voCte1Mtg5jjXbcuDy5Abh2h5css47xYz Cz0fLdZnVPW9++Q1mkgdLWL+ylQvQirH2HXr3M1fQO4UnyG1a2VN+dtQc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGAHBbv0+Q/khR/2dsb2JhbABEgkWxVYEHAoEHghUBAQEDAQEBAQ8BFBYxCwUNAQgYVTABAQQOBR8Dh2YFC5tJn3EEiwEUhTIDiAyNDI4MJ4E9gmGBVQ X-IronPort-AV: E=Sophos;i="4.75,655,1330905600"; d="scan'208,217";a="73629092" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 25 May 2012 10:17:07 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4PAH7Nm009808; Fri, 25 May 2012 10:17:07 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 12:17:07 +0200 Received: from 144.254.90.168 ([144.254.90.168]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 May 2012 10:17:06 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Fri, 25 May 2012 11:17:02 +0100 From: Alan Ford To: Yoshifumi Nishida Message-ID: Thread-Topic: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 Thread-Index: Ac06X4a2Horx3OHYG0GBmFQcQd3jJQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3420789422_3109317" X-OriginalArrivalTime: 25 May 2012 10:17:07.0005 (UTC) FILETIME=[89B1D6D0:01CD3A5F] Cc: multipathtcp Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 10:17:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3420789422_3109317 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Yoshifumi, Thank you for your feedback. Anything I haven=B9t directly commented on below was straightforwardly addressed in =AD08. If there is anything you feel wasn=B9= t sufficiently addressed, please shout. Regards, Alan On 18/04/2012 07:03, "Yoshifumi Nishida" wrote: > Hi authors, >=20 > Sorry. I would like to add one more thing. >=20 > This draft requires to create new registries for subtypes of mptcp option= and > cryptographic algorithms handshake in MP_CAPABLE.=A0 > For this, you will need to add the description of the policy used for man= aging > these registries in the IANA considerations section. Please check the sec= tion > 4 of RFC5226 to see the available choices (Section 4.1) and update the te= xts > based on the guideline (Section 4.2). >=20 > Thanks, > -- > Yoshifumi Nishida >=20 >=20 >=20 >=20 > On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida > wrote: >> Hello, >>=20 >> Sorry for the long delay. >> We believe it's good time to proceed to submit >> draft-ietf-mptcp-multiaddressed to IESG. >>=20 >> Here's my comments on the draft to prepare a write-up for the draft. >> Please check and update if you agree with them. >>=20 >> Thanks, >> -- >> Yoshifumi >>=20 >>=20 >> Page 13: >> =A0 3.1. Connection Initiation >>=20 >> =A0 =A0 -> =A0In my understanding, the key MUST be unique for each mptcp >> connection.=20 >> =A0 =A0 =A0 =A0 =A0If so, I think we had better articulate it here. >>=20 >> [Alan] Unique per host, yes. I believe that is clear already; certainly,= I >> couldn=B9t find a way of making it any clearer. >>=20 >> Page 17: >> =A0 =A0A host MUST store the Address IDs associated with all established >> subflows. >>=20 >> =A0 =A0-> Does this mean both local Address IDs and remote Address IDs >> advertized from the receiver? >> =A0 =A0 =A0 =A0It might be better to clarify this. >>=20 >> [Alan] Yes it does, and I have clarified that. >>=20 >> Page 18: >> =A0 =A0therefore receipt of this packet MUST trigger an ACK in response >>=20 >> =A0 =A0-> Since this is MUST, I think Figure 8 needs to include this ACK in= the >> sequence. >>=20 >>=20 >> =A0 =A0the packet MUST be retransmitted if this ACK is not received. >>=20 >> =A0 =A0-> In case of MP_CAPABLE, the third packet is not retransmitted. >> =A0 =A0 =A0 =A0But, in case of MP_JOIN, it's retransmitted. Readers might want = to >> know the rationale about this. >>=20 >> [Alan] It=B9s a completely different exchange, sending completely differen= t >> information: it=B9s a crypto handshake not a key exchange. I had hoped tha= t >> would have been sufficiently clear, but I=B9ve added a few words anyway. >> =A0=20 >> Page 27: >>=20 >> =A0=A0 Essentially, a host MUST NOT FIN all functioning subflows unless it i= s >> safe to do so >> =A0=A0=20 >> =A0=A0=A0 -> MUST NOT close? >>=20 >> Page 28: >> =A0 >> =A0=A0 Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to cl= ean >> up state even if the subflow is failed. >> =A0=A0 -> I'm not very sure which situations can be addressed by this.. >>=20 >> [Alan] Changed to =B3Both hosts SHOULD send FINs on all subflows, as a cou= rtesy >> to allow middleboxes to clean up state even if an individual subflow is = no >> longer operational end-to-end.=B2. This is in the case if a link has faile= d in >> the path somewhere, but one of the end hosts is behind a middlebox. That= host >> would never receive a FIN on the subflow, and neither would the middlebo= x. >> But the end host knows the subflow should be closed, so by sending a FIN= it >> aids in cleaning up. >>=20 >> =A0=A0 .. >> =A0=A0 Note that a host may also send a FIN on an individual subflow to shut= it >> down, but this impact is limited to the subflow in question. >>=20 >> =A0=A0 -> Sorry. I couldn't understand this sentences well.. >>=20 >> [Alan] Changed to =B3As specified above, a standard TCP FIN on an individu= al >> subflow only shuts down the subflow on which it was sent.=B2 >>=20 >> Page 30: >>=20 >> =A0=A0=A0 The sender also remembers the receive windows advertised by each sub= flow. >> =A0=A0=20 >> =A0=A0=A0 -> Don't we need to put SHOULD or MUST here? >>=20 >> =A0=A0=A0 The send buffer must be, at the minimum, as big as the receive buffe= r >>=20 >> =A0=A0=A0 -> MUST? >>=20 >> =A0=A0=A0 When doing this, a host must still retransmit the original data on t= he >> original subflow, >> =A0 >> =A0=A0=A0 -> MUST? >>=20 >> Page 37: >>=20 >> =A0=A0 if a response is received, the path is not removed. >>=20 >> =A0=A0 a subflow that is still functioning MUST be closed with a FIN exchang= e >>=20 >> =A0=A0=A0 -> Aren't these sentences inconsistent? >>=20 >> [Alan] Not at all. It says you can=B9t remove a functioning subflow with >> REMOVE_ADDR, you must use a FIN exchange. >>=20 >> Page 40: >>=20 >> =A0=A0 fallback to regular TCP can become necessary at any point during a >> connection if a non-MPTCP-aware middlebox changes the data stream. >> =A0 >> =A0=A0=A0 -> The paragraph below this suggest when multiple subflows are in us= e, >> the affected subflow must be terminated, but not suggesting fallback. >> =A0=A0=A0=A0=A0=A0=A0=A0 So, fallback seems not to be necessary? >>=20 >> =A0=A0 Therefore, it is not possible to recover the subflow, and the affecte= d >> subflow must be immediately closed with an RST. >>=20 >> =A0=A0=A0 -> MUST? >>=20 >> =A0=A0 Failed data will not be DATA_ACKed. >>=20 >> =A0=A0=A0 -> MUST NOT be DATA_ACKed? >>=20 >>=20 >> Page 47: >>=20 >> =A0=A0 If this is dropped, MPTCP SHOULD fall back to regular TCP. >>=20 >> =A0 =A0 -> may be MUST? since we cannot continue to use MPTCP . >>=20 >> [Alan] I don=B9t want to restrict what implementations do in this state =AD = we >> don=B9t care what happens if MPTCP isn=B9t going to be used. >>=20 >> =A0=A0 If packets with the MP_JOIN option are dropped, the paths will simply= not >> be used. >>=20 >> =A0=A0=A0 -> MUST NOT be used? >>=20 >> [Alan] It=B9s not a restriction, it=B9s a consequence of the MPTCP handshake= . If >> it=B9s dropped, it=B9s a fact it won=B9t be used since the receiver cannot kno= w the >> packet turning up has anything to do with an MPTCP connection. >>=20 >>=20 >> Page 51: >>=20 >> =A0=A0 Should use RFC6234 instead of RFC4634 >>=20 >> Page 52: >>=20 >> =A0=A0 Should use RFC5681 instead of RFC2581 >> =A0=A0 Should use draft-ietf-tcpm-secury-03 instead of -02 >> =A0=A0 Should use draft-ietf-mptcp-api-04 or 05? instead of -03 >>=20 >>=20 >> There are some typos in the doc. Please update them by some tools. >>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --B_3420789422_3109317 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Hi Yoshifumi,<BR> <BR> Thank you for your feedback. Anything I haven’t directly commented on= below was straightforwardly addressed in –08. If there is anything yo= u feel wasn’t sufficiently addressed, please shout.<BR> <BR> Regards,<BR> Alan<BR> <BR> On 18/04/2012 07:03, "Yoshifumi Nishida" <<a href=3D"nishida@sfc= .wide.ad.jp">nishida@sfc.wide.ad.jp</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Times Ne= w Roman">Hi authors,<BR> <BR> Sorry. I would like to add one more thing. <BR> <BR> This draft requires to create new registries for subtypes of mptcp option a= nd cryptographic algorithms handshake in MP_CAPABLE.=A0  <BR> For this, you will need to add the description of the policy used for manag= ing these registries in the IANA considerations section. Please check the se= ction 4 of RFC5226 to see the available choices (Section 4.1) and update the= texts based on the guideline (Section 4.2).<BR> <BR> Thanks,<BR> --<BR> Yoshifumi Nishida<BR> </FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR> <BR> <BR> <BR> On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida <<a href=3D"nishida@sf= c.wide.ad.jp">nishida@sfc.wide.ad.jp</a>> wrote:<BR> </FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Times Ne= w Roman">Hello,<BR> <BR> Sorry for the long delay.<BR> We believe it's good time to proceed to submit draft-ietf-mptcp-multiaddres= sed to IESG.<BR> <BR> Here's my comments on the draft to prepare a write-up for the draft.<BR> Please check and update if you agree with them.<BR> <BR> Thanks,<BR> --<BR> Yoshifumi<BR> <BR> <BR> Page 13:<BR>  =A0 3.1. Connection Initiation<BR> <BR>  =A0 =A0 -> =A0In my understanding, the key MUST be unique for each mptcp= connection. <BR>  =A0 =A0 =A0 =A0 =A0If so, I think we had better articulate it here.<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Unique per host, yes. I believe that is clear = already; certainly, I couldn’t find a way of making it any clearer.<BR= > </FONT><BR> Page 17:<BR>  =A0 =A0A host MUST store the Address IDs associated with all established = subflows.<BR> <BR>  =A0 =A0-> Does this mean both local Address IDs and remote Address IDs= advertized from the receiver?<BR>  =A0 =A0 =A0 =A0It might be better to clarify this.<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Yes it does, and I have clarified that.<BR> </FONT><BR> Page 18:<BR>  =A0 =A0therefore receipt of this packet MUST trigger an ACK in response<B= R> <BR>  =A0 =A0-> Since this is MUST, I think Figure 8 needs to include this A= CK in the sequence.<BR> <BR> <BR>  =A0 =A0the packet MUST be retransmitted if this ACK is not received.<BR> <BR>  =A0 =A0-> In case of MP_CAPABLE, the third packet is not retransmitted= .<BR>  =A0 =A0 =A0 =A0But, in case of MP_JOIN, it's retransmitted. Readers might wan= t to know the rationale about this.<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] It’s a completely different exchange, se= nding completely different information: it’s a crypto handshake not a = key exchange. I had hoped that would have been sufficiently clear, but IR= 17;ve added a few words anyway.<BR> </FONT> =A0 <BR> Page 27:<BR> <BR> =A0=A0 Essentially, a host MUST NOT FIN all functioning subflows unless it is s= afe to do so<BR> =A0=A0 <BR> =A0=A0=A0 -> MUST NOT close?<BR> <BR> Page 28:<BR> =A0<BR> =A0=A0 Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to clean= up state even if the subflow is failed.<BR> =A0=A0 -> I'm not very sure which situations can be addressed by this..<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Changed to “Both hosts SHOULD send FINs = on all subflows, as a courtesy to allow middleboxes to clean up state even i= f an individual subflow is no longer operational end-to-end.”. This is= in the case if a link has failed in the path somewhere, but one of the end = hosts is behind a middlebox. That host would never receive a FIN on the subf= low, and neither would the middlebox. But the end host knows the subflow sho= uld be closed, so by sending a FIN it aids in cleaning up. <BR> </FONT><BR> =A0=A0 ..<BR> =A0=A0 Note that a host may also send a FIN on an individual subflow to shut it= down, but this impact is limited to the subflow in question.<BR> <BR> =A0=A0 -> Sorry. I couldn't understand this sentences well..<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Changed to “As specified above, a standa= rd TCP FIN on an individual subflow only shuts down the subflow on which it = was sent.”<BR> </FONT><BR> Page 30:<BR> <BR> =A0=A0=A0 The sender also remembers the receive windows advertised by each subflo= w.<BR> =A0=A0 <BR> =A0=A0=A0 -> Don't we need to put SHOULD or MUST here?<BR> <BR> =A0=A0=A0 The send buffer must be, at the minimum, as big as the receive buffer<B= R> <BR> =A0=A0=A0 -> MUST?<BR> <BR> =A0=A0=A0 When doing this, a host must still retransmit the original data on the = original subflow,<BR> =A0<BR> =A0=A0=A0 -> MUST?<BR> <BR> Page 37:<BR> <BR> =A0=A0 if a response is received, the path is not removed.<BR> <BR> =A0=A0 a subflow that is still functioning MUST be closed with a FIN exchange<B= R> <BR> =A0=A0=A0 -> Aren't these sentences inconsistent?<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Not at all. It says you can’t remove a f= unctioning subflow with REMOVE_ADDR, you must use a FIN exchange.<BR> </FONT><BR> Page 40:<BR> <BR> =A0=A0 fallback to regular TCP can become necessary at any point during a conne= ction if a non-MPTCP-aware middlebox changes the data stream.<BR> =A0<BR> =A0=A0=A0 -> The paragraph below this suggest when multiple subflows are in us= e, the affected subflow must be terminated, but not suggesting fallback.<BR> =A0=A0=A0=A0=A0=A0=A0=A0 So, fallback seems not to be necessary?<BR> <BR> =A0=A0 Therefore, it is not possible to recover the subflow, and the affected s= ubflow must be immediately closed with an RST.<BR> <BR> =A0=A0=A0 -> MUST?<BR> <BR> =A0=A0 Failed data will not be DATA_ACKed.<BR> <BR> =A0=A0=A0 -> MUST NOT be DATA_ACKed?<BR> <BR> <BR> Page 47:<BR> <BR> =A0=A0 If this is dropped, MPTCP SHOULD fall back to regular TCP.<BR> <BR> =A0 =A0 -> may be MUST? since we cannot continue to use MPTCP . <BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] I don’t want to restrict what implementa= tions do in this state – we don’t care what happens if MPTCP isn= ’t going to be used.<BR> </FONT><BR> =A0=A0 If packets with the MP_JOIN option are dropped, the paths will simply no= t be used.<BR> <BR> =A0=A0=A0 -> MUST NOT be used? <BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] It’s not a restriction, it’s a con= sequence of the MPTCP handshake. If it’s dropped, it’s a fact it= won’t be used since the receiver cannot know the packet turning up ha= s anything to do with an MPTCP connection.<BR> </FONT><BR> <BR> Page 51:<BR> <BR> =A0=A0 Should use RFC6234 instead of RFC4634<BR> <BR> Page 52:<BR> <BR> =A0=A0 Should use RFC5681 instead of RFC2581<BR> =A0=A0 Should use draft-ietf-tcpm-secury-03 instead of -02<BR> =A0=A0 Should use draft-ietf-mptcp-api-04 or 05? instead of -03<BR> <BR> <BR> There are some typos in the doc. Please update them by some tools.<BR> <BR> <BR> </FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri= , Verdana, Helvetica, Arial"><BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></FONT></SPAN><FONT SIZE=3D"2"><FONT FA= CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________= ____________________________________<BR> multipathtcp mailing list<BR> <a href=3D"multipathtcp@ietf.org">multipathtcp@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/multipathtcp">https://www.ie= tf.org/mailman/listinfo/multipathtcp</a><BR> </SPAN></FONT></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3420789422_3109317-- From alanford@cisco.com Fri May 25 03:17:54 2012 Return-Path: <alanford@cisco.com> X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A8A21F85F9 for <multipathtcp@ietfa.amsl.com>; Fri, 25 May 2012 03:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlZFMf6hZ5Lv for <multipathtcp@ietfa.amsl.com>; Fri, 25 May 2012 03:17:42 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id C665821F8628 for <multipathtcp@ietf.org>; Fri, 25 May 2012 03:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=52961; q=dns/txt; s=iport; t=1337941060; x=1339150660; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=zP5bgF/p2iRg9i8l4+Uu53+h/XeQf28Wv1MkuYz8bbc=; b=Aj7BUTjSV509t+5dW3QvGfQWyQUEUW+l0/UcegSxg4Go5hAZxTWbnQRc QG86QXeHZESIPT+CJ8+DdT1BPHVOT67eTV5X/6fqvL+1XHbDQ8D+GF1jr gNA/gJ1FieEB5zA0/BZy06wEB4/hg2lMEpHyX2TcU9J5Gn/Rz+H2qdL7j I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoGANFbv0+Q/khL/2dsb2JhbABEgkWHK6oqgQcCgQeCFQEBAQMBEgEHAQwWKg0FBQ0BCBEEAQEBIAEGTQkIAQEEAQ0FIodmBZtWn3WLARQBhTEDiAyNDI4MJ4E9gmGBVQEEAg X-IronPort-AV: E=Sophos;i="4.75,655,1330905600"; d="scan'208,217";a="4971001" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 25 May 2012 10:17:38 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4PAHc2J002577; Fri, 25 May 2012 10:17:38 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 12:17:38 +0200 Received: from 144.254.90.168 ([144.254.90.168]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 May 2012 10:17:37 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Fri, 25 May 2012 11:17:36 +0100 From: Alan Ford <alanford@cisco.com> To: <philip.eardley@bt.com>, <nishida@sfc.wide.ad.jp> Message-ID: <CBE51AD0.9DEB%alanford@cisco.com> Thread-Topic: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 Thread-Index: Ac0jzbqibAFIshA0T/uPM83vXnJ6ygWkeBYa In-Reply-To: <9510D26531EF184D9017DF24659BB87F33520217BD@EMV65-UKRD.domain1.systemhost.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3420789456_3100212" X-OriginalArrivalTime: 25 May 2012 10:17:38.0286 (UTC) FILETIME=[9C56F0E0:01CD3A5F] Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp> List-Post: <mailto:multipathtcp@ietf.org> List-Help: <mailto:multipathtcp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 May 2012 10:17:54 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3420789456_3100212 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Phil, Many thanks for you comments. Anything I have not directly commented on below was straightforwardly addressed in =AD08. If there is anything you feel wasn=B9t sufficiently addressed, please shout. Regards, Alan On 26/04/2012 17:57, "philip.eardley@bt.com" <philip.eardley@bt.com> wrote: > Hi Alan, Costin, Mark, Olivier, > =20 > Here are some comments. Sorry I finally got through it. > The first lot are either significant or something worth thinking about. T= he > second lot are just typos & re-phrasings =AD feel free to ignore if you don= =B9t > like the suggestion > =20 > Thanks! > phil > =20 > -- > =20 > Think it would be good to have a sub-section in S2 on Fast Close > =20 > Also might be worth adding one on MP_FAIL ? >=20 > [Alan] I decided against doing this. S2 is meant to be a light overview o= f the > protocol; it seems unnecessary and potentially confusing to burden reader= s > with these little-used features at this stage. > =20 > S3.1 penultimate para, << If this > option is not present, the connection should fall back to regular > TCP , as documented in Section 3.6.>> > SHOULD? > also S3.6 para 1 is about this =AD but it doesn=B9t have any capitalisation, = which > presumably it should > =20 > I thought that S3.2 could be clearer. Basically there are a lot of minor > things (see below) that add up to making it quite hard work. > =20 > Fig 8 =AD I think the first msg (SYN + MP_CAPABLE) should have (Key-A) > =20 > S3.3.0 =AD do you say somewhere what to do if the checksum is present but i= t > wasn=B9t negotiated in MP-CAPABLE, or it isnt present but wasn=B9t negotiated= ? > =20 > [Alan] We do now: =B3If a checksum is present, but its use had not been > negotiated in the MP_CAPABLE handshake, it SHOULD be ignored. If a checks= um is > not present when its use has been negotiated, the receiver SHOULD close t= he > subflow with a RST as it is considered broken.=B2 >=20 > P36 para 4 < If the Address ID is not in use on a > live subflow, but is stored by the receiver, a new ADD_ADDR SHOULD > take precedence and replace the stored address.> > I found this sentence quite hard to parse. If I understand it right, this= is > advertising a new address by over-writing an old address - using the same > Address ID. Rather than removing the old address and adding a new one wit= h a > different Address ID. Sounds dodgy? why doing this? >=20 > [Alan] You understood it right, however you=B9re right is has a whiff of > dodgyness to it. So I=B9ve removed it =AD now a host that wants to replace an > Address ID MUST remove it first. > =20 > 3.5 =AD Fast Close sends the Receiver=B9s Key in the clear. Does this open an > attack? =20 >=20 > [Alan] Not any new risks. Once it=B9s sent on Fast Close, the connection is > dead, so no further signalling with that key would have any effect. And y= es, > anyone who had seen the key on the initial handshake could Fast Close the > connection. But they can do anything anyway if they=B9ve seen the key on th= e > initial handshake. In Fast Close, usual TCP sequence number verification = is > required to ensure the signal is in-window (so an attacker would need to = know > both the key of the receiver and the sequence space of the sender). >=20 > There might be value in e.g. hashing the key with the sender=B9s DSN for > slightly more protection; I=B9m not sure if that adds anything. In fact, it > probably goes against the point of Fast Close that the sender actively DO= ES > NOT CARE whether its last packets actually get to the end host. >=20 > anyway, it contradicts S3.1 & S5 which say it=B9s only sent in the clear on= ce, > ie on MP-CAPABLE >=20 > [Alan] Fixed this. > =20 > 3.6 =AD I had it in my brain that fallback meant =8Cfallback from mptcp to tc= p=B9. > Here it means =8C.. or close a problematic subflow=B9. I=B9m not absolutely sur= e > it=B9s used consistently throughout the doc, but it=B9s probably worth adding= an > intro para to 3.6 that says there are n ways of coping with some problem, > close the subflow, close the connection (?), shift to tcp >=20 > [Alan] You=B9re right, it has evolved from its original meaning. Now re-wor= ded: > =B3Sometimes, middleboxes will exist on a path that could prevent the opera= tion > of MPTCP. MPTCP has been designed in order to cope with many middlebox > modifications (see Section 6), but there are still some cases where a sub= flow > could fail to operate within the MPTCP requirements. These cases are not= ably: > the loss of TCP options on a path; and the modification of payload data. = If > such an event occurs, it is necessary to "fall back" to the previous, saf= e > operation. This may either be falling back to regular TCP, or removing a > problematic subflow.=B2 > =20 > 3.6 para 1 =AD needs to be a SHOULD somewhere in here > =20 > 3.6 para 1 COMPARE 3.8.3 para 2 =AD 3.6 suggests give up on mptcp after one > MP_CAPABLE fails (& also 6 & 3.1); 3.8 suggests after several. Which is r= ight? >=20 > [Alan] It=B9s up to the implementation. The heuristics are our initial thou= ghts > on this; implementations optimise this. The heuristics now say =B3one or mo= re=B2 > rather than =B3several=B2. >=20 > S4 Receive window last sentence, =B3so a host must=B2 =AD SHOULD? Or maybe =8Cnee= ds > to=B9? Also, this point doesn=B9t appear in S3.3.4 >=20 > [Alan] =B3needs to=B2. Re S3.3.4, I think it is implied =AD there is talk there > about normal subflow processing. > =20 > P48 penul para < If some subflow-level space is left unmapped, > however, the subflow is treated as broken and is closed, as discussed > in Section 3.3. > > do you mean S3.6? I couldn=B9t see anything in s3.3 > =20 > [but it=B9s a big section, so a more accurate ref would be useful =AD same co= mment > on p10 just above the SS pic & p40 para 3] >=20 > [Alan] The reference to S3.6 there are more a general pointer to procedur= e > than a specific instruction =AD I=B9ve clarified this. > =20 > P49 PEPs < MPTCP will > therefore fall back to single-path TCP (see Section 3.6).> > I read S3.6 to say that you close the subflow (rather than fall back to t= cp) >=20 > [Alan] S3.6 is intended to cover both, and hopefully this new intro shoul= d > make this clearer. > =20 > S8 =AD can be updated with Option kind number 30 ! also Wes=B9s comment about= the > subtypes [ie invent a policy for managing them] >=20 > [Alan] It=B9s now been rewritten in RFC5226 style. > =20 > Appendix C =AD should the =8Csnd DATA_ACK=B9 arrows from M_ESTAB & from M_FIN W= AIT-1 > be snd DATA_ACK[DFIN] ? > =20 > -- > =20 > Minor suggestions etc =AD no need to ack these individually [but shout if I > reveal some misunderstanding!] > =20 > Throughout doc:=20 > =20 > Be consistent on =8CDATA_ACK=B9 & =8CDATA_FIN=B9 =AD many times appear without =8C_=B9 = [I > guess I prefer MP_DATA_ACK but that may be too much for your taste!] >=20 > [Alan] Remember those two are flags and not specific options, so it=B9s > definitely inappropriate to call them MP_... But they=B9ve all grown an > underscore for consistency. > =20 > I think it would be more logical if all the subtype names started MP_ [ie= also > DSS, ADD_ADDR, REMOVE_ADDR] [again, maybe too much for your taste] >=20 > [Alan] Given that these are symbols within a MPTCP-specific registry, I o= nly > see MP_ as taking up unnecessary space. Sorry ;) >=20 > The bare =8CID=B9 appears quite often- think you should use =8CAddress ID=B9 > throughout >=20 > [Alan] I found three instances, let me know if I=B9ve missed any. > =20 > -- > =20 > S1.1 <<The > congestion control algorithms as discussed in [5] ensure this does > not act detrimentally.>> > The congestion control algorithm defined in [5] achieves this. > =20 > S1.3 a reference to S4 might be nice > =20 > S1.4 bullet 2, =B3where a TCP connection is established=B2 =AD should be MPTCP > connection > =20 > 2.1 & 2.2 =AD would it be more logical if =8CACK MP_CAPABLE=B9 & =8CACK MP_JOIN=B9 > didn=B9t have =8CACK=B9 since there=B9s no special ACK subtype? But maybe this ma= kes > it harder to understand what=B9s happening? > =20 > 2.4 para 2 << The "Data Sequence Signal" option which carries this "Dat= a > Sequence > Mapping", which consists of the subflow sequence number, data>> > The "Data Sequence Signal" option carries the "Data Sequence > Mapping". The Data Sequence Mapping consists of the subflow sequence > number, data > =20 > 2.7 bullet 1 =B3MP-ADD-ADDR=B2 should be ADD_ADDR (unless you change subtype = names > to all start MP_ !) > =20 > 3.1 para 4, last sentence (The subflow handshake mechanism=8A) is quite har= d to > parse > =20 > 3.1, last para p14 << The leftmost bit - labeled C > - indicates "Checksum required", and SHOULD be set to 1 unless > specifically overridden (for example, if the system administrator has > decided that checksums are not required - see Section 3.3 for more > discussion)>> > The leftmost bit - labelled C - SHOULD be set to 1 to indicate "Checksum > required", unless the system administrator has > decided that checksums are not required - see Section 3.3 for more > discussion) > =20 > also, S3.3 doesn=B9t discuss why someone might decide to use checksums, or > decide not to. Might be nice to add a hint about this somewhere > =20 > also, when there are multiple crypo algos, do we want to point out that t= he > same one MUST be used for everything (generating token, isdn etc)? maybe = this > is obvious and anyway would be better in any subsequent doc about alterna= tive > crypto > =20 > [Alan] That=B9s a good point, however I think it is best to leave it to any= new > documents to decide whether they also want to tie a new crypto algorithm = with > tokens/IDSN generation. >=20 > p15 =AD I thought the first sentence [=B3These bits..=B2 was redundant > =20 > p15 para 2 << The initiator > creates a proposal setting a bit for each algorithm >> > The initiator sets a bit for each algorithm > =20 > P16, last para of 3.1 << The initial Data Sequence Number (IDSN) is gener= ated > as a hash from > the Key, in the same way as the token, i.e. IDSN-A =3D Hash(Key-A) and > IDSN-B =3D Hash(Key-B).>> > The Initial Data Sequence Number (IDSN) is generated as a hash from > the Key, i.e. IDSN-A =3D Hash(Key-A) and > IDSN-B =3D Hash(Key-B). > =20 > Middle p17 =AD the =8Cthis=B9 bonanza made it hard to understand. How about > (includes a couple of other changes):- > The MP_JOIN option includes an "Address ID". This is an identifier > that only has significance within a single connection, where it > identifies the original source address of the packet, even if the IP h= eader > has been changed in transit by a middlebox. This allows > address removal (Section 3.4.2) without needing to know what the sourc= e > address at > the receiver is, and thus allows address removal through NATs. It also > allows correlation between new subflow > setup attempts and address signaling (Section 3.4.1), to prevent > setting up duplicate subflows on the same path. > =20 > P17 last para<< The MP_JOIN option on SYNs >> add =8Cand SYN_ACKs=B9 >=20 > [Alan] =B3Packets with the SYN flag set=B2 > =20 > P18 first para under Fig 5 << Although cryptographic calculations are req= uired > in the > SYN/ACK, it is felt that the 32 bit token gives >> > Although calculating a MAC requires cryptographic operations, it is belie= ved > that the 32 bit token in the MP_JOIN SYN gives > =20 > P18 2nd para, sentence 2 =B3This is to allow..=B2 takes some working out. May= be: > =B3This allow Host B to use random data sent by Host A in the SYN, as part = of > the MAC algorithm; and similarly Host A to use random data sent by Host B= in > the SYN/ACK. > =20 > Last sentence of this para can be shortened: > Due > to option space limitations, the MAC included in the SYN/ACK is > truncated to the leftmost 64 bits, but this is acceptable since > an attacker has only one chance to guess the MAC correctly. > =20 > Next para =AD =B3and this is=B2 -> =B3as=B2 > =20 > Same para =B3MUST trigger an ACK in response=B2 =AD maybe you could stress that= this > is an ordinary data ACK > =20 > P19 =B3The message in each case =B3 -> The message for the MAC algorithm in e= ach > case=20 > =20 > S3.2, the Random Number =3D=3D Nonce in S2. Point out, or change one of them. > =20 > S3.3 para 2 & 3 could be re-phrased slightly:- > During normal MPTCP operation, the Data Sequence Mapping defines how t= he > sequence space on the subflow maps to > the connection level; and the Data ACK acknowledges receipt of > data at the connection level. These functions are described in more > detail in the following two subsections. > The Data Sequence Mapping and the Data ACK are signalled in the Data Sequ= ence > Signal (DSS). Either or both can be signalled in one DSS, dependent on th= e > flags set. > =20 > P23 << The data sequence mapping also contains a checksum of the data tha= t > this mapping covers. >> - to check I understand, this means you need = all > the data before you start to transmit it, so you can calculate the checks= um? > =20 > P24 first para under fig 10, you could delete =B3. Furthermore,=B2 and put th= e > rest of the sentence in (..) > =20 > Last para 3.3.1 =B3data-level length field to =B3 > Data-level Length field of the DSS option to > =20 > P26 para 3, =B3that it is used=B2 can be deleted > =20 > P26 para 4 << An MPTCP sender MUST only free data from the send buffer wh= en it > has > been acknowledged by both a Data ACK received on any subflow and at > the subflow level by any subflows the data was sent on. >> > could be clearer > An MPTCP sender MUST NOT free data from the send buffer until it has > been acknowledged by both a Data ACK received on any subflow and at > the subflow level by all subflows the data was sent on. > [note, 2nd =8Cany=B9 -> =8Call=B9] > =20 > Same para restransmited / re-transmitted > =20 > P27 para 4 < and length 11> and Data-level Length of 11 > =20 > Same thing in next para > =20 > P27 penult para =AD I think =8CData Sequence Signal=B9 would be more accurate h= ere > than =8CMapping=B9. Also Length -> Data-level Length > =20 > P27 last line, think you mean =8CDATA_FIN=B9 and not FIN > =20 > 3.3.4 para 4 << When deciding to accept packets at subflow level, normal = TCP > uses the > sequence number in the packet and checks it against the allowed > receive window. >> > When deciding to accept packets at the subflow level, normal TCP checks t= he > sequence number in the packet against the allowed > receive window. > =20 > P28 last line > Could you spell out what rcv_next is [or at least reference B2.2.2, where= it=B9s > called RCV.NXT] > =20 > 3.3.4 last para =8Cmaximum bandwidth-delay product of any of the paths=B9 won= der > if =8Cany one of the=B9 would be clearer? > =20 > 3.3.6 para 1 =8Cthe best behaviour=B9 -> =8Csensible behaviour=B9 > =20 > P30 last line active ACK -> actively ACK > =20 > 3.3.6 last line - < For example, subflows that perform highly asymmetrica= lly > may be mis- > diagnosed as underperforming.> > For example, a highly asymmetrically path may be mis- > diagnosed as underperforming. > =20 > P33 para 1 =8CThe signal applies to a single direction: > the sender of this option, however, may >> > The signal applies to a single direction =AD and so the sender of this opti= on > may=20 > =20 > Next para < This > applies the given setting of B to all subflows that use the address > identified by the given Address ID. > > do you think it=B9s worth saying that this means all subflows in this > connection? > =20 > S3.4 para 2 < This design makes use of two methods of sharing such > information, > used simultaneously. > > This design makes use of two methods of sharing such information; both ca= n be > used on a connection. > =20 > 3.4.1 understake -> undertake > =20 > P35 para above Fig 12 as does the ephemeral port at the client =AD explain. > =20 > Same para, =B3signalling subflow=B9 =AD should this be =8Cinitial subflow=B9? > =20 > Fig 12 caption =AD can delete =8C(shown for IPv4)=B9 =AD as pic includes v6 > =20 > P36 para 2 < This would be to ensure that this> This would ensure that > =20 > 3.4.1 last para < an MPTCP > implementation MUST NOT treat duplicate ACKs with any MPTCP option > apart from DSS as indications of congestion >> > =B3NOT =8A any .. apart from=B2 is ambiguous. > =20 > P38 last bullet < The number of > retransmissions should be limited > > SHOULD? > =20 > S3.6 =AD end of sentence 1 =AD add =8Cfor instance they aren=B9t blocked or mangl= ed by > a middlebox=20 > =20 > 3.6 para 4 < with the length value of 0 > with the Data-level Length set = to 0 > =20 > P40 para 1 I couldn=B9t parse this:- > (Note that these rules do not apply if an > infinite mapping is included from the start - in which case, each end > will send DSS options declaring the infinite mapping.) > =20 > Fig 15 Length may be 8 & DSN may be 4 octets > =20 > 3.6 penult para =B3fallback mode=B2 =AD what is this? > =20 > 3.8.3 para 2 < a host should fall back> SHOULD > =20 > S4, Duplicate ack. =B3To avoid any=B2 -> To limit > =20 > S4, Receive window penult line <also need to> also needs to > =20 > S5, big para on p46 < used on subflow setup that verify that > used on su= bflow > setup, in order to verify that > =20 > P47 line 1, =B3will allow=B2 -> allows > =20 > S6 para 1 & P54 para 2 > accomodate -> accommodate > =20 > S6 para 2 < Most middleboxes > should just forward packets with new options unchanged> > Middleboxes should just forward packets with new options unchanged > [I think =AD (all) middleboxes aren=B9t supposed to change options; most don=B9= t] > =20 > P49 Traffic normalisers =AD should you also mention about re-transmitting o= n the > same subflow? > =20 > 9.2 =AD maybe worth adding rfc editor note that hoping this will become rfc= at > the same time > =20 > P54 para 2 <(10B)> 10 bytes > =20 > Appendix C =AD point out that [DFIN] is shorthand for [DATA_FIN] =AD (I think= !) > =20 > That=B9s it, phew. >=20 > =20 > =20 > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org= ] On > Behalf Of Yoshifumi Nishida > Sent: 18 April 2012 07:04 > To: draft-ietf-mptcp-multiaddressed@tools.ietf.org; multipathtcp > Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-0= 7 > =20 > Hi authors, > =20 > Sorry. I would like to add one more thing. > =20 > This draft requires to create new registries for subtypes of mptcp option= and > cryptographic algorithms handshake in MP_CAPABLE. > For this, you will need to add the description of the policy used for man= aging > these registries in the IANA considerations section. Please check the sec= tion > 4 of RFC5226 to see the available choices (Section 4.1) and update the te= xts > based on the guideline (Section 4.2). > =20 > Thanks, > -- > Yoshifumi Nishida > =20 > =20 > =20 > On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.= jp> > wrote: > Hello, > =20 > Sorry for the long delay. > We believe it's good time to proceed to submit draft-ietf-mptcp-multiaddr= essed > to IESG. > =20 > Here's my comments on the draft to prepare a write-up for the draft. > Please check and update if you agree with them. > =20 > Thanks, > -- > Yoshifumi > =20 > =20 > Page 13: > 3.1. Connection Initiation > =20 > -> In my understanding, the key MUST be unique for each mptcp connec= tion. > If so, I think we had better articulate it here. > =20 > Page 17: > A host MUST store the Address IDs associated with all established subf= lows. > =20 > -> Does this mean both local Address IDs and remote Address IDs advert= ized > from the receiver? > It might be better to clarify this. > =20 > Page 18: > therefore receipt of this packet MUST trigger an ACK in response > =20 > -> Since this is MUST, I think Figure 8 needs to include this ACK in t= he > sequence. > =20 > =20 > the packet MUST be retransmitted if this ACK is not received. > =20 > -> In case of MP_CAPABLE, the third packet is not retransmitted. > But, in case of MP_JOIN, it's retransmitted. Readers might want to= know > the rationale about this. > =20 > Page 27: > =20 > Essentially, a host MUST NOT FIN all functioning subflows unless it is= safe > to do so > =20 > -> MUST NOT close? > =20 > Page 28: > =20 > Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to cle= an up > state even if the subflow is failed. > -> I'm not very sure which situations can be addressed by this.. > .. > Note that a host may also send a FIN on an individual subflow to shut = it > down, but this impact is limited to the subflow in question. > =20 > -> Sorry. I couldn't understand this sentences well.. > =20 > Page 30: > =20 > The sender also remembers the receive windows advertised by each subf= low. > =20 > -> Don't we need to put SHOULD or MUST here? > =20 > The send buffer must be, at the minimum, as big as the receive buffer > =20 > -> MUST? > =20 > When doing this, a host must still retransmit the original data on th= e > original subflow, > =20 > -> MUST? > =20 > Page 37: > =20 > if a response is received, the path is not removed. > =20 > a subflow that is still functioning MUST be closed with a FIN exchange > =20 > -> Aren't these sentences inconsistent? > =20 > Page 40: > =20 > fallback to regular TCP can become necessary at any point during a > connection if a non-MPTCP-aware middlebox changes the data stream. > =20 > -> The paragraph below this suggest when multiple subflows are in use= , the > affected subflow must be terminated, but not suggesting fallback. > So, fallback seems not to be necessary? > =20 > Therefore, it is not possible to recover the subflow, and the affected > subflow must be immediately closed with an RST. > =20 > -> MUST? > =20 > Failed data will not be DATA_ACKed. > =20 > -> MUST NOT be DATA_ACKed? > =20 > =20 > Page 47: > =20 > If this is dropped, MPTCP SHOULD fall back to regular TCP. > =20 > -> may be MUST? since we cannot continue to use MPTCP . > =20 > If packets with the MP_JOIN option are dropped, the paths will simply = not > be used. > =20 > -> MUST NOT be used? > =20 > =20 > Page 51: > =20 > Should use RFC6234 instead of RFC4634 > =20 > Page 52: > =20 > Should use RFC5681 instead of RFC2581 > Should use draft-ietf-tcpm-secury-03 instead of -02 > Should use draft-ietf-mptcp-api-04 or 05? instead of -03 > =20 > =20 > There are some typos in the doc. Please update them by some tools. > =20 > =20 --B_3420789456_3100212 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Hi Phil,<BR> <BR> Many thanks for you comments. Anything I have not directly commented on bel= ow was straightforwardly addressed in –08. If there is anything you fe= el wasn’t sufficiently addressed, please shout.<BR> <BR> Regards,<BR> Alan<BR> <BR> On 26/04/2012 17:57, "<a href=3D"philip.eardley@bt.com">philip.eardley@b= t.com</a>" <<a href=3D"philip.eardley@bt.com">philip.eardley@bt.com</a= >> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>Hi Alan, Costin, Mark, Olivier,<BR>  <BR> Here are some comments. Sorry I finally got through it.<BR> The first lot are either significant or something worth thinking about. The=  second lot are just typos & re-phrasings – feel free to ign= ore if you don’t like the suggestion<BR>  <BR> Thanks!<BR> phil<BR>  <BR> --<BR>  <BR> Think it would be good to have a sub-section in S2 on Fast Close<BR>  <BR> Also might be worth adding one on MP_FAIL ?<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] I decided against doing this. S2 is meant to b= e a light overview of the protocol; it seems unnecessary and potentially con= fusing to burden readers with these little-used features at this stage.<BR> </FONT> <BR> S3.1 penultimate para, << If this<BR>    option is not present, the connection should fall back to= regular<BR>    TCP , as documented in Section 3.6.>><BR> SHOULD?<BR> also S3.6 para 1 is about this – but it doesn’t have any capita= lisation, which presumably it should<BR>  <BR> I thought that S3.2 could be clearer. Basically there are a lot of minor th= ings (see below) that add up to making it quite hard work.<BR>  <BR> Fig 8 – I think the first msg (SYN + MP_CAPABLE) should have (Key-A)<= BR>  <BR> S3.3.0 – do you say somewhere what to do if the checksum is present b= ut it wasn’t negotiated in MP-CAPABLE, or it isnt present but wasnR= 17;t negotiated?<BR>  <BR> <FONT COLOR=3D"#0000FF">[Alan] We do now: “If a checksum is present, bu= t its use had not been negotiated in the MP_CAPABLE handshake, it SHOULD be = ignored. If a checksum is not present when its use has been negotiated, the = receiver SHOULD close the subflow with a RST as it is considered broken.R= 21;<BR> </FONT><BR> P36 para 4 < If the Address ID is not in use on a<BR>    live subflow, but is stored by the receiver, a new ADD_AD= DR SHOULD<BR>    take precedence and replace the stored address.><BR> I found this sentence quite hard to parse. If I understand it right, this i= s advertising a new address by over-writing an old address - using the same = Address ID. Rather than removing the old address and adding a new one with a= different Address ID. Sounds dodgy? why doing this?<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] You understood it right, however you’re = right is has a whiff of dodgyness to it. So I’ve removed it – no= w a host that wants to replace an Address ID MUST remove it first.<BR> </FONT> <BR> 3.5 – Fast Close sends the Receiver’s Key in the clear. Does th= is open an attack?  <BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Not any new risks. Once it’s sent on Fas= t Close, the connection is dead, so no further signalling with that key woul= d have any effect. And yes, anyone who had seen the key on the initial hands= hake could Fast Close the connection. But they can do anything anyway if the= y’ve seen the key on the initial handshake. In Fast Close, usual TCP s= equence number verification is required to ensure the signal is in-window (s= o an attacker would need to know both the key of the receiver and the sequen= ce space of the sender).<BR> <BR> There might be value in e.g. hashing the key with the sender’s DSN fo= r slightly more protection; I’m not sure if that adds anything. In fac= t, it probably goes against the point of Fast Close that the sender actively= DOES NOT CARE whether its last packets actually get to the end host.<BR> </FONT><BR> anyway, it contradicts S3.1 & S5 which say it’s only sent in the = clear once, ie on MP-CAPABLE<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Fixed this.<BR> </FONT> <BR> 3.6 – I had it in my brain that fallback meant ‘fallback from m= ptcp to tcp’. Here it means ‘.. or close a problematic subflow&#= 8217;. I’m not absolutely sure it’s used consistently throughout= the doc, but it’s probably worth adding an intro para to 3.6 that say= s there are n ways of coping with some problem, close the subflow, close the= connection (?), shift to tcp<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] You’re right, it has evolved from its or= iginal meaning. Now re-worded: “Sometimes, middleboxes will exist on a= path that could prevent the operation of MPTCP.  MPTCP has been design= ed in order to cope with many middlebox modifications (see Section 6), but t= here are still some cases where a subflow could fail to operate within the M= PTCP requirements.  These cases are notably: the loss of TCP options on= a path; and the modification of payload data.  If such an event occurs= , it is necessary to "fall back" to the previous, safe operation. =  This may either be falling back to regular TCP, or removing a problema= tic subflow.”<BR> </FONT> <BR> 3.6 para 1 – needs to be a SHOULD somewhere in here<BR>  <BR> 3.6 para 1 COMPARE 3.8.3 para 2 – 3.6 suggests give up on mptcp after= one MP_CAPABLE fails (& also 6 & 3.1); 3.8 suggests after several. = Which is right? <BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] It’s up to the implementation. The heuri= stics are our initial thoughts on this; implementations optimise this</FONT>= .<FONT COLOR=3D"#0000FF"> The heuristics now say “one or more” rat= her than “several”.</FONT> <BR> <BR> S4 Receive window last sentence, “so a host must” – SHOUL= D? Or maybe ‘needs to’?  Also, this point doesn’t app= ear in S3.3.4<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] “needs to”. Re S3.3.4, I think it = is implied – there is talk there about normal subflow processing.<BR> </FONT> <BR> P48 penul para < If some subflow-level space is left unmapped,<BR>    however, the subflow is treated as broken and is closed, = as discussed<BR>    in Section 3.3.  ><BR> do you mean S3.6? I couldn’t see anything in s3.3 <BR>  <BR> [but it’s a big section, so a more accurate ref would be useful ̵= 1; same comment on p10 just above the SS pic & p40 para 3]<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] The reference to S3.6 there are more a general= pointer to procedure than a specific instruction – I’ve clarifi= ed this.<BR> </FONT> <BR> P49 PEPs < MPTCP will<BR>       therefore fall back to single-path TCP = (see Section 3.6).><BR> I read S3.6 to say that you close the subflow (rather than fall back to tcp= )<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] S3.6 is intended to cover both, and hopefully = this new intro should make this clearer.<BR> </FONT> <BR> S8 – can be updated with Option kind number 30 ! also Wes’s com= ment about the subtypes [ie invent a policy for managing them] <BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] It’s now been rewritten in RFC5226 style= .<BR> </FONT> <BR> Appendix C – should the ‘snd DATA_ACK’ arrows from M_ESTA= B & from M_FIN WAIT-1  be snd DATA_ACK[DFIN] ?  <BR>  <BR> --<BR>  <BR> Minor suggestions etc – no need to ack these individually [but shout = if I reveal some misunderstanding!]<BR>  <BR> Throughout doc: <BR>  <BR> Be consistent on ‘DATA_ACK’ & ‘DATA_FIN’ –= ; many times appear without ‘_’ [I guess I prefer MP_DATA_ACK bu= t that may be too much for your taste!]<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Remember those two are flags and not specific = options, so it’s definitely inappropriate to call them MP_... But they= ’ve all grown an underscore for consistency.<BR> </FONT> <BR> I think it would be more logical if all the subtype names started MP_ [ie a= lso DSS, ADD_ADDR, REMOVE_ADDR] [again, maybe too much for your taste]<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Given that these are symbols within a MPTCP-sp= ecific registry, I only see MP_ as taking up unnecessary space. Sorry ;)</FO= NT> <BR> <BR> The bare ‘ID’ appears quite often- think you should use ‘= Address ID’ throughout<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] I found three instances, let me know if I̵= 7;ve missed any.<BR> </FONT> <BR> --<BR>  <BR> S1.1 <<The<BR>    congestion control algorithms as discussed in [5] ensure = this does<BR>    not act detrimentally.>><BR> The congestion control algorithm defined in [5] achieves this.<BR>  <BR> S1.3 a reference to S4 might be nice <BR>  <BR> S1.4 bullet 2, “where a TCP connection is established” – = should be MPTCP connection<BR>  <BR> 2.1 & 2.2 – would it be more logical if ‘ACK MP_CAPABLER= 17; & ‘ACK MP_JOIN’ didn’t have ‘ACK’ sinc= e there’s no special ACK subtype? But maybe this makes it harder to un= derstand what’s happening?<BR>  <BR> 2.4 para 2 <<   The "Data Sequence Signal" option= which carries this "Data Sequence<BR>    Mapping", which consists of the subflow sequence num= ber, data>><BR>    The "Data Sequence Signal" option carries the &= quot;Data Sequence<BR>    Mapping". The Data Sequence Mapping consists of the = subflow sequence number, data<BR>  <BR> 2.7 bullet 1 “MP-ADD-ADDR” should be ADD_ADDR (unless you chang= e subtype names to all start MP_ !)<BR>  <BR> 3.1 para 4, last sentence (The subflow handshake mechanism…) is quite= hard to parse<BR>  <BR> 3.1, last para p14 << The leftmost bit - labeled C<BR>    - indicates "Checksum required", and SHOULD be = set to 1 unless<BR>    specifically overridden (for example, if the system admin= istrator has<BR>    decided that checksums are not required - see Section 3.3= for more<BR>    discussion)>><BR> The leftmost bit - labelled C - SHOULD be set to 1 to indicate "Checks= um required", unless the system administrator has<BR>    decided that checksums are not required - see Section 3.3= for more<BR>    discussion)<BR>  <BR> also, S3.3 doesn’t discuss why someone might decide to use checksums,= or decide not to. Might be nice to add a hint about this somewhere<BR>  <BR> also, when there are multiple crypo algos, do we want to point out that the= same one MUST be used for everything (generating token, isdn etc)? maybe th= is is obvious and anyway would be better in any subsequent doc about alterna= tive crypto<BR>  <BR> <FONT COLOR=3D"#0000FF">[Alan] That’s a good point, however I think it = is best to leave it to any new documents to decide whether they also want to= tie a new crypto algorithm with tokens/IDSN generation.<BR> </FONT><BR> p15 – I thought the first sentence [“These bits..” was re= dundant<BR>  <BR> p15 para 2 << The initiator<BR>    creates a proposal setting a bit for each algorithm >&= gt;<BR> The initiator sets a bit for each algorithm <BR>  <BR> P16, last para of 3.1 << The initial Data Sequence Number (IDSN) is g= enerated as a hash from<BR>    the Key, in the same way as the token, i.e.  IDSN-A = =3D Hash(Key-A) and<BR>    IDSN-B =3D Hash(Key-B).>><BR> The Initial Data Sequence Number (IDSN) is generated as a hash from<BR>    the Key, i.e.  IDSN-A =3D Hash(Key-A) and<BR>    IDSN-B =3D Hash(Key-B).       = ;        <BR>  <BR> Middle p17 – the ‘this’ bonanza made it hard to understan= d. How about (includes a couple of other changes):-<BR> The MP_JOIN option includes an "Address ID".  This is an ide= ntifier<BR>    that only has significance within a single connection, wh= ere it<BR>    identifies the original source address of the packet, eve= n if the IP header has been changed in transit by a middlebox.  This al= lows<BR>    address removal (Section 3.4.2) without needing to know w= hat the source address at<BR>    the receiver is, and thus allows address removal through = NATs. It also allows correlation between new subflow<BR>    setup attempts and address signaling (Section 3.4.1), to = prevent<BR>    setting up duplicate subflows on the same path.<BR>  <BR> P17 last para<< The MP_JOIN option on SYNs >> add ‘and SY= N_ACKs’<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] “Packets with the SYN flag set”<BR= > </FONT> <BR> P18 first para under Fig 5 << Although cryptographic calculations are= required in the<BR>    SYN/ACK, it is felt that the 32 bit token gives >><= BR> Although calculating a MAC requires cryptographic operations, it is believe= d that the 32 bit token in the MP_JOIN SYN gives <BR>  <BR> P18 2nd para, sentence 2 “This is to allow..” takes some workin= g out. Maybe: “This allow Host B to use random data sent by Host A in = the SYN, as part of the MAC algorithm; and similarly Host A to use random da= ta sent by Host B in the SYN/ACK.<BR>  <BR> Last sentence of this para can be shortened: <BR> Due<BR>    to option space limitations, the MAC included in the SYN/= ACK is<BR>    truncated to the leftmost 64 bits, but this is acceptable= since <BR> an attacker has only one chance to guess the MAC correctly.<BR>  <BR> Next para – “and this is” -> “as”<BR>  <BR> Same para “MUST trigger an ACK in response” – maybe you c= ould stress that this is an ordinary data ACK<BR>  <BR> P19 “The message in each case “ -> The message for the MAC a= lgorithm in each case <BR>  <BR> S3.2, the Random Number =3D=3D Nonce in S2. Point out, or change one of them.<B= R>  <BR> S3.3 para 2 & 3 could be re-phrased slightly:-<BR>    During normal MPTCP operation, the Data Sequence Mapping = defines how the sequence space on the subflow maps to<BR>    the connection level; and the Data ACK acknowledges recei= pt of<BR>    data at the connection level.  These functions are d= escribed in more<BR>    detail in the following two subsections.<BR> The Data Sequence Mapping and the Data ACK are signalled in the Data Sequen= ce Signal (DSS). Either or both can be signalled in one DSS, dependent on th= e flags set.<BR>  <BR> P23 << The data sequence mapping also contains a checksum of the data= that<BR>    this mapping covers.  >> - to check I understa= nd, this means you need all the data before you start to transmit it, so you= can calculate the checksum?<BR>  <BR> P24 first para under fig 10, you could delete “. Furthermore,” = and put the rest of the sentence in (..)<BR>  <BR> Last para 3.3.1 “data-level length field to “<BR> Data-level Length field of the DSS option to<BR>  <BR> P26 para 3, “that it is used” can be deleted<BR>  <BR> P26 para 4 << An MPTCP sender MUST only free data from the send buffe= r when it has<BR>    been acknowledged by both a Data ACK received on any subf= low and at<BR>    the subflow level by any subflows the data was sent on. &= nbsp;>><BR> could be clearer<BR> An MPTCP sender MUST NOT free data from the send buffer until it has<BR>    been acknowledged by both a Data ACK received on any subf= low and at<BR>    the subflow level by all subflows the data was sent on. &= nbsp;<BR> [note, 2nd ‘any’ -> ‘all’]<BR>  <BR> Same para restransmited / re-transmitted<BR>  <BR> P27 para 4 < and length 11> and Data-level Length of 11<BR>  <BR> Same thing in next para<BR>  <BR> P27 penult para – I think ‘Data Sequence Signal’ would be= more accurate here than ‘Mapping’. Also Length -> Data-level= Length<BR>  <BR> P27 last line, think you mean ‘DATA_FIN’ and not FIN<BR>  <BR> 3.3.4 para 4 << When deciding to accept packets at subflow level, nor= mal TCP uses the<BR>    sequence number in the packet and checks it against the a= llowed<BR>    receive window.  >><BR> When deciding to accept packets at the subflow level, normal TCP checks the= <BR>    sequence number in the packet against the allowed<BR>    receive window.  <BR>  <BR> P28 last line<BR> Could you spell out what rcv_next is [or at least reference B2.2.2, where i= t’s called RCV.NXT]<BR>  <BR> 3.3.4 last para ‘maximum bandwidth-delay product of any of the paths&= #8217; wonder if ‘any one of the’ would be clearer?<BR>  <BR> 3.3.6 para 1 ‘the best behaviour’ -> ‘sensible behavio= ur’<BR>  <BR> P30 last line active ACK -> actively ACK<BR>  <BR> 3.3.6 last line - < For example, subflows that perform highly asymmetric= ally may be mis-<BR>    diagnosed as underperforming.><BR> For example, a highly asymmetrically path may be mis-<BR>    diagnosed as underperforming.<BR>  <BR> P33 para 1 ‘The signal applies to a single direction:<BR>    the sender of this option, however, may >><BR> The signal applies to a single direction – and so the sender of this = option may <BR>  <BR> Next para < This<BR>    applies the given setting of B to all subflows that use t= he address<BR>    identified by the given Address ID.  ><BR> do you think it’s worth saying that this means all subflows in this c= onnection?<BR>  <BR> S3.4 para 2 < This design makes use of two methods of sharing such infor= mation,<BR>    used simultaneously.  ><BR> This design makes use of two methods of sharing such information; both can = be used on a connection.<BR>  <BR> 3.4.1 understake -> undertake<BR>  <BR> P35 para above Fig 12 as does the ephemeral port at the client – expl= ain.<BR>  <BR> Same para, “signalling subflow’ – should this  be &#= 8216;initial subflow’?<BR>  <BR> Fig 12 caption – can delete ‘(shown for IPv4)’ – as= pic includes v6<BR>  <BR> P36 para 2 < This would be to ensure that this> This would ensure tha= t <BR>  <BR> 3.4.1 last para < an MPTCP<BR>    implementation MUST NOT treat duplicate ACKs with any MPT= CP option<BR>    apart from DSS as indications of congestion >><BR> “NOT … any .. apart from” is ambiguous.<BR>  <BR> P38 last bullet < The number of<BR>       retransmissions should be limited ><= BR> SHOULD?<BR>  <BR> S3.6 – end of sentence 1 – add ‘for instance they aren= 217;t blocked or mangled by a middlebox <BR>  <BR> 3.6 para 4 < with the length value of 0 > with the Data-level Length = set to 0 <BR>  <BR> P40 para 1 I couldn’t parse this:-<BR> (Note that these rules do not apply if an<BR>    infinite mapping is included from the start - in which ca= se, each end<BR>    will send DSS options declaring the infinite mapping.)<BR= >  <BR> Fig 15 Length may be 8 & DSN may be 4 octets<BR>  <BR> 3.6 penult para “fallback mode” – what is this?<BR>  <BR> 3.8.3 para 2 < a host should fall back> SHOULD<BR>  <BR> S4, Duplicate ack. “To avoid any” -> To limit<BR>  <BR> S4, Receive window penult line <also need to> also needs to<BR>  <BR> S5, big para on p46 < used on subflow setup that verify that > used o= n subflow setup, in order to verify that <BR>  <BR> P47 line 1, “will allow” -> allows<BR>  <BR> S6 para 1 &   P54 para 2<BR> accomodate -> accommodate<BR>  <BR> S6 para 2 < Most middleboxes<BR>    should just forward packets with new options unchanged>= ;<BR> Middleboxes should just forward packets with new options unchanged  <B= R> [I think – (all) middleboxes aren’t supposed to change options;= most don’t]<BR>  <BR> P49 Traffic normalisers – should you also mention about re-transmitti= ng on the same subflow?<BR>  <BR> 9.2 – maybe worth adding rfc editor note that hoping this will become= rfc at the same time<BR>  <BR> P54 para 2 <(10B)> 10 bytes<BR>  <BR> Appendix C – point out that [DFIN] is shorthand for [DATA_FIN] –= ; (I think!) <BR>  <BR> That’s it, phew.<BR> <BR>  <BR>  <BR> From: <a href=3D"multipathtcp-bounces@ietf.org">multipathtcp-bounces@ietf.org= </a> [<a href=3D"mailto:multipathtcp-bounces@ietf.org">mailto:multipathtcp-bou= nces@ietf.org</a>] On Behalf Of Yoshifumi Nishida<BR> Sent: 18 April 2012 07:04<BR> To: <a href=3D"draft-ietf-mptcp-multiaddressed@tools.ietf.org">draft-ietf-mpt= cp-multiaddressed@tools.ietf.org</a>; multipathtcp<BR> Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07<= BR>  <BR> Hi authors,<BR>  <BR> Sorry. I would like to add one more thing. <BR>  <BR> This draft requires to create new registries for subtypes of mptcp option a= nd cryptographic algorithms handshake in MP_CAPABLE.  <BR> For this, you will need to add the description of the policy used for manag= ing these registries in the IANA considerations section. Please check the se= ction 4 of RFC5226 to see the available choices (Section 4.1) and update the= texts based on the guideline (Section 4.2).<BR>  <BR> Thanks,<BR> --<BR> Yoshifumi Nishida<BR>  <BR>  <BR>  <BR> On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida <<a href=3D"nishida@sf= c.wide.ad.jp">nishida@sfc.wide.ad.jp</a>> wrote:<BR> Hello,<BR>  <BR> Sorry for the long delay.<BR> We believe it's good time to proceed to submit draft-ietf-mptcp-multiaddres= sed to IESG.<BR>  <BR> Here's my comments on the draft to prepare a write-up for the draft.<BR> Please check and update if you agree with them.<BR>  <BR> Thanks,<BR> --<BR> Yoshifumi<BR>  <BR>  <BR> Page 13:<BR>   3.1. Connection Initiation<BR>  <BR>     ->  In my understanding, the key MUST be un= ique for each mptcp connection. <BR>          If so, I think we had= better articulate it here.<BR>  <BR> Page 17:<BR>    A host MUST store the Address IDs associated with all est= ablished subflows.<BR>  <BR>    -> Does this mean both local Address IDs and remote Ad= dress IDs advertized from the receiver?<BR>        It might be better to clarify thi= s.<BR>  <BR> Page 18:<BR>    therefore receipt of this packet MUST trigger an ACK in r= esponse<BR>  <BR>    -> Since this is MUST, I think Figure 8 needs to inclu= de this ACK in the sequence.<BR>  <BR>  <BR>    the packet MUST be retransmitted if this ACK is not recei= ved.<BR>  <BR>    -> In case of MP_CAPABLE, the third packet is not retr= ansmitted.<BR>        But, in case of MP_JOIN, it's ret= ransmitted. Readers might want to know the rationale about this.<BR>   <BR> Page 27:<BR>  <BR>    Essentially, a host MUST NOT FIN all functioning subflows= unless it is safe to do so<BR>    <BR>     -> MUST NOT close?<BR>  <BR> Page 28:<BR>  <BR>    Both hosts SHOULD send FINS, as a courtesy to allow middl= eboxes to clean up state even if the subflow is failed.<BR>    -> I'm not very sure which situations can be addressed= by this..<BR>    ..<BR>    Note that a host may also send a FIN on an individual sub= flow to shut it down, but this impact is limited to the subflow in question.= <BR>  <BR>    -> Sorry. I couldn't understand this sentences well..<= BR>  <BR> Page 30:<BR>  <BR>     The sender also remembers the receive windows adver= tised by each subflow.<BR>    <BR>     -> Don't we need to put SHOULD or MUST here?<BR>  <BR>     The send buffer must be, at the minimum, as big as = the receive buffer<BR>  <BR>     -> MUST?<BR>  <BR>     When doing this, a host must still retransmit the o= riginal data on the original subflow,<BR>  <BR>     -> MUST?<BR>  <BR> Page 37:<BR>  <BR>    if a response is received, the path is not removed.<BR>  <BR>    a subflow that is still functioning MUST be closed with a= FIN exchange<BR>  <BR>     -> Aren't these sentences inconsistent?<BR>  <BR> Page 40:<BR>  <BR>    fallback to regular TCP can become necessary at any point= during a connection if a non-MPTCP-aware middlebox changes the data stream.= <BR>  <BR>     -> The paragraph below this suggest when multipl= e subflows are in use, the affected subflow must be terminated, but not sugg= esting fallback.<BR>          So, fallback seems no= t to be necessary?<BR>  <BR>    Therefore, it is not possible to recover the subflow, and= the affected subflow must be immediately closed with an RST.<BR>  <BR>     -> MUST?<BR>  <BR>    Failed data will not be DATA_ACKed.<BR>  <BR>     -> MUST NOT be DATA_ACKed?<BR>  <BR>  <BR> Page 47:<BR>  <BR>    If this is dropped, MPTCP SHOULD fall back to regular TCP= .<BR>  <BR>     -> may be MUST? since we cannot continue to use = MPTCP . <BR>  <BR>    If packets with the MP_JOIN option are dropped, the paths= will simply not be used.<BR>  <BR>     -> MUST NOT be used? <BR>  <BR>  <BR> Page 51:<BR>  <BR>    Should use RFC6234 instead of RFC4634<BR>  <BR> Page 52:<BR>  <BR>    Should use RFC5681 instead of RFC2581<BR>    Should use draft-ietf-tcpm-secury-03 instead of -02<BR>    Should use draft-ietf-mptcp-api-04 or 05? instead of -03<= BR>  <BR>  <BR> There are some typos in the doc. Please update them by some tools.<BR>  <BR>  <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#222222"><BR> </FONT><BR> </SPAN></FONT> </BODY> </HTML> --B_3420789456_3100212-- From nishida@sfc.wide.ad.jp Fri May 25 11:48:59 2012 Return-Path: <nishida@sfc.wide.ad.jp> X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D764921F8775 for <multipathtcp@ietfa.amsl.com>; Fri, 25 May 2012 11:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.577 X-Spam-Level: X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBJyK2ADqVtu for <multipathtcp@ietfa.amsl.com>; Fri, 25 May 2012 11:48:59 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id E5B8321F873B for <multipathtcp@ietf.org>; Fri, 25 May 2012 11:48:57 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D24502780B4 for <multipathtcp@ietf.org>; Sat, 26 May 2012 03:48:53 +0900 (JST) Received: by lbbgo11 with SMTP id go11so980389lbb.31 for <multipathtcp@ietf.org>; Fri, 25 May 2012 11:48:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.104.47 with SMTP id gb15mr4497923lab.45.1337971731459; Fri, 25 May 2012 11:48:51 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Fri, 25 May 2012 11:48:51 -0700 (PDT) In-Reply-To: <30991B60-11E9-4062-9EFE-952EB9394364@iii.ca> References: <4AAE17A6-0E0A-492C-96D0-C7D0DBF5C78F@netapp.com> <30991B60-11E9-4062-9EFE-952EB9394364@iii.ca> Date: Fri, 25 May 2012 11:48:51 -0700 Message-ID: <CAO249ycmGRgxKmnseZndXCcxMOhR66KX0OJ9_+TO0yhDeDeAWg@mail.gmail.com> From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp> To: multipathtcp <multipathtcp@ietf.org> Content-Type: multipart/alternative; boundary=f46d0421824dc5ed5604c0e0d190 Subject: [multipathtcp] Fwd: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp> List-Post: <mailto:multipathtcp@ietf.org> List-Help: <mailto:multipathtcp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 May 2012 18:48:59 -0000 --f46d0421824dc5ed5604c0e0d190 Content-Type: text/plain; charset=ISO-8859-1 FYI.. IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication****July 28, 2012 Vancouver, Canada**** ** ** The IAB and IRTF will hold a workshop on Congestion Control for Interactive Real-Time Communication" in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html<http://www.ietf.org/meeting/83/index.html>). Participation at the workshop is free of charge. There is no requirement to either register with or attend the IETF-84 meeting that follows the workshop.**** ** ** The workshop organizers would like to foster a discussion on:**** 1. What are appropriate congestion signals to use for interactive media and data?**** 2. What existing congestion control algorithms are appropriate for interactive media and data? What properties would be desirable in new congestion control algorithms?**** 3. Measurement and/or simulations of new congestion signals (e.g., delay-based) and their interaction with existing congestion control mechanisms.**** 4. What are good available techniques for adjusting sending rates for interactive media and data? What are the limits of those techniques? What properties would be desirable in new techniques?**** 5. What application-specific considerations have to be taken into account?**** 6. How can we ensure that real-time communications are well-behaved with respect to other Internet applications while still providing good quality? **** 7. What should the IETF and/or IRTF do?**** The organizers seek position papers on any or all of these topics, as well as other topics related to congestion control for interactive realtime media.**** ** ** Every prospective workshop participant must submit a position paper containing a name and an email address. Authors of accepted papers will be invited to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Accepted position papers will be published. Additional details about the meeting venue will be provided to authors of accepted papers.**** Important Dates**** Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012**** Additional Details**** Additional details on the workshop as well as the submission process is available at http://www.iab.org/cc-workshop/**** Contact****To sponsors: If you are interested to help us working towards better interactive media congestion control mechanisms on the Internet (such as by making a contribution towards catering costs and room rental), please contact us!**** In case of questions please send email to mary.ietf.barnes at gmail.com.**** ** ** --f46d0421824dc5ed5604c0e0d190 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI..<br><br><div class=3D"gmail_quote"><div style=3D"word-wrap:break-word"= ><div><div><br><blockquote type=3D"cite"><span style=3D"border-collapse:sep= arate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weig= ht:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;= text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;fon= t-size:medium"><div link=3D"blue" vlink=3D"purple" style=3D"word-wrap:break= -word" lang=3D"EN-US"> <div><h1 style=3D"margin-right:0in;margin-left:0in;font-size:24pt;font-fami= ly:'Times New Roman',serif;margin-top:0in;margin-bottom:0.0001pt;te= xt-align:center" align=3D"center"><span style=3D"font-size:18pt;font-family= :Arial,sans-serif">IAB / IRTF Workshop on<br> Congestion Control for Interactive<br>Real-Time Communication</span><u></u>= <u></u></h1><h2 style=3D"margin-right:0in;margin-left:0in;font-size:18pt;fo= nt-family:'Times New Roman',serif;margin-top:0in;margin-bottom:0.00= 01pt;text-align:center" align=3D"center"> <span style=3D"font-size:14.5pt;font-family:Arial,sans-serif">July 28, 2012= <br>Vancouver, Canada</span><u></u><u></u></h2><div style=3D"margin-top:0in= ;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:11pt;fon= t-family:Calibri,sans-serif"> <span style=3D"font-size:11.5pt;font-family:Arial,sans-serif"><u></u>=A0<u>= </u></span></div><div style=3D"margin-top:0in;margin-right:0in;margin-left:= 0in;margin-bottom:0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><= span style=3D"font-size:11.5pt;font-family:Arial,sans-serif">The IAB and IR= TF will hold a workshop on Congestion Control for Interactive Real-Time Com= munication" in Vancouver, Canada on Saturday, July 28th, 2012 prior to= the IETF-84 meeting (see<span>=A0</span></span><a href=3D"http://www.ietf.= org/meeting/83/index.html" style=3D"color:blue;text-decoration:underline" t= arget=3D"_blank"><span style=3D"font-size:11.5pt;font-family:Arial,sans-ser= if;color:rgb(17,85,204)">http://www.ietf.org/meeting/84/index.html</span></= a><span style=3D"font-size:11.5pt;font-family:Arial,sans-serif">). =A0Parti= cipation at the workshop is free of charge. There is no requirement to eith= er register with or attend the IETF-84 meeting that follows the workshop.<u= ></u><u></u></span></div> <div style=3D"margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom= :0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style=3D"fon= t-size:11.5pt;font-family:Arial,sans-serif"><u></u>=A0<u></u></span></div><= div style=3D"margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:= 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> <span style=3D"font-size:11.5pt;font-family:Arial,sans-serif">The workshop = organizers would like to foster a discussion on:</span><span style=3D"font-= size:12pt;font-family:'Times New Roman',serif"><u></u><u></u></span= ></div> <ol start=3D"1" style=3D"margin-bottom:0in" type=3D"1"><li class=3D"MsoNorm= al" style=3D"vertical-align:baseline;margin-right:0in;font-size:11pt;margin= -left:0in;margin-bottom:0.0001pt;font-family:Calibri,sans-serif;margin-top:= 0in"><span style=3D"font-size:11.5pt;font-family:Arial,sans-serif">What are= appropriate congestion signals to use for interactive media and data?<u></= u><u></u></span></li> <li class=3D"MsoNormal" style=3D"vertical-align:baseline;margin-right:0in;f= ont-size:11pt;margin-left:0in;margin-bottom:0.0001pt;font-family:Calibri,sa= ns-serif;margin-top:0in"><span style=3D"font-size:11.5pt;font-family:Arial,= sans-serif">What existing congestion control algorithms are appropriate for= interactive media and data? What properties would be desirable in new cong= estion control algorithms?<u></u><u></u></span></li> <li class=3D"MsoNormal" style=3D"vertical-align:baseline;margin-right:0in;f= ont-size:11pt;margin-left:0in;margin-bottom:0.0001pt;font-family:Calibri,sa= ns-serif;margin-top:0in"><span style=3D"font-size:11.5pt;font-family:Arial,= sans-serif">Measurement and/or simulations of new congestion signals (e.g.,= delay-based) and their interaction with existing congestion control mechan= isms.<u></u><u></u></span></li> <li class=3D"MsoNormal" style=3D"vertical-align:baseline;margin-right:0in;f= ont-size:11pt;margin-left:0in;margin-bottom:0.0001pt;font-family:Calibri,sa= ns-serif;margin-top:0in"><span style=3D"font-size:11.5pt;font-family:Arial,= sans-serif">What are good available techniques for adjusting sending rates = for interactive media and data? What are the limits of those techniques? Wh= at properties would be desirable in new techniques?<u></u><u></u></span></l= i> <li class=3D"MsoNormal" style=3D"vertical-align:baseline;margin-right:0in;f= ont-size:11pt;margin-left:0in;margin-bottom:0.0001pt;font-family:Calibri,sa= ns-serif;margin-top:0in"><span style=3D"font-size:11.5pt;font-family:Arial,= sans-serif">What application-specific considerations have to be taken into = account?<u></u><u></u></span></li> <li class=3D"MsoNormal" style=3D"vertical-align:baseline;margin-right:0in;f= ont-size:11pt;margin-left:0in;margin-bottom:0.0001pt;font-family:Calibri,sa= ns-serif;margin-top:0in"><span style=3D"font-size:11.5pt;font-family:Arial,= sans-serif">How can we ensure that real-time communications are well-behave= d with respect to other Internet applications while still providing good qu= ality?<u></u><u></u></span></li> <li class=3D"MsoNormal" style=3D"vertical-align:baseline;margin-right:0in;f= ont-size:11pt;margin-left:0in;margin-bottom:0.0001pt;font-family:Calibri,sa= ns-serif;margin-top:0in"><span style=3D"font-size:11.5pt;font-family:Arial,= sans-serif">What should the IETF and/or IRTF do?<u></u><u></u></span></li> </ol><div style=3D"margin-top:0in;margin-right:0in;margin-left:0in;margin-b= ottom:0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style= =3D"font-size:11.5pt;font-family:Arial,sans-serif">The organizers seek posi= tion papers on any or all of these topics, as well as other topics related = to congestion control for interactive realtime media.<u></u><u></u></span><= /div> <div style=3D"margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom= :0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style=3D"fon= t-size:11.5pt;font-family:Arial,sans-serif"><u></u>=A0<u></u></span></div><= div style=3D"margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:= 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> <span style=3D"font-size:11.5pt;font-family:Arial,sans-serif">Every prospec= tive workshop participant must submit a position paper containing a name an= d an email address. Authors of accepted papers will be invited to the works= hop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for examp= le, as a submitted Internet-Draft) are ideal. Accepted position papers will= be published.=A0 Additional details about the meeting venue will be provid= ed to authors of accepted papers.<u></u><u></u></span></div> <h2 style=3D"margin-right:0in;margin-left:0in;font-size:18pt;font-family:&#= 39;Times New Roman',serif"><span style=3D"font-size:14.5pt;font-family:= Arial,sans-serif">Important Dates</span><u></u><u></u></h2><div style=3D"ma= rgin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-s= ize:11pt;font-family:Calibri,sans-serif"> <span style=3D"font-size:11.5pt;font-family:Arial,sans-serif">Position pape= r submission deadline: =A0=A0=A0=A0=A0=A0=A0=A0 June 23, 2012</span><br><sp= an style=3D"font-size:11.5pt;font-family:Arial,sans-serif">Notification to = paper authors: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 June 30, 2012</span><br> <span style=3D"font-size:11.5pt;font-family:Arial,sans-serif">Workshop date= : =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 July 28, 2012</sp= an><u></u><u></u></div><h2 style=3D"margin-right:0in;margin-left:0in;font-s= ize:18pt;font-family:'Times New Roman',serif"> <span style=3D"font-size:14.5pt;font-family:Arial,sans-serif">Additional De= tails<u></u><u></u></span></h2><div style=3D"margin-top:0in;margin-right:0i= n;margin-left:0in;margin-bottom:0.0001pt;font-size:11pt;font-family:Calibri= ,sans-serif"> <span style=3D"font-size:11.5pt;font-family:Arial,sans-serif">Additional de= tails on the workshop as well as the submission process is available at<spa= n>=A0</span><a href=3D"http://www.iab.org/cc-workshop/" style=3D"color:blue= ;text-decoration:underline" target=3D"_blank">http://www.iab.org/cc-worksho= p/</a><u></u><u></u></span></div> <h2 style=3D"margin-right:0in;margin-left:0in;font-size:18pt;font-family:&#= 39;Times New Roman',serif"><span style=3D"font-size:14.5pt;font-family:= Arial,sans-serif">Contact<u></u><u></u></span></h2><h2 style=3D"margin-righ= t:0in;margin-left:0in;font-size:18pt;font-family:'Times New Roman',= serif"> <span style=3D"font-size:11.5pt;font-family:Arial,sans-serif;font-weight:no= rmal">To sponsors: If you are interested to help us working towards better = interactive media congestion control mechanisms on the Internet (such as by= making a contribution towards catering costs and room rental), please cont= act us!</span><span style=3D"font-weight:normal"><u></u><u></u></span></h2> <div style=3D"margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom= :0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style=3D"fon= t-size:11.5pt;font-family:Arial,sans-serif">In case of questions please sen= d email to mary.ietf.barnes at<span>=A0</span><a href=3D"http://gmail.com/"= style=3D"color:blue;text-decoration:underline" target=3D"_blank">gmail.com= </a>.<u></u><u></u></span></div> <div style=3D"margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom= :0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u>=A0<u></u><= /div></div></div></span></blockquote></div><br></div></div></div><br> --f46d0421824dc5ed5604c0e0d190-- From philip.eardley@bt.com Tue May 29 01:22:24 2012 Return-Path: <philip.eardley@bt.com> X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9117021F8767 for <multipathtcp@ietfa.amsl.com>; Tue, 29 May 2012 01:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.245 X-Spam-Level: X-Spam-Status: No, score=-101.245 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcyyhdrhYg0K for <multipathtcp@ietfa.amsl.com>; Tue, 29 May 2012 01:22:12 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 640C321F8623 for <multipathtcp@ietf.org>; Tue, 29 May 2012 01:22:11 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.264.0; Tue, 29 May 2012 09:22:10 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.15]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 29 May 2012 09:22:10 +0100 From: <philip.eardley@bt.com> To: <alanford@cisco.com>, <nishida@sfc.wide.ad.jp> Date: Tue, 29 May 2012 09:22:08 +0100 Thread-Topic: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 Thread-Index: Ac0jzbqibAFIshA0T/uPM83vXnJ6ygWkeBYaAMUdVAA= Message-ID: <9510D26531EF184D9017DF24659BB87F33C4583CCB@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F33520217BD@EMV65-UKRD.domain1.systemhost.net> <CBE51AD0.9DEB%alanford@cisco.com> In-Reply-To: <CBE51AD0.9DEB%alanford@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F33C4583CCBEMV65UKRDdoma_" MIME-Version: 1.0 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp> List-Post: <mailto:multipathtcp@ietf.org> List-Help: <mailto:multipathtcp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 May 2012 08:22:24 -0000 --_000_9510D26531EF184D9017DF24659BB87F33C4583CCBEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alan, Thanks - your changes look good to me. phil From: Alan Ford [mailto:alanford@cisco.com] Sent: 25 May 2012 11:18 To: Eardley,PL,Philip,DUB8 R; nishida@sfc.wide.ad.jp Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 Hi Phil, Many thanks for you comments. Anything I have not directly commented on bel= ow was straightforwardly addressed in -08. If there is anything you feel wa= sn't sufficiently addressed, please shout. Regards, Alan On 26/04/2012 17:57, "philip.eardley@bt.com" <philip.eardley@bt.com> wrote: Hi Alan, Costin, Mark, Olivier, Here are some comments. Sorry I finally got through it. The first lot are either significant or something worth thinking about. The= second lot are just typos & re-phrasings - feel free to ignore if you don= 't like the suggestion Thanks! phil -- Think it would be good to have a sub-section in S2 on Fast Close Also might be worth adding one on MP_FAIL ? [Alan] I decided against doing this. S2 is meant to be a light overview of = the protocol; it seems unnecessary and potentially confusing to burden read= ers with these little-used features at this stage. S3.1 penultimate para, << If this option is not present, the connection should fall back to regular TCP , as documented in Section 3.6.>> SHOULD? also S3.6 para 1 is about this - but it doesn't have any capitalisation, wh= ich presumably it should I thought that S3.2 could be clearer. Basically there are a lot of minor th= ings (see below) that add up to making it quite hard work. Fig 8 - I think the first msg (SYN + MP_CAPABLE) should have (Key-A) S3.3.0 - do you say somewhere what to do if the checksum is present but it = wasn't negotiated in MP-CAPABLE, or it isnt present but wasn't negotiated? [Alan] We do now: "If a checksum is present, but its use had not been negot= iated in the MP_CAPABLE handshake, it SHOULD be ignored. If a checksum is n= ot present when its use has been negotiated, the receiver SHOULD close the = subflow with a RST as it is considered broken." P36 para 4 < If the Address ID is not in use on a live subflow, but is stored by the receiver, a new ADD_ADDR SHOULD take precedence and replace the stored address.> I found this sentence quite hard to parse. If I understand it right, this i= s advertising a new address by over-writing an old address - using the same= Address ID. Rather than removing the old address and adding a new one with= a different Address ID. Sounds dodgy? why doing this? [Alan] You understood it right, however you're right is has a whiff of dodg= yness to it. So I've removed it - now a host that wants to replace an Addre= ss ID MUST remove it first. 3.5 - Fast Close sends the Receiver's Key in the clear. Does this open an a= ttack? [Alan] Not any new risks. Once it's sent on Fast Close, the connection is d= ead, so no further signalling with that key would have any effect. And yes,= anyone who had seen the key on the initial handshake could Fast Close the = connection. But they can do anything anyway if they've seen the key on the = initial handshake. In Fast Close, usual TCP sequence number verification is= required to ensure the signal is in-window (so an attacker would need to k= now both the key of the receiver and the sequence space of the sender). There might be value in e.g. hashing the key with the sender's DSN for slig= htly more protection; I'm not sure if that adds anything. In fact, it proba= bly goes against the point of Fast Close that the sender actively DOES NOT = CARE whether its last packets actually get to the end host. anyway, it contradicts S3.1 & S5 which say it's only sent in the clear once= , ie on MP-CAPABLE [Alan] Fixed this. 3.6 - I had it in my brain that fallback meant 'fallback from mptcp to tcp'= . Here it means '.. or close a problematic subflow'. I'm not absolutely sur= e it's used consistently throughout the doc, but it's probably worth adding= an intro para to 3.6 that says there are n ways of coping with some proble= m, close the subflow, close the connection (?), shift to tcp [Alan] You're right, it has evolved from its original meaning. Now re-worde= d: "Sometimes, middleboxes will exist on a path that could prevent the oper= ation of MPTCP. MPTCP has been designed in order to cope with many middleb= ox modifications (see Section 6), but there are still some cases where a su= bflow could fail to operate within the MPTCP requirements. These cases are= notably: the loss of TCP options on a path; and the modification of payloa= d data. If such an event occurs, it is necessary to "fall back" to the pre= vious, safe operation. This may either be falling back to regular TCP, or = removing a problematic subflow." 3.6 para 1 - needs to be a SHOULD somewhere in here 3.6 para 1 COMPARE 3.8.3 para 2 - 3.6 suggests give up on mptcp after one M= P_CAPABLE fails (& also 6 & 3.1); 3.8 suggests after several. Which is righ= t? [Alan] It's up to the implementation. The heuristics are our initial though= ts on this; implementations optimise this. The heuristics now say "one or m= ore" rather than "several". S4 Receive window last sentence, "so a host must" - SHOULD? Or maybe 'needs= to'? Also, this point doesn't appear in S3.3.4 [Alan] "needs to". Re S3.3.4, I think it is implied - there is talk there a= bout normal subflow processing. P48 penul para < If some subflow-level space is left unmapped, however, the subflow is treated as broken and is closed, as discussed in Section 3.3. > do you mean S3.6? I couldn't see anything in s3.3 [but it's a big section, so a more accurate ref would be useful - same comm= ent on p10 just above the SS pic & p40 para 3] [Alan] The reference to S3.6 there are more a general pointer to procedure = than a specific instruction - I've clarified this. P49 PEPs < MPTCP will therefore fall back to single-path TCP (see Section 3.6).> I read S3.6 to say that you close the subflow (rather than fall back to tcp= ) [Alan] S3.6 is intended to cover both, and hopefully this new intro should = make this clearer. S8 - can be updated with Option kind number 30 ! also Wes's comment about t= he subtypes [ie invent a policy for managing them] [Alan] It's now been rewritten in RFC5226 style. Appendix C - should the 'snd DATA_ACK' arrows from M_ESTAB & from M_FIN WAI= T-1 be snd DATA_ACK[DFIN] ? -- Minor suggestions etc - no need to ack these individually [but shout if I r= eveal some misunderstanding!] Throughout doc: Be consistent on 'DATA_ACK' & 'DATA_FIN' - many times appear without '_' [I= guess I prefer MP_DATA_ACK but that may be too much for your taste!] [Alan] Remember those two are flags and not specific options, so it's defin= itely inappropriate to call them MP_... But they've all grown an underscore= for consistency. I think it would be more logical if all the subtype names started MP_ [ie a= lso DSS, ADD_ADDR, REMOVE_ADDR] [again, maybe too much for your taste] [Alan] Given that these are symbols within a MPTCP-specific registry, I onl= y see MP_ as taking up unnecessary space. Sorry ;) The bare 'ID' appears quite often- think you should use 'Address ID' throug= hout [Alan] I found three instances, let me know if I've missed any. -- S1.1 <<The congestion control algorithms as discussed in [5] ensure this does not act detrimentally.>> The congestion control algorithm defined in [5] achieves this. S1.3 a reference to S4 might be nice S1.4 bullet 2, "where a TCP connection is established" - should be MPTCP co= nnection 2.1 & 2.2 - would it be more logical if 'ACK MP_CAPABLE' & 'ACK MP_JOIN' di= dn't have 'ACK' since there's no special ACK subtype? But maybe this makes = it harder to understand what's happening? 2.4 para 2 << The "Data Sequence Signal" option which carries this "Data = Sequence Mapping", which consists of the subflow sequence number, data>> The "Data Sequence Signal" option carries the "Data Sequence Mapping". The Data Sequence Mapping consists of the subflow sequence num= ber, data 2.7 bullet 1 "MP-ADD-ADDR" should be ADD_ADDR (unless you change subtype na= mes to all start MP_ !) 3.1 para 4, last sentence (The subflow handshake mechanism...) is quite har= d to parse 3.1, last para p14 << The leftmost bit - labeled C - indicates "Checksum required", and SHOULD be set to 1 unless specifically overridden (for example, if the system administrator has decided that checksums are not required - see Section 3.3 for more discussion)>> The leftmost bit - labelled C - SHOULD be set to 1 to indicate "Checksum re= quired", unless the system administrator has decided that checksums are not required - see Section 3.3 for more discussion) also, S3.3 doesn't discuss why someone might decide to use checksums, or de= cide not to. Might be nice to add a hint about this somewhere also, when there are multiple crypo algos, do we want to point out that the= same one MUST be used for everything (generating token, isdn etc)? maybe t= his is obvious and anyway would be better in any subsequent doc about alter= native crypto [Alan] That's a good point, however I think it is best to leave it to any n= ew documents to decide whether they also want to tie a new crypto algorithm= with tokens/IDSN generation. p15 - I thought the first sentence ["These bits.." was redundant p15 para 2 << The initiator creates a proposal setting a bit for each algorithm >> The initiator sets a bit for each algorithm P16, last para of 3.1 << The initial Data Sequence Number (IDSN) is generat= ed as a hash from the Key, in the same way as the token, i.e. IDSN-A =3D Hash(Key-A) and IDSN-B =3D Hash(Key-B).>> The Initial Data Sequence Number (IDSN) is generated as a hash from the Key, i.e. IDSN-A =3D Hash(Key-A) and IDSN-B =3D Hash(Key-B). Middle p17 - the 'this' bonanza made it hard to understand. How about (incl= udes a couple of other changes):- The MP_JOIN option includes an "Address ID". This is an identifier that only has significance within a single connection, where it identifies the original source address of the packet, even if the IP hea= der has been changed in transit by a middlebox. This allows address removal (Section 3.4.2) without needing to know what the source = address at the receiver is, and thus allows address removal through NATs. It also a= llows correlation between new subflow setup attempts and address signaling (Section 3.4.1), to prevent setting up duplicate subflows on the same path. P17 last para<< The MP_JOIN option on SYNs >> add 'and SYN_ACKs' [Alan] "Packets with the SYN flag set" P18 first para under Fig 5 << Although cryptographic calculations are requi= red in the SYN/ACK, it is felt that the 32 bit token gives >> Although calculating a MAC requires cryptographic operations, it is believe= d that the 32 bit token in the MP_JOIN SYN gives P18 2nd para, sentence 2 "This is to allow.." takes some working out. Maybe= : "This allow Host B to use random data sent by Host A in the SYN, as part = of the MAC algorithm; and similarly Host A to use random data sent by Host = B in the SYN/ACK. Last sentence of this para can be shortened: Due to option space limitations, the MAC included in the SYN/ACK is truncated to the leftmost 64 bits, but this is acceptable since an attacker has only one chance to guess the MAC correctly. Next para - "and this is" -> "as" Same para "MUST trigger an ACK in response" - maybe you could stress that t= his is an ordinary data ACK P19 "The message in each case " -> The message for the MAC algorithm in eac= h case S3.2, the Random Number =3D=3D Nonce in S2. Point out, or change one of the= m. S3.3 para 2 & 3 could be re-phrased slightly:- During normal MPTCP operation, the Data Sequence Mapping defines how the= sequence space on the subflow maps to the connection level; and the Data ACK acknowledges receipt of data at the connection level. These functions are described in more detail in the following two subsections. The Data Sequence Mapping and the Data ACK are signalled in the Data Sequen= ce Signal (DSS). Either or both can be signalled in one DSS, dependent on t= he flags set. P23 << The data sequence mapping also contains a checksum of the data that this mapping covers. >> - to check I understand, this means you need al= l the data before you start to transmit it, so you can calculate the checks= um? P24 first para under fig 10, you could delete ". Furthermore," and put the = rest of the sentence in (..) Last para 3.3.1 "data-level length field to " Data-level Length field of the DSS option to P26 para 3, "that it is used" can be deleted P26 para 4 << An MPTCP sender MUST only free data from the send buffer when= it has been acknowledged by both a Data ACK received on any subflow and at the subflow level by any subflows the data was sent on. >> could be clearer An MPTCP sender MUST NOT free data from the send buffer until it has been acknowledged by both a Data ACK received on any subflow and at the subflow level by all subflows the data was sent on. [note, 2nd 'any' -> 'all'] Same para restransmited / re-transmitted P27 para 4 < and length 11> and Data-level Length of 11 Same thing in next para P27 penult para - I think 'Data Sequence Signal' would be more accurate her= e than 'Mapping'. Also Length -> Data-level Length P27 last line, think you mean 'DATA_FIN' and not FIN 3.3.4 para 4 << When deciding to accept packets at subflow level, normal TC= P uses the sequence number in the packet and checks it against the allowed receive window. >> When deciding to accept packets at the subflow level, normal TCP checks the sequence number in the packet against the allowed receive window. P28 last line Could you spell out what rcv_next is [or at least reference B2.2.2, where i= t's called RCV.NXT] 3.3.4 last para 'maximum bandwidth-delay product of any of the paths' wonde= r if 'any one of the' would be clearer? 3.3.6 para 1 'the best behaviour' -> 'sensible behaviour' P30 last line active ACK -> actively ACK 3.3.6 last line - < For example, subflows that perform highly asymmetricall= y may be mis- diagnosed as underperforming.> For example, a highly asymmetrically path may be mis- diagnosed as underperforming. P33 para 1 'The signal applies to a single direction: the sender of this option, however, may >> The signal applies to a single direction - and so the sender of this option= may Next para < This applies the given setting of B to all subflows that use the address identified by the given Address ID. > do you think it's worth saying that this means all subflows in this connect= ion? S3.4 para 2 < This design makes use of two methods of sharing such informat= ion, used simultaneously. > This design makes use of two methods of sharing such information; both can = be used on a connection. 3.4.1 understake -> undertake P35 para above Fig 12 as does the ephemeral port at the client - explain. Same para, "signalling subflow' - should this be 'initial subflow'? Fig 12 caption - can delete '(shown for IPv4)' - as pic includes v6 P36 para 2 < This would be to ensure that this> This would ensure that 3.4.1 last para < an MPTCP implementation MUST NOT treat duplicate ACKs with any MPTCP option apart from DSS as indications of congestion >> "NOT ... any .. apart from" is ambiguous. P38 last bullet < The number of retransmissions should be limited > SHOULD? S3.6 - end of sentence 1 - add 'for instance they aren't blocked or mangled= by a middlebox 3.6 para 4 < with the length value of 0 > with the Data-level Length set to= 0 P40 para 1 I couldn't parse this:- (Note that these rules do not apply if an infinite mapping is included from the start - in which case, each end will send DSS options declaring the infinite mapping.) Fig 15 Length may be 8 & DSN may be 4 octets 3.6 penult para "fallback mode" - what is this? 3.8.3 para 2 < a host should fall back> SHOULD S4, Duplicate ack. "To avoid any" -> To limit S4, Receive window penult line <also need to> also needs to S5, big para on p46 < used on subflow setup that verify that > used on subf= low setup, in order to verify that P47 line 1, "will allow" -> allows S6 para 1 & P54 para 2 accomodate -> accommodate S6 para 2 < Most middleboxes should just forward packets with new options unchanged> Middleboxes should just forward packets with new options unchanged [I think - (all) middleboxes aren't supposed to change options; most don't] P49 Traffic normalisers - should you also mention about re-transmitting on = the same subflow? 9.2 - maybe worth adding rfc editor note that hoping this will become rfc a= t the same time P54 para 2 <(10B)> 10 bytes Appendix C - point out that [DFIN] is shorthand for [DATA_FIN] - (I think!) That's it, phew. From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Yoshifumi Nishida Sent: 18 April 2012 07:04 To: draft-ietf-mptcp-multiaddressed@tools.ietf.org; multipathtcp Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 Hi authors, Sorry. I would like to add one more thing. This draft requires to create new registries for subtypes of mptcp option a= nd cryptographic algorithms handshake in MP_CAPABLE. For this, you will need to add the description of the policy used for manag= ing these registries in the IANA considerations section. Please check the s= ection 4 of RFC5226 to see the available choices (Section 4.1) and update t= he texts based on the guideline (Section 4.2). Thanks, -- Yoshifumi Nishida On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp= > wrote: Hello, Sorry for the long delay. We believe it's good time to proceed to submit draft-ietf-mptcp-multiaddres= sed to IESG. Here's my comments on the draft to prepare a write-up for the draft. Please check and update if you agree with them. Thanks, -- Yoshifumi Page 13: 3.1. Connection Initiation -> In my understanding, the key MUST be unique for each mptcp connecti= on. If so, I think we had better articulate it here. Page 17: A host MUST store the Address IDs associated with all established subflo= ws. -> Does this mean both local Address IDs and remote Address IDs advertiz= ed from the receiver? It might be better to clarify this. Page 18: therefore receipt of this packet MUST trigger an ACK in response -> Since this is MUST, I think Figure 8 needs to include this ACK in the= sequence. the packet MUST be retransmitted if this ACK is not received. -> In case of MP_CAPABLE, the third packet is not retransmitted. But, in case of MP_JOIN, it's retransmitted. Readers might want to k= now the rationale about this. Page 27: Essentially, a host MUST NOT FIN all functioning subflows unless it is s= afe to do so -> MUST NOT close? Page 28: Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to clean= up state even if the subflow is failed. -> I'm not very sure which situations can be addressed by this.. .. Note that a host may also send a FIN on an individual subflow to shut it= down, but this impact is limited to the subflow in question. -> Sorry. I couldn't understand this sentences well.. Page 30: The sender also remembers the receive windows advertised by each subflo= w. -> Don't we need to put SHOULD or MUST here? The send buffer must be, at the minimum, as big as the receive buffer -> MUST? When doing this, a host must still retransmit the original data on the = original subflow, -> MUST? Page 37: if a response is received, the path is not removed. a subflow that is still functioning MUST be closed with a FIN exchange -> Aren't these sentences inconsistent? Page 40: fallback to regular TCP can become necessary at any point during a conne= ction if a non-MPTCP-aware middlebox changes the data stream. -> The paragraph below this suggest when multiple subflows are in use, = the affected subflow must be terminated, but not suggesting fallback. So, fallback seems not to be necessary? Therefore, it is not possible to recover the subflow, and the affected s= ubflow must be immediately closed with an RST. -> MUST? Failed data will not be DATA_ACKed. -> MUST NOT be DATA_ACKed? Page 47: If this is dropped, MPTCP SHOULD fall back to regular TCP. -> may be MUST? since we cannot continue to use MPTCP . If packets with the MP_JOIN option are dropped, the paths will simply no= t be used. -> MUST NOT be used? Page 51: Should use RFC6234 instead of RFC4634 Page 52: Should use RFC5681 instead of RFC2581 Should use draft-ietf-tcpm-secury-03 instead of -02 Should use draft-ietf-mptcp-api-04 or 05? instead of -03 There are some typos in the doc. Please update them by some tools. --_000_9510D26531EF184D9017DF24659BB87F33C4583CCBEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema= s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html= 40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset= =3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 (filtered = medium)"><title>Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddres= sed-07

Alan,

Thanks – your changes look good to me.

phil

 

From: Alan Ford [mailto:alanford@cisco= .com]
Sent: 25 May 2012 11:18
To: Eardley,PL,Philip,DU= B8 R; nishida@sfc.wide.ad.jp
Cc: multipathtcp@ietf.org
Subj= ect: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07<= o:p>

 

=

Hi Phil,

Many thanks fo= r you comments. Anything I have not directly commented on below was straigh= tforwardly addressed in –08. If there is anything you feel wasn’= ;t sufficiently addressed, please shout.

Regards,
Alan

On = 26/04/2012 17:57, "philip.eardley@bt= .com" <philip.eardley@bt.com<= /a>> wrote:

Hi Alan, Costin, Mark, Ol= ivier,
 
Here are some comments. Sorry I finally got through it.=
The first lot are either significant or something worth thinking about.= The  second lot are just typos & re-phrasings – feel free t= o ignore if you don’t like the suggestion
 
Thanks!
phi= l
 
--
 
Think it would be good to have a sub-section= in S2 on Fast Close
 
Also might be worth adding one on MP_FAIL= ?

[Alan] I decided against doing this. S= 2 is meant to be a light overview of the protocol; it seems unnecessary and= potentially confusing to burden readers with these little-used features at= this stage.

S3.1 penultimate para, << If this
 = ;  option is not present, the connection should fall back to regu= lar
   TCP , as documented in Section 3.6.>>
SHO= ULD?
also S3.6 para 1 is about this – but it doesn’t have an= y capitalisation, which presumably it should
 
I thought that S3= .2 could be clearer. Basically there are a lot of minor things (see below) = that add up to making it quite hard work.
 
Fig 8 – I thin= k the first msg (SYN + MP_CAPABLE) should have (Key-A)
 
S3.3.0 = – do you say somewhere what to do if the checksum is present but it w= asn’t negotiated in MP-CAPABLE, or it isnt present but wasn’t n= egotiated?
 
[Alan] We do now: “= ;If a checksum is present, but its use had not been negotiated in the MP_CA= PABLE handshake, it SHOULD be ignored. If a checksum is not present when it= s use has been negotiated, the receiver SHOULD close the subflow with a RST= as it is considered broken.”

P36 para 4 < If the Ad= dress ID is not in use on a
   live subflow, but is store= d by the receiver, a new ADD_ADDR SHOULD
   take preceden= ce and replace the stored address.>
I found this sentence quite hard = to parse. If I understand it right, this is advertising a new address by ov= er-writing an old address - using the same Address ID. Rather than removing= the old address and adding a new one with a different Address ID. Sounds d= odgy? why doing this?

[Alan] You understo= od it right, however you’re right is has a whiff of dodgyness to it. = So I’ve removed it – now a host that wants to replace an Addres= s ID MUST remove it first.

3.5 – Fast Close sends the R= eceiver’s Key in the clear. Does this open an attack?  

<= span style=3D'color:blue'>[Alan] Not any new risks. Once it’s sent on= Fast Close, the connection is dead, so no further signalling with that key= would have any effect. And yes, anyone who had seen the key on the initial= handshake could Fast Close the connection. But they can do anything anyway= if they’ve seen the key on the initial handshake. In Fast Close, usu= al TCP sequence number verification is required to ensure the signal is in-= window (so an attacker would need to know both the key of the receiver and = the sequence space of the sender).

There might be value in e.g. hash= ing the key with the sender’s DSN for slightly more protection; IR= 17;m not sure if that adds anything. In fact, it probably goes against the = point of Fast Close that the sender actively DOES NOT CARE whether its last= packets actually get to the end host.

anyway, it contradicts= S3.1 & S5 which say it’s only sent in the clear once, ie on MP-C= APABLE

[Alan] Fixed this.

3= .6 – I had it in my brain that fallback meant ‘fallback from mp= tcp to tcp’. Here it means ‘.. or close a problematic subflow&#= 8217;. I’m not absolutely sure it’s used consistently throughou= t the doc, but it’s probably worth adding an intro para to 3.6 that s= ays there are n ways of coping with some problem, close the subflow, close = the connection (?), shift to tcp

[Alan] Y= ou’re right, it has evolved from its original meaning. Now re-worded:= “Sometimes, middleboxes will exist on a path that could prevent the = operation of MPTCP.  MPTCP has been designed in order to cope with man= y middlebox modifications (see Section 6), but there are still some cases w= here a subflow could fail to operate within the MPTCP requirements.  T= hese cases are notably: the loss of TCP options on a path; and the modifica= tion of payload data.  If such an event occurs, it is necessary to &qu= ot;fall back" to the previous, safe operation.  This may either b= e falling back to regular TCP, or removing a problematic subflow.”
3.6 para 1 – needs to be a SHOULD somewhere in here
&n= bsp;
3.6 para 1 COMPARE 3.8.3 para 2 – 3.6 suggests give up on mpt= cp after one MP_CAPABLE fails (& also 6 & 3.1); 3.8 suggests after = several. Which is right?

[Alan] It’= ;s up to the implementation. The heuristics are our initial thoughts on thi= s; implementations optimise this. The heu= ristics now say “one or more” rather than “several”= .

S4 Receive window last sentence, “so a host mustR= 21; – SHOULD? Or maybe ‘needs to’?  Also, this point= doesn’t appear in S3.3.4

[Alan] &#= 8220;needs to”. Re S3.3.4, I think it is implied – there is tal= k there about normal subflow processing.

P48 penul para < = If some subflow-level space is left unmapped,
   however,= the subflow is treated as broken and is closed, as discussed
 &nbs= p; in Section 3.3.  >
do you mean S3.6? I couldn’t se= e anything in s3.3
 
[but it’s a big section, so a more a= ccurate ref would be useful – same comment on p10 just above the SS p= ic & p40 para 3]

[Alan] The reference= to S3.6 there are more a general pointer to procedure than a specific inst= ruction – I’ve clarified this.

P49 PEPs < MPTC= P will
      therefore fall back to single= -path TCP (see Section 3.6).>
I read S3.6 to say that you close the s= ubflow (rather than fall back to tcp)

[Al= an] S3.6 is intended to cover both, and hopefully this new intro should mak= e this clearer.

S8 – can be updated with Option kind nu= mber 30 ! also Wes’s comment about the subtypes [ie invent a policy f= or managing them]

[Alan] It’s now = been rewritten in RFC5226 style.

Appendix C – should th= e ‘snd DATA_ACK’ arrows from M_ESTAB & from M_FIN WAIT-1 &n= bsp;be snd DATA_ACK[DFIN] ?  
 
--
 
Minor sugge= stions etc – no need to ack these individually [but shout if I reveal= some misunderstanding!]
 
Throughout doc:
 
Be cons= istent on ‘DATA_ACK’ & ‘DATA_FIN’ – many = times appear without ‘_’ [I guess I prefer MP_DATA_ACK but that= may be too much for your taste!]

[Alan] = Remember those two are flags and not specific options, so it’s defini= tely inappropriate to call them MP_... But they’ve all grown an under= score for consistency.

I think it would be more logical if al= l the subtype names started MP_ [ie also DSS, ADD_ADDR, REMOVE_ADDR] [again= , maybe too much for your taste]

[Alan] G= iven that these are symbols within a MPTCP-specific registry, I only see MP= _ as taking up unnecessary space. Sorry ;)

The bare ‘I= D’ appears quite often- think you should use ‘Address ID’= throughout

[Alan] I found three instance= s, let me know if I’ve missed any.

--
 
S1.1= <<The
   congestion control algorithms as discusse= d in [5] ensure this does
   not act detrimentally.>&g= t;
The congestion control algorithm defined in [5] achieves this.
&nb= sp;
S1.3 a reference to S4 might be nice
 
S1.4 bullet 2, &#= 8220;where a TCP connection is established” – should be MPTCP c= onnection
 
2.1 & 2.2 – would it be more logical if &#= 8216;ACK MP_CAPABLE’ & ‘ACK MP_JOIN’ didn’t hav= e ‘ACK’ since there’s no special ACK subtype? But maybe t= his makes it harder to understand what’s happening?
 
2.4 = para 2 <<   The "Data Sequence Signal" option whi= ch carries this "Data Sequence
   Mapping", whi= ch consists of the subflow sequence number, data>>
  &nb= sp;The "Data Sequence Signal" option carries the "Data Seque= nce
   Mapping". The Data Sequence Mapping consists = of the subflow sequence number, data
 
2.7 bullet 1 “MP-AD= D-ADDR” should be ADD_ADDR (unless you change subtype names to all st= art MP_ !)
 
3.1 para 4, last sentence (The subflow handshake me= chanism…) is quite hard to parse
 
3.1, last para p14 <= < The leftmost bit - labeled C
   - indicates "Ch= ecksum required", and SHOULD be set to 1 unless
   s= pecifically overridden (for example, if the system administrator has
&nb= sp;  decided that checksums are not required - see Section 3.3 fo= r more
   discussion)>>
The leftmost bit - label= led C - SHOULD be set to 1 to indicate "Checksum required", unles= s the system administrator has
   decided that checksums = are not required - see Section 3.3 for more
   discussion= )
 
also, S3.3 doesn’t discuss why someone might decide to= use checksums, or decide not to. Might be nice to add a hint about this so= mewhere
 
also, when there are multiple crypo algos, do we want = to point out that the same one MUST be used for everything (generating toke= n, isdn etc)? maybe this is obvious and anyway would be better in any subse= quent doc about alternative crypto
 
= [Alan] That’s a good point, however I think it is best to leave it to= any new documents to decide whether they also want to tie a new crypto alg= orithm with tokens/IDSN generation.

p15 – I thought the= first sentence [“These bits..” was redundant
 
p15 = para 2 << The initiator
   creates a proposal setti= ng a bit for each algorithm >>
The initiator sets a bit for each a= lgorithm
 
P16, last para of 3.1 << The initial Data Sequ= ence Number (IDSN) is generated as a hash from
   the Key= , in the same way as the token, i.e.  IDSN-A =3D Hash(Key-A) and
&n= bsp;  IDSN-B =3D Hash(Key-B).>>
The Initial Data Sequenc= e Number (IDSN) is generated as a hash from
   the Key, i= .e.  IDSN-A =3D Hash(Key-A) and
   IDSN-B =3D Hash(K= ey-B).            &n= bsp;  
 
Middle p17 – the ‘this’ bon= anza made it hard to understand. How about (includes a couple of other chan= ges):-
The MP_JOIN option includes an "Address ID".  This= is an identifier
   that only has significance within a = single connection, where it
   identifies the original so= urce address of the packet, even if the IP header has been changed in trans= it by a middlebox.  This allows
   address removal (= Section 3.4.2) without needing to know what the source address at
 =   the receiver is, and thus allows address removal through NATs. = It also allows correlation between new subflow
   setup a= ttempts and address signaling (Section 3.4.1), to prevent
  &n= bsp;setting up duplicate subflows on the same path.
 
P17 last p= ara<< The MP_JOIN option on SYNs >> add ‘and SYN_ACKsR= 17;

[Alan] “Packets with the SYN fl= ag set”

P18 first para under Fig 5 << Although cr= yptographic calculations are required in the
   SYN/ACK, = it is felt that the 32 bit token gives >>
Although calculating a M= AC requires cryptographic operations, it is believed that the 32 bit token = in the MP_JOIN SYN gives
 
P18 2nd para, sentence 2 “This= is to allow..” takes some working out. Maybe: “This allow Host= B to use random data sent by Host A in the SYN, as part of the MAC algorit= hm; and similarly Host A to use random data sent by Host B in the SYN/ACK.<= br> 
Last sentence of this para can be shortened:
Due
 =   to option space limitations, the MAC included in the SYN/ACK is=
   truncated to the leftmost 64 bits, but this is accept= able since
an attacker has only one chance to guess the MAC correctly.<= br> 
Next para – “and this is” -> “as= 221;
 
Same para “MUST trigger an ACK in response” &= #8211; maybe you could stress that this is an ordinary data ACK
 P19 “The message in each case “ -> The message for the MAC= algorithm in each case
 
S3.2, the Random Number =3D=3D Nonce = in S2. Point out, or change one of them.
 
S3.3 para 2 & 3 c= ould be re-phrased slightly:-
   During normal MPTCP oper= ation, the Data Sequence Mapping defines how the sequence space on the subf= low maps to
   the connection level; and the Data ACK ack= nowledges receipt of
   data at the connection level. &nb= sp;These functions are described in more
   detail in the= following two subsections.
The Data Sequence Mapping and the Data ACK a= re signalled in the Data Sequence Signal (DSS). Either or both can be signa= lled in one DSS, dependent on the flags set.
 
P23 << The = data sequence mapping also contains a checksum of the data that
 &n= bsp; this mapping covers.  >> - to check I understand, this= means you need all the data before you start to transmit it, so you can ca= lculate the checksum?
 
P24 first para under fig 10, you could d= elete “. Furthermore,” and put the rest of the sentence in (..)=
 
Last para 3.3.1 “data-level length field to “
= Data-level Length field of the DSS option to
 
P26 para 3, ̶= 0;that it is used” can be deleted
 
P26 para 4 << An= MPTCP sender MUST only free data from the send buffer when it has
 = ;  been acknowledged by both a Data ACK received on any subflow a= nd at
   the subflow level by any subflows the data was s= ent on.  >>
could be clearer
An MPTCP sender MUST NOT free= data from the send buffer until it has
   been acknowled= ged by both a Data ACK received on any subflow and at
   = the subflow level by all subflows the data was sent on.  
[note, 2n= d ‘any’ -> ‘all’]
 
Same para restran= smited / re-transmitted
 
P27 para 4 < and length 11> and = Data-level Length of 11
 
Same thing in next para
 
P= 27 penult para – I think ‘Data Sequence Signal’ would be = more accurate here than ‘Mapping’. Also Length -> Data-level= Length
 
P27 last line, think you mean ‘DATA_FIN’ a= nd not FIN
 
3.3.4 para 4 << When deciding to accept packe= ts at subflow level, normal TCP uses the
   sequence numb= er in the packet and checks it against the allowed
   rec= eive window.  >>
When deciding to accept packets at the subfl= ow level, normal TCP checks the
   sequence number in the= packet against the allowed
   receive window.  
=  
P28 last line
Could you spell out what rcv_next is [or at leas= t reference B2.2.2, where it’s called RCV.NXT]
 
3.3.4 las= t para ‘maximum bandwidth-delay product of any of the paths’ wo= nder if ‘any one of the’ would be clearer?
 
3.3.6 p= ara 1 ‘the best behaviour’ -> ‘sensible behaviour̵= 7;
 
P30 last line active ACK -> actively ACK
 
3.= 3.6 last line - < For example, subflows that perform highly asymmetrical= ly may be mis-
   diagnosed as underperforming.>
Fo= r example, a highly asymmetrically path may be mis-
   di= agnosed as underperforming.
 
P33 para 1 ‘The signal appli= es to a single direction:
   the sender of this option, h= owever, may >>
The signal applies to a single direction – an= d so the sender of this option may
 
Next para < This
&nb= sp;  applies the given setting of B to all subflows that use the = address
   identified by the given Address ID.  >=
do you think it’s worth saying that this means all subflows in th= is connection?
 
S3.4 para 2 < This design makes use of two m= ethods of sharing such information,
   used simultaneousl= y.  >
This design makes use of two methods of sharing such infor= mation; both can be used on a connection.
 
3.4.1 understake -&g= t; undertake
 
P35 para above Fig 12 as does the ephemeral port = at the client – explain.
 
Same para, “signalling su= bflow’ – should this  be ‘initial subflow’? 
Fig 12 caption – can delete ‘(shown for IPv4)’= – as pic includes v6
 
P36 para 2 < This would be to e= nsure that this> This would ensure that
 
3.4.1 last para &l= t; an MPTCP
   implementation MUST NOT treat duplicate AC= Ks with any MPTCP option
   apart from DSS as indications= of congestion >>
“NOT … any .. apart from” is a= mbiguous.
 
P38 last bullet < The number of
  &n= bsp;   retransmissions should be limited >
SHOULD?
=  
S3.6 – end of sentence 1 – add ‘for instance th= ey aren’t blocked or mangled by a middlebox
 
3.6 para 4 = < with the length value of 0 > with the Data-level Length set to 0  
P40 para 1 I couldn’t parse this:-
(Note that these ru= les do not apply if an
   infinite mapping is included fr= om the start - in which case, each end
   will send DSS o= ptions declaring the infinite mapping.)
 
Fig 15 Length may be 8= & DSN may be 4 octets
 
3.6 penult para “fallback mod= e” – what is this?
 
3.8.3 para 2 < a host should= fall back> SHOULD
 
S4, Duplicate ack. “To avoid any&#= 8221; -> To limit
 
S4, Receive window penult line <also n= eed to> also needs to
 
S5, big para on p46 < used on subf= low setup that verify that > used on subflow setup, in order to verify t= hat
 
P47 line 1, “will allow” -> allows
&nbs= p;
S6 para 1 &   P54 para 2
accomodate -> accommodat= e
 
S6 para 2 < Most middleboxes
   should = just forward packets with new options unchanged>
Middleboxes should j= ust forward packets with new options unchanged  
[I think – (= all) middleboxes aren’t supposed to change options; most don’t]=
 
P49 Traffic normalisers – should you also mention about= re-transmitting on the same subflow?
 
9.2 – maybe worth = adding rfc editor note that hoping this will become rfc at the same time 
P54 para 2 <(10B)> 10 bytes
 
Appendix C –= ; point out that [DFIN] is shorthand for [DATA_FIN] – (I think!)
=  
That’s it, phew.

 
 
From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@iet= f.org] On Behalf Of Yoshifumi Nishida
Sent: 18 April 2012 07:04
T= o: draft-ietf-mp= tcp-multiaddressed@tools.ietf.org; multipathtcp
Subject: Re: [multip= athtcp] comments on draft-ietf-mptcp-multiaddressed-07
 
Hi auth= ors,
 
Sorry. I would like to add one more thing.
 
= This draft requires to create new registries for subtypes of mptcp option a= nd cryptographic algorithms handshake in MP_CAPABLE.  
For this, yo= u will need to add the description of the policy used for managing these re= gistries in the IANA considerations section. Please check the section 4 of = RFC5226 to see the available choices (Section 4.1) and update the texts bas= ed on the guideline (Section 4.2).
 
Thanks,
--
Yoshifumi = Nishida
 
 
 
On Mon, Apr 16, 2012 at 11:53 PM, = Yoshifumi Nishida <nishida@sfc.wide.a= d.jp> wrote:
Hello,
 
Sorry for the long delay.
We = believe it's good time to proceed to submit draft-ietf-mptcp-multiaddressed= to IESG.
 
Here's my comments on the draft to prepare a write-u= p for the draft.
Please check and update if you agree with them.
&nbs= p;
Thanks,
--
Yoshifumi
 
 
Page 13:
 &= nbsp;3.1. Connection Initiation
 
    -> =  In my understanding, the key MUST be unique for each mptcp connection= .
         If so, I think = we had better articulate it here.
 
Page 17:
  &nbs= p;A host MUST store the Address IDs associated with all established subflow= s.
 
   -> Does this mean both local Address I= Ds and remote Address IDs advertized from the receiver?
  &nbs= p;    It might be better to clarify this.
 
= Page 18:
   therefore receipt of this packet MUST trigger= an ACK in response
 
   -> Since this is MUST= , I think Figure 8 needs to include this ACK in the sequence.
 
=  
   the packet MUST be retransmitted if this ACK is= not received.
 
   -> In case of MP_CAPABLE, = the third packet is not retransmitted.
     &nb= sp; But, in case of MP_JOIN, it's retransmitted. Readers might want to= know the rationale about this.
  
Page 27:
 
&n= bsp;  Essentially, a host MUST NOT FIN all functioning subflows u= nless it is safe to do so
   
    = -> MUST NOT close?
 
Page 28:
 
   = Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to clean up= state even if the subflow is failed.
   -> I'm not ve= ry sure which situations can be addressed by this..
   ..=
   Note that a host may also send a FIN on an individual= subflow to shut it down, but this impact is limited to the subflow in ques= tion.
 
   -> Sorry. I couldn't understand thi= s sentences well..
 
Page 30:
 
   &nb= sp;The sender also remembers the receive windows advertised by each subflow= .
   
    -> Don't we need to p= ut SHOULD or MUST here?
 
    The send buffe= r must be, at the minimum, as big as the receive buffer
 
 =    -> MUST?
 
    When doi= ng this, a host must still retransmit the original data on the original sub= flow,
 
    -> MUST?
 
Page 37= :
 
   if a response is received, the path is not= removed.
 
   a subflow that is still functionin= g MUST be closed with a FIN exchange
 
    -= > Aren't these sentences inconsistent?
 
Page 40:
    fallback to regular TCP can become necessary at any poi= nt during a connection if a non-MPTCP-aware middlebox changes the data stre= am.
 
    -> The paragraph below this sug= gest when multiple subflows are in use, the affected subflow must be termin= ated, but not suggesting fallback.
      &= nbsp;  So, fallback seems not to be necessary?
 
 = ;  Therefore, it is not possible to recover the subflow, and the = affected subflow must be immediately closed with an RST.
 
 = ;   -> MUST?
 
   Failed data w= ill not be DATA_ACKed.
 
    -> MUST NOT = be DATA_ACKed?
 
 
Page 47:
 
  &nb= sp;If this is dropped, MPTCP SHOULD fall back to regular TCP.
 
=     -> may be MUST? since we cannot continue to use = MPTCP .
 
   If packets with the MP_JOIN option = are dropped, the paths will simply not be used.
 
  &n= bsp; -> MUST NOT be used?
 
 
Page 51:
 = ;
   Should use RFC6234 instead of RFC4634
 
P= age 52:
 
   Should use RFC5681 instead of RFC258= 1
   Should use draft-ietf-tcpm-secury-03 instead of -02<= br>   Should use draft-ietf-mptcp-api-04 or 05? instead of -= 03
 
 
There are some typos in the doc. Please update th= em by some tools.
 
 

 

= --_000_9510D26531EF184D9017DF24659BB87F33C4583CCBEMV65UKRDdoma_-- From philip.eardley@bt.com Tue May 29 01:35:11 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6889D21F8613 for ; Tue, 29 May 2012 01:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a76ki7X1epLJ for ; Tue, 29 May 2012 01:34:59 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA6321F85CF for ; Tue, 29 May 2012 01:34:58 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.264.0; Tue, 29 May 2012 09:34:57 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.15]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 29 May 2012 09:34:57 +0100 From: To: , Date: Tue, 29 May 2012 09:34:56 +0100 Thread-Topic: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 Thread-Index: Ac0jzbqibAFIshA0T/uPM83vXnJ6ygWkeBYaAMUj+HA= Message-ID: <9510D26531EF184D9017DF24659BB87F33C4583D02@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F33520217BD@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F33C4583D02EMV65UKRDdoma_" MIME-Version: 1.0 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 08:35:11 -0000 --_000_9510D26531EF184D9017DF24659BB87F33C4583D02EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, It's probably worth pointing out explicitly that Section 8 IANA Considerati= ons has been updated. - With our option kind assignment (30) - RFCs will be used for future assignments of MPTCP option subtype= values & flags for crypto algos Alan, In the crypto algos part of S8 << Note that the length of this field is not fixed; it is a definition of the meaning of each bit in this field (i.e. 0x2, 0x4, 0x8, 0x10, etc). Future specifications may encroach on the non-cryptographic flags at the other end of this field so the number of flags available for cryptographic algorithm use may change.>> I don't understand the "encroaching". S3.1 says the flag octet leftmost bit= is for Checksum required and "The remaining bits are used for crypto algor= ithm negotiation." Thanks phil From: Alan Ford [mailto:alanford@cisco.com] Sent: 25 May 2012 11:18 To: Eardley,PL,Philip,DUB8 R; nishida@sfc.wide.ad.jp Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 Hi Phil, Many thanks for you comments. Anything I have not directly commented on bel= ow was straightforwardly addressed in -08. If there is anything you feel wa= sn't sufficiently addressed, please shout. Regards, Alan On 26/04/2012 17:57, "philip.eardley@bt.com" wrote: Hi Alan, Costin, Mark, Olivier, Here are some comments. Sorry I finally got through it. The first lot are either significant or something worth thinking about. The= second lot are just typos & re-phrasings - feel free to ignore if you don= 't like the suggestion Thanks! phil -- Think it would be good to have a sub-section in S2 on Fast Close Also might be worth adding one on MP_FAIL ? [Alan] I decided against doing this. S2 is meant to be a light overview of = the protocol; it seems unnecessary and potentially confusing to burden read= ers with these little-used features at this stage. S3.1 penultimate para, << If this option is not present, the connection should fall back to regular TCP , as documented in Section 3.6.>> SHOULD? also S3.6 para 1 is about this - but it doesn't have any capitalisation, wh= ich presumably it should I thought that S3.2 could be clearer. Basically there are a lot of minor th= ings (see below) that add up to making it quite hard work. Fig 8 - I think the first msg (SYN + MP_CAPABLE) should have (Key-A) S3.3.0 - do you say somewhere what to do if the checksum is present but it = wasn't negotiated in MP-CAPABLE, or it isnt present but wasn't negotiated? [Alan] We do now: "If a checksum is present, but its use had not been negot= iated in the MP_CAPABLE handshake, it SHOULD be ignored. If a checksum is n= ot present when its use has been negotiated, the receiver SHOULD close the = subflow with a RST as it is considered broken." P36 para 4 < If the Address ID is not in use on a live subflow, but is stored by the receiver, a new ADD_ADDR SHOULD take precedence and replace the stored address.> I found this sentence quite hard to parse. If I understand it right, this i= s advertising a new address by over-writing an old address - using the same= Address ID. Rather than removing the old address and adding a new one with= a different Address ID. Sounds dodgy? why doing this? [Alan] You understood it right, however you're right is has a whiff of dodg= yness to it. So I've removed it - now a host that wants to replace an Addre= ss ID MUST remove it first. 3.5 - Fast Close sends the Receiver's Key in the clear. Does this open an a= ttack? [Alan] Not any new risks. Once it's sent on Fast Close, the connection is d= ead, so no further signalling with that key would have any effect. And yes,= anyone who had seen the key on the initial handshake could Fast Close the = connection. But they can do anything anyway if they've seen the key on the = initial handshake. In Fast Close, usual TCP sequence number verification is= required to ensure the signal is in-window (so an attacker would need to k= now both the key of the receiver and the sequence space of the sender). There might be value in e.g. hashing the key with the sender's DSN for slig= htly more protection; I'm not sure if that adds anything. In fact, it proba= bly goes against the point of Fast Close that the sender actively DOES NOT = CARE whether its last packets actually get to the end host. anyway, it contradicts S3.1 & S5 which say it's only sent in the clear once= , ie on MP-CAPABLE [Alan] Fixed this. 3.6 - I had it in my brain that fallback meant 'fallback from mptcp to tcp'= . Here it means '.. or close a problematic subflow'. I'm not absolutely sur= e it's used consistently throughout the doc, but it's probably worth adding= an intro para to 3.6 that says there are n ways of coping with some proble= m, close the subflow, close the connection (?), shift to tcp [Alan] You're right, it has evolved from its original meaning. Now re-worde= d: "Sometimes, middleboxes will exist on a path that could prevent the oper= ation of MPTCP. MPTCP has been designed in order to cope with many middleb= ox modifications (see Section 6), but there are still some cases where a su= bflow could fail to operate within the MPTCP requirements. These cases are= notably: the loss of TCP options on a path; and the modification of payloa= d data. If such an event occurs, it is necessary to "fall back" to the pre= vious, safe operation. This may either be falling back to regular TCP, or = removing a problematic subflow." 3.6 para 1 - needs to be a SHOULD somewhere in here 3.6 para 1 COMPARE 3.8.3 para 2 - 3.6 suggests give up on mptcp after one M= P_CAPABLE fails (& also 6 & 3.1); 3.8 suggests after several. Which is righ= t? [Alan] It's up to the implementation. The heuristics are our initial though= ts on this; implementations optimise this. The heuristics now say "one or m= ore" rather than "several". S4 Receive window last sentence, "so a host must" - SHOULD? Or maybe 'needs= to'? Also, this point doesn't appear in S3.3.4 [Alan] "needs to". Re S3.3.4, I think it is implied - there is talk there a= bout normal subflow processing. P48 penul para < If some subflow-level space is left unmapped, however, the subflow is treated as broken and is closed, as discussed in Section 3.3. > do you mean S3.6? I couldn't see anything in s3.3 [but it's a big section, so a more accurate ref would be useful - same comm= ent on p10 just above the SS pic & p40 para 3] [Alan] The reference to S3.6 there are more a general pointer to procedure = than a specific instruction - I've clarified this. P49 PEPs < MPTCP will therefore fall back to single-path TCP (see Section 3.6).> I read S3.6 to say that you close the subflow (rather than fall back to tcp= ) [Alan] S3.6 is intended to cover both, and hopefully this new intro should = make this clearer. S8 - can be updated with Option kind number 30 ! also Wes's comment about t= he subtypes [ie invent a policy for managing them] [Alan] It's now been rewritten in RFC5226 style. Appendix C - should the 'snd DATA_ACK' arrows from M_ESTAB & from M_FIN WAI= T-1 be snd DATA_ACK[DFIN] ? -- Minor suggestions etc - no need to ack these individually [but shout if I r= eveal some misunderstanding!] Throughout doc: Be consistent on 'DATA_ACK' & 'DATA_FIN' - many times appear without '_' [I= guess I prefer MP_DATA_ACK but that may be too much for your taste!] [Alan] Remember those two are flags and not specific options, so it's defin= itely inappropriate to call them MP_... But they've all grown an underscore= for consistency. I think it would be more logical if all the subtype names started MP_ [ie a= lso DSS, ADD_ADDR, REMOVE_ADDR] [again, maybe too much for your taste] [Alan] Given that these are symbols within a MPTCP-specific registry, I onl= y see MP_ as taking up unnecessary space. Sorry ;) The bare 'ID' appears quite often- think you should use 'Address ID' throug= hout [Alan] I found three instances, let me know if I've missed any. -- S1.1 <> The congestion control algorithm defined in [5] achieves this. S1.3 a reference to S4 might be nice S1.4 bullet 2, "where a TCP connection is established" - should be MPTCP co= nnection 2.1 & 2.2 - would it be more logical if 'ACK MP_CAPABLE' & 'ACK MP_JOIN' di= dn't have 'ACK' since there's no special ACK subtype? But maybe this makes = it harder to understand what's happening? 2.4 para 2 << The "Data Sequence Signal" option which carries this "Data = Sequence Mapping", which consists of the subflow sequence number, data>> The "Data Sequence Signal" option carries the "Data Sequence Mapping". The Data Sequence Mapping consists of the subflow sequence num= ber, data 2.7 bullet 1 "MP-ADD-ADDR" should be ADD_ADDR (unless you change subtype na= mes to all start MP_ !) 3.1 para 4, last sentence (The subflow handshake mechanism...) is quite har= d to parse 3.1, last para p14 << The leftmost bit - labeled C - indicates "Checksum required", and SHOULD be set to 1 unless specifically overridden (for example, if the system administrator has decided that checksums are not required - see Section 3.3 for more discussion)>> The leftmost bit - labelled C - SHOULD be set to 1 to indicate "Checksum re= quired", unless the system administrator has decided that checksums are not required - see Section 3.3 for more discussion) also, S3.3 doesn't discuss why someone might decide to use checksums, or de= cide not to. Might be nice to add a hint about this somewhere also, when there are multiple crypo algos, do we want to point out that the= same one MUST be used for everything (generating token, isdn etc)? maybe t= his is obvious and anyway would be better in any subsequent doc about alter= native crypto [Alan] That's a good point, however I think it is best to leave it to any n= ew documents to decide whether they also want to tie a new crypto algorithm= with tokens/IDSN generation. p15 - I thought the first sentence ["These bits.." was redundant p15 para 2 << The initiator creates a proposal setting a bit for each algorithm >> The initiator sets a bit for each algorithm P16, last para of 3.1 << The initial Data Sequence Number (IDSN) is generat= ed as a hash from the Key, in the same way as the token, i.e. IDSN-A =3D Hash(Key-A) and IDSN-B =3D Hash(Key-B).>> The Initial Data Sequence Number (IDSN) is generated as a hash from the Key, i.e. IDSN-A =3D Hash(Key-A) and IDSN-B =3D Hash(Key-B). Middle p17 - the 'this' bonanza made it hard to understand. How about (incl= udes a couple of other changes):- The MP_JOIN option includes an "Address ID". This is an identifier that only has significance within a single connection, where it identifies the original source address of the packet, even if the IP hea= der has been changed in transit by a middlebox. This allows address removal (Section 3.4.2) without needing to know what the source = address at the receiver is, and thus allows address removal through NATs. It also a= llows correlation between new subflow setup attempts and address signaling (Section 3.4.1), to prevent setting up duplicate subflows on the same path. P17 last para<< The MP_JOIN option on SYNs >> add 'and SYN_ACKs' [Alan] "Packets with the SYN flag set" P18 first para under Fig 5 << Although cryptographic calculations are requi= red in the SYN/ACK, it is felt that the 32 bit token gives >> Although calculating a MAC requires cryptographic operations, it is believe= d that the 32 bit token in the MP_JOIN SYN gives P18 2nd para, sentence 2 "This is to allow.." takes some working out. Maybe= : "This allow Host B to use random data sent by Host A in the SYN, as part = of the MAC algorithm; and similarly Host A to use random data sent by Host = B in the SYN/ACK. Last sentence of this para can be shortened: Due to option space limitations, the MAC included in the SYN/ACK is truncated to the leftmost 64 bits, but this is acceptable since an attacker has only one chance to guess the MAC correctly. Next para - "and this is" -> "as" Same para "MUST trigger an ACK in response" - maybe you could stress that t= his is an ordinary data ACK P19 "The message in each case " -> The message for the MAC algorithm in eac= h case S3.2, the Random Number =3D=3D Nonce in S2. Point out, or change one of the= m. S3.3 para 2 & 3 could be re-phrased slightly:- During normal MPTCP operation, the Data Sequence Mapping defines how the= sequence space on the subflow maps to the connection level; and the Data ACK acknowledges receipt of data at the connection level. These functions are described in more detail in the following two subsections. The Data Sequence Mapping and the Data ACK are signalled in the Data Sequen= ce Signal (DSS). Either or both can be signalled in one DSS, dependent on t= he flags set. P23 << The data sequence mapping also contains a checksum of the data that this mapping covers. >> - to check I understand, this means you need al= l the data before you start to transmit it, so you can calculate the checks= um? P24 first para under fig 10, you could delete ". Furthermore," and put the = rest of the sentence in (..) Last para 3.3.1 "data-level length field to " Data-level Length field of the DSS option to P26 para 3, "that it is used" can be deleted P26 para 4 << An MPTCP sender MUST only free data from the send buffer when= it has been acknowledged by both a Data ACK received on any subflow and at the subflow level by any subflows the data was sent on. >> could be clearer An MPTCP sender MUST NOT free data from the send buffer until it has been acknowledged by both a Data ACK received on any subflow and at the subflow level by all subflows the data was sent on. [note, 2nd 'any' -> 'all'] Same para restransmited / re-transmitted P27 para 4 < and length 11> and Data-level Length of 11 Same thing in next para P27 penult para - I think 'Data Sequence Signal' would be more accurate her= e than 'Mapping'. Also Length -> Data-level Length P27 last line, think you mean 'DATA_FIN' and not FIN 3.3.4 para 4 << When deciding to accept packets at subflow level, normal TC= P uses the sequence number in the packet and checks it against the allowed receive window. >> When deciding to accept packets at the subflow level, normal TCP checks the sequence number in the packet against the allowed receive window. P28 last line Could you spell out what rcv_next is [or at least reference B2.2.2, where i= t's called RCV.NXT] 3.3.4 last para 'maximum bandwidth-delay product of any of the paths' wonde= r if 'any one of the' would be clearer? 3.3.6 para 1 'the best behaviour' -> 'sensible behaviour' P30 last line active ACK -> actively ACK 3.3.6 last line - < For example, subflows that perform highly asymmetricall= y may be mis- diagnosed as underperforming.> For example, a highly asymmetrically path may be mis- diagnosed as underperforming. P33 para 1 'The signal applies to a single direction: the sender of this option, however, may >> The signal applies to a single direction - and so the sender of this option= may Next para < This applies the given setting of B to all subflows that use the address identified by the given Address ID. > do you think it's worth saying that this means all subflows in this connect= ion? S3.4 para 2 < This design makes use of two methods of sharing such informat= ion, used simultaneously. > This design makes use of two methods of sharing such information; both can = be used on a connection. 3.4.1 understake -> undertake P35 para above Fig 12 as does the ephemeral port at the client - explain. Same para, "signalling subflow' - should this be 'initial subflow'? Fig 12 caption - can delete '(shown for IPv4)' - as pic includes v6 P36 para 2 < This would be to ensure that this> This would ensure that 3.4.1 last para < an MPTCP implementation MUST NOT treat duplicate ACKs with any MPTCP option apart from DSS as indications of congestion >> "NOT ... any .. apart from" is ambiguous. P38 last bullet < The number of retransmissions should be limited > SHOULD? S3.6 - end of sentence 1 - add 'for instance they aren't blocked or mangled= by a middlebox 3.6 para 4 < with the length value of 0 > with the Data-level Length set to= 0 P40 para 1 I couldn't parse this:- (Note that these rules do not apply if an infinite mapping is included from the start - in which case, each end will send DSS options declaring the infinite mapping.) Fig 15 Length may be 8 & DSN may be 4 octets 3.6 penult para "fallback mode" - what is this? 3.8.3 para 2 < a host should fall back> SHOULD S4, Duplicate ack. "To avoid any" -> To limit S4, Receive window penult line also needs to S5, big para on p46 < used on subflow setup that verify that > used on subf= low setup, in order to verify that P47 line 1, "will allow" -> allows S6 para 1 & P54 para 2 accomodate -> accommodate S6 para 2 < Most middleboxes should just forward packets with new options unchanged> Middleboxes should just forward packets with new options unchanged [I think - (all) middleboxes aren't supposed to change options; most don't] P49 Traffic normalisers - should you also mention about re-transmitting on = the same subflow? 9.2 - maybe worth adding rfc editor note that hoping this will become rfc a= t the same time P54 para 2 <(10B)> 10 bytes Appendix C - point out that [DFIN] is shorthand for [DATA_FIN] - (I think!) That's it, phew. From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Yoshifumi Nishida Sent: 18 April 2012 07:04 To: draft-ietf-mptcp-multiaddressed@tools.ietf.org; multipathtcp Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 Hi authors, Sorry. I would like to add one more thing. This draft requires to create new registries for subtypes of mptcp option a= nd cryptographic algorithms handshake in MP_CAPABLE. For this, you will need to add the description of the policy used for manag= ing these registries in the IANA considerations section. Please check the s= ection 4 of RFC5226 to see the available choices (Section 4.1) and update t= he texts based on the guideline (Section 4.2). Thanks, -- Yoshifumi Nishida On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida wrote: Hello, Sorry for the long delay. We believe it's good time to proceed to submit draft-ietf-mptcp-multiaddres= sed to IESG. Here's my comments on the draft to prepare a write-up for the draft. Please check and update if you agree with them. Thanks, -- Yoshifumi Page 13: 3.1. Connection Initiation -> In my understanding, the key MUST be unique for each mptcp connecti= on. If so, I think we had better articulate it here. Page 17: A host MUST store the Address IDs associated with all established subflo= ws. -> Does this mean both local Address IDs and remote Address IDs advertiz= ed from the receiver? It might be better to clarify this. Page 18: therefore receipt of this packet MUST trigger an ACK in response -> Since this is MUST, I think Figure 8 needs to include this ACK in the= sequence. the packet MUST be retransmitted if this ACK is not received. -> In case of MP_CAPABLE, the third packet is not retransmitted. But, in case of MP_JOIN, it's retransmitted. Readers might want to k= now the rationale about this. Page 27: Essentially, a host MUST NOT FIN all functioning subflows unless it is s= afe to do so -> MUST NOT close? Page 28: Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to clean= up state even if the subflow is failed. -> I'm not very sure which situations can be addressed by this.. .. Note that a host may also send a FIN on an individual subflow to shut it= down, but this impact is limited to the subflow in question. -> Sorry. I couldn't understand this sentences well.. Page 30: The sender also remembers the receive windows advertised by each subflo= w. -> Don't we need to put SHOULD or MUST here? The send buffer must be, at the minimum, as big as the receive buffer -> MUST? When doing this, a host must still retransmit the original data on the = original subflow, -> MUST? Page 37: if a response is received, the path is not removed. a subflow that is still functioning MUST be closed with a FIN exchange -> Aren't these sentences inconsistent? Page 40: fallback to regular TCP can become necessary at any point during a conne= ction if a non-MPTCP-aware middlebox changes the data stream. -> The paragraph below this suggest when multiple subflows are in use, = the affected subflow must be terminated, but not suggesting fallback. So, fallback seems not to be necessary? Therefore, it is not possible to recover the subflow, and the affected s= ubflow must be immediately closed with an RST. -> MUST? Failed data will not be DATA_ACKed. -> MUST NOT be DATA_ACKed? Page 47: If this is dropped, MPTCP SHOULD fall back to regular TCP. -> may be MUST? since we cannot continue to use MPTCP . If packets with the MP_JOIN option are dropped, the paths will simply no= t be used. -> MUST NOT be used? Page 51: Should use RFC6234 instead of RFC4634 Page 52: Should use RFC5681 instead of RFC2581 Should use draft-ietf-tcpm-secury-03 instead of -02 Should use draft-ietf-mptcp-api-04 or 05? instead of -03 There are some typos in the doc. Please update them by some tools. --_000_9510D26531EF184D9017DF24659BB87F33C4583D02EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-= 07

All,

It’s probably worth pointing out = explicitly that Section 8 IANA Considerations has been updated. =

-    &n= bsp;     With our= option kind assignment (30)

-          = RFCs will be used for future assignments of = MPTCP option subtype values & flags for crypto algos =

 

Alan,

In the crypto algos part of S8

<=
span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif";color:#1F497=
D'><<   Note that the length of this field is not fi=
xed; it is a definition

   of the meaning of= each bit in this field (i.e. 0x2, 0x4, 0x8, 0x10,

   flags at the other end o= f this field so the number of flags available

&nb= sp;  for cryptographic algorithm use may change.>>

I don’t understand the “encroaching”. S3.1 s=
ays the flag octet leftmost bit is for Checksum required and “The rem=
aining bits are used for crypto algorithm negotiation.”
 
Thanks
phil
 

 

From: Alan Ford [mailto:alanford@cisco.com] Sent: 25 May 2012 11:18
To: Eardley,PL,Philip,DUB8 R; nis= hida@sfc.wide.ad.jp
Cc: multipathtcp@ietf.org
Subject: = Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07

 

Hi Phil,

Many thanks for you co= mments. Anything I have not directly commented on below was straightforward= ly addressed in –08. If there is anything you feel wasn’t suffi= ciently addressed, please shout.

Regards,
Alan

On 26/04/20= 12 17:57, "philip.eardley@bt.com= " <philip.eardley@bt.com> = wrote:

Hi Alan, Costin, Mark, Olivier, 
Here are some comments. Sorry I finally got through it.
The = first lot are either significant or something worth thinking about. The &nb= sp;second lot are just typos & re-phrasings – feel free to ignore= if you don’t like the suggestion
 
Thanks!
phil
&nb= sp;
--
 
Think it would be good to have a sub-section in S2 o= n Fast Close
 
Also might be worth adding one on MP_FAIL ?
[Alan] I decided against doing this. S2 is mea= nt to be a light overview of the protocol; it seems unnecessary and potenti= ally confusing to burden readers with these little-used features at this st= age.

S3.1 penultimate para, << If this
  &= nbsp;option is not present, the connection should fall back to regular
&= nbsp;  TCP , as documented in Section 3.6.>>
SHOULD?
= also S3.6 para 1 is about this – but it doesn’t have any capita= lisation, which presumably it should
 
I thought that S3.2 could= be clearer. Basically there are a lot of minor things (see below) that add= up to making it quite hard work.
 
Fig 8 – I think the fi= rst msg (SYN + MP_CAPABLE) should have (Key-A)
 
S3.3.0 – = do you say somewhere what to do if the checksum is present but it wasn̵= 7;t negotiated in MP-CAPABLE, or it isnt present but wasn’t negotiate= d?
 
[Alan] We do now: “If a ch= ecksum is present, but its use had not been negotiated in the MP_CAPABLE ha= ndshake, it SHOULD be ignored. If a checksum is not present when its use ha= s been negotiated, the receiver SHOULD close the subflow with a RST as it i= s considered broken.”

P36 para 4 < If the Address ID= is not in use on a
   live subflow, but is stored by the= receiver, a new ADD_ADDR SHOULD
   take precedence and r= eplace the stored address.>
I found this sentence quite hard to parse= . If I understand it right, this is advertising a new address by over-writi= ng an old address - using the same Address ID. Rather than removing the old= address and adding a new one with a different Address ID. Sounds dodgy? wh= y doing this?

[Alan] You understood it ri= ght, however you’re right is has a whiff of dodgyness to it. So IR= 17;ve removed it – now a host that wants to replace an Address ID MUS= T remove it first.

3.5 – Fast Close sends the Receiver&= #8217;s Key in the clear. Does this open an attack?  

[Alan] Not any new risks. Once it’s sent on Fast Cl= ose, the connection is dead, so no further signalling with that key would h= ave any effect. And yes, anyone who had seen the key on the initial handsha= ke could Fast Close the connection. But they can do anything anyway if they= ’ve seen the key on the initial handshake. In Fast Close, usual TCP s= equence number verification is required to ensure the signal is in-window (= so an attacker would need to know both the key of the receiver and the sequ= ence space of the sender).

There might be value in e.g. hashing the = key with the sender’s DSN for slightly more protection; I’m not= sure if that adds anything. In fact, it probably goes against the point of= Fast Close that the sender actively DOES NOT CARE whether its last packets= actually get to the end host.

anyway, it contradicts S3.1 &a= mp; S5 which say it’s only sent in the clear once, ie on MP-CAPABLE
[Alan] Fixed this.

3.6 ̵= 1; I had it in my brain that fallback meant ‘fallback from mptcp to t= cp’. Here it means ‘.. or close a problematic subflow’. I= ’m not absolutely sure it’s used consistently throughout the do= c, but it’s probably worth adding an intro para to 3.6 that says ther= e are n ways of coping with some problem, close the subflow, close the conn= ection (?), shift to tcp

[Alan] You’= ;re right, it has evolved from its original meaning. Now re-worded: “= Sometimes, middleboxes will exist on a path that could prevent the operatio= n of MPTCP.  MPTCP has been designed in order to cope with many middle= box modifications (see Section 6), but there are still some cases where a s= ubflow could fail to operate within the MPTCP requirements.  These cas= es are notably: the loss of TCP options on a path; and the modification of = payload data.  If such an event occurs, it is necessary to "fall = back" to the previous, safe operation.  This may either be fallin= g back to regular TCP, or removing a problematic subflow.”
=
3.6 para 1 – needs to be a SHOULD somewhere in here
 
= 3.6 para 1 COMPARE 3.8.3 para 2 – 3.6 suggests give up on mptcp after= one MP_CAPABLE fails (& also 6 & 3.1); 3.8 suggests after several.= Which is right?

[Alan] It’s up to= the implementation. The heuristics are our initial thoughts on this; imple= mentations optimise this. The heuristics = now say “one or more” rather than “several”.=

S4 Receive window last sentence, “so a host must” R= 11; SHOULD? Or maybe ‘needs to’?  Also, this point doesn&#= 8217;t appear in S3.3.4

[Alan] “nee= ds to”. Re S3.3.4, I think it is implied – there is talk there = about normal subflow processing.

P48 penul para < If some = subflow-level space is left unmapped,
   however, the sub= flow is treated as broken and is closed, as discussed
   = in Section 3.3.  >
do you mean S3.6? I couldn’t see anythi= ng in s3.3
 
[but it’s a big section, so a more accurate = ref would be useful – same comment on p10 just above the SS pic &= p40 para 3]

[Alan] The reference to S3.6= there are more a general pointer to procedure than a specific instruction = – I’ve clarified this.

P49 PEPs < MPTCP will      therefore fall back to single-path TC= P (see Section 3.6).>
I read S3.6 to say that you close the subflow (= rather than fall back to tcp)

[Alan] S3.6= is intended to cover both, and hopefully this new intro should make this c= learer.

S8 – can be updated with Option kind number 30 = ! also Wes’s comment about the subtypes [ie invent a policy for manag= ing them]

[Alan] It’s now been rew= ritten in RFC5226 style.

Appendix C – should the ‘= ;snd DATA_ACK’ arrows from M_ESTAB & from M_FIN WAIT-1  be s= nd DATA_ACK[DFIN] ?  
 
--
 
Minor suggestions e= tc – no need to ack these individually [but shout if I reveal some mi= sunderstanding!]
 
Throughout doc:
 
Be consistent o= n ‘DATA_ACK’ & ‘DATA_FIN’ – many times ap= pear without ‘_’ [I guess I prefer MP_DATA_ACK but that may be = too much for your taste!]

[Alan] Remember= those two are flags and not specific options, so it’s definitely ina= ppropriate to call them MP_... But they’ve all grown an underscore fo= r consistency.

I think it would be more logical if all the su= btype names started MP_ [ie also DSS, ADD_ADDR, REMOVE_ADDR] [again, maybe = too much for your taste]

[Alan] Given tha= t these are symbols within a MPTCP-specific registry, I only see MP_ as tak= ing up unnecessary space. Sorry ;)

The bare ‘ID’= appears quite often- think you should use ‘Address ID’ through= out

[Alan] I found three instances, let m= e know if I’ve missed any.

--
 
S1.1 <<= ;The
   congestion control algorithms as discussed in [5]= ensure this does
   not act detrimentally.>>
Th= e congestion control algorithm defined in [5] achieves this.
 
S= 1.3 a reference to S4 might be nice
 
S1.4 bullet 2, “whe= re a TCP connection is established” – should be MPTCP connectio= n
 
2.1 & 2.2 – would it be more logical if ‘ACK= MP_CAPABLE’ & ‘ACK MP_JOIN’ didn’t have ‘= ;ACK’ since there’s no special ACK subtype? But maybe this make= s it harder to understand what’s happening?
 
2.4 para 2 &= lt;<   The "Data Sequence Signal" option which carri= es this "Data Sequence
   Mapping", which consi= sts of the subflow sequence number, data>>
   The &= quot;Data Sequence Signal" option carries the "Data Sequence
&= nbsp;  Mapping". The Data Sequence Mapping consists of the s= ubflow sequence number, data
 
2.7 bullet 1 “MP-ADD-ADDR&#= 8221; should be ADD_ADDR (unless you change subtype names to all start MP_ = !)
 
3.1 para 4, last sentence (The subflow handshake mechanism&= #8230;) is quite hard to parse
 
3.1, last para p14 << The= leftmost bit - labeled C
   - indicates "Checksum r= equired", and SHOULD be set to 1 unless
   specifica= lly overridden (for example, if the system administrator has
  = ; decided that checksums are not required - see Section 3.3 for more   discussion)>>
The leftmost bit - labelled C - = SHOULD be set to 1 to indicate "Checksum required", unless the sy= stem administrator has
   decided that checksums are not = required - see Section 3.3 for more
   discussion)
&nb= sp;
also, S3.3 doesn’t discuss why someone might decide to use che= cksums, or decide not to. Might be nice to add a hint about this somewhere<= br> 
also, when there are multiple crypo algos, do we want to point= out that the same one MUST be used for everything (generating token, isdn = etc)? maybe this is obvious and anyway would be better in any subsequent do= c about alternative crypto
 
[Alan] T= hat’s a good point, however I think it is best to leave it to any new= documents to decide whether they also want to tie a new crypto algorithm w= ith tokens/IDSN generation.

p15 – I thought the first s= entence [“These bits..” was redundant
 
p15 para 2 &= lt;< The initiator
   creates a proposal setting a bit= for each algorithm >>
The initiator sets a bit for each algorithm=
 
P16, last para of 3.1 << The initial Data Sequence Num= ber (IDSN) is generated as a hash from
   the Key, in the= same way as the token, i.e.  IDSN-A =3D Hash(Key-A) and
 &nbs= p; IDSN-B =3D Hash(Key-B).>>
The Initial Data Sequence Number= (IDSN) is generated as a hash from
   the Key, i.e. &nbs= p;IDSN-A =3D Hash(Key-A) and
   IDSN-B =3D Hash(Key-B). &= nbsp;           &nbs= p; 
 
Middle p17 – the ‘this’ bonanza mad= e it hard to understand. How about (includes a couple of other changes):-The MP_JOIN option includes an "Address ID".  This is an i= dentifier
   that only has significance within a single c= onnection, where it
   identifies the original source add= ress of the packet, even if the IP header has been changed in transit by a = middlebox.  This allows
   address removal (Section = 3.4.2) without needing to know what the source address at
  &n= bsp;the receiver is, and thus allows address removal through NATs. It also = allows correlation between new subflow
   setup attempts = and address signaling (Section 3.4.1), to prevent
   sett= ing up duplicate subflows on the same path.
 
P17 last para<&= lt; The MP_JOIN option on SYNs >> add ‘and SYN_ACKs’
<= br>[Alan] “Packets with the SYN flag set&#= 8221;

P18 first para under Fig 5 << Although cryptograp= hic calculations are required in the
   SYN/ACK, it is fe= lt that the 32 bit token gives >>
Although calculating a MAC requi= res cryptographic operations, it is believed that the 32 bit token in the M= P_JOIN SYN gives
 
P18 2nd para, sentence 2 “This is to a= llow..” takes some working out. Maybe: “This allow Host B to us= e random data sent by Host A in the SYN, as part of the MAC algorithm; and = similarly Host A to use random data sent by Host B in the SYN/ACK.
 = ;
Last sentence of this para can be shortened:
Due
  &n= bsp;to option space limitations, the MAC included in the SYN/ACK is
&nbs= p;  truncated to the leftmost 64 bits, but this is acceptable sin= ce
an attacker has only one chance to guess the MAC correctly.
 = ;
Next para – “and this is” -> “as”
=  
Same para “MUST trigger an ACK in response” – m= aybe you could stress that this is an ordinary data ACK
 
P19 &#= 8220;The message in each case “ -> The message for the MAC algorit= hm in each case
 
S3.2, the Random Number =3D=3D Nonce in S2. P= oint out, or change one of them.
 
S3.3 para 2 & 3 could be = re-phrased slightly:-
   During normal MPTCP operation, t= he Data Sequence Mapping defines how the sequence space on the subflow maps= to
   the connection level; and the Data ACK acknowledge= s receipt of
   data at the connection level.  These= functions are described in more
   detail in the followi= ng two subsections.
The Data Sequence Mapping and the Data ACK are signa= lled in the Data Sequence Signal (DSS). Either or both can be signalled in = one DSS, dependent on the flags set.
 
P23 << The data seq= uence mapping also contains a checksum of the data that
  &nbs= p;this mapping covers.  >> - to check I understand, this means y= ou need all the data before you start to transmit it, so you can calculate = the checksum?
 
P24 first para under fig 10, you could delete &#= 8220;. Furthermore,” and put the rest of the sentence in (..)
&nbs= p;
Last para 3.3.1 “data-level length field to “
Data-lev= el Length field of the DSS option to
 
P26 para 3, “that i= t is used” can be deleted
 
P26 para 4 << An MPTCP s= ender MUST only free data from the send buffer when it has
  &= nbsp;been acknowledged by both a Data ACK received on any subflow and at   the subflow level by any subflows the data was sent on. =  >>
could be clearer
An MPTCP sender MUST NOT free data fr= om the send buffer until it has
   been acknowledged by b= oth a Data ACK received on any subflow and at
   the subf= low level by all subflows the data was sent on.  
[note, 2nd ‘= ;any’ -> ‘all’]
 
Same para restransmited /= re-transmitted
 
P27 para 4 < and length 11> and Data-lev= el Length of 11
 
Same thing in next para
 
P27 penul= t para – I think ‘Data Sequence Signal’ would be more acc= urate here than ‘Mapping’. Also Length -> Data-level Length<= br> 
P27 last line, think you mean ‘DATA_FIN’ and not F= IN
 
3.3.4 para 4 << When deciding to accept packets at su= bflow level, normal TCP uses the
   sequence number in th= e packet and checks it against the allowed
   receive win= dow.  >>
When deciding to accept packets at the subflow level= , normal TCP checks the
   sequence number in the packet = against the allowed
   receive window.  
 P28 last line
Could you spell out what rcv_next is [or at least refere= nce B2.2.2, where it’s called RCV.NXT]
 
3.3.4 last para &= #8216;maximum bandwidth-delay product of any of the paths’ wonder if = ‘any one of the’ would be clearer?
 
3.3.6 para 1 &#= 8216;the best behaviour’ -> ‘sensible behaviour’
&n= bsp;
P30 last line active ACK -> actively ACK
 
3.3.6 last= line - < For example, subflows that perform highly asymmetrically may b= e mis-
   diagnosed as underperforming.>
For exampl= e, a highly asymmetrically path may be mis-
   diagnosed = as underperforming.
 
P33 para 1 ‘The signal applies to a = single direction:
   the sender of this option, however, = may >>
The signal applies to a single direction – and so the= sender of this option may
 
Next para < This
  = ; applies the given setting of B to all subflows that use the address<= br>   identified by the given Address ID.  >
do y= ou think it’s worth saying that this means all subflows in this conne= ction?
 
S3.4 para 2 < This design makes use of two methods o= f sharing such information,
   used simultaneously.  = ;>
This design makes use of two methods of sharing such information; = both can be used on a connection.
 
3.4.1 understake -> under= take
 
P35 para above Fig 12 as does the ephemeral port at the c= lient – explain.
 
Same para, “signalling subflow= 217; – should this  be ‘initial subflow’?
 <= br>Fig 12 caption – can delete ‘(shown for IPv4)’ –= as pic includes v6
 
P36 para 2 < This would be to ensure th= at this> This would ensure that
 
3.4.1 last para < an MP= TCP
   implementation MUST NOT treat duplicate ACKs with = any MPTCP option
   apart from DSS as indications of cong= estion >>
“NOT … any .. apart from” is ambiguous= .
 
P38 last bullet < The number of
   &nbs= p;  retransmissions should be limited >
SHOULD?
 S3.6 – end of sentence 1 – add ‘for instance they aren&= #8217;t blocked or mangled by a middlebox
 
3.6 para 4 < wit= h the length value of 0 > with the Data-level Length set to 0
 =
P40 para 1 I couldn’t parse this:-
(Note that these rules do n= ot apply if an
   infinite mapping is included from the s= tart - in which case, each end
   will send DSS options d= eclaring the infinite mapping.)
 
Fig 15 Length may be 8 & D= SN may be 4 octets
 
3.6 penult para “fallback mode”= – what is this?
 
3.8.3 para 2 < a host should fall ba= ck> SHOULD
 
S4, Duplicate ack. “To avoid any” -&= gt; To limit
 
S4, Receive window penult line <also need to&g= t; also needs to
 
S5, big para on p46 < used on subflow setu= p that verify that > used on subflow setup, in order to verify that
=  
P47 line 1, “will allow” -> allows
 
S6= para 1 &   P54 para 2
accomodate -> accommodate
&nb= sp;
S6 para 2 < Most middleboxes
   should just for= ward packets with new options unchanged>
Middleboxes should just forw= ard packets with new options unchanged  
[I think – (all) mid= dleboxes aren’t supposed to change options; most don’t]
&nbs= p;
P49 Traffic normalisers – should you also mention about re-tran= smitting on the same subflow?
 
9.2 – maybe worth adding r= fc editor note that hoping this will become rfc at the same time
 <= br>P54 para 2 <(10B)> 10 bytes
 
Appendix C – point = out that [DFIN] is shorthand for [DATA_FIN] – (I think!)
 That’s it, phew.

 
 
From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org]= On Behalf Of Yoshifumi Nishida
Sent: 18 April 2012 07:04
To: draft-ietf-mptcp-multia= ddressed@tools.ietf.org; multipathtcp
Subject: Re: [multipathtcp] co= mments on draft-ietf-mptcp-multiaddressed-07
 
Hi authors,
&n= bsp;
Sorry. I would like to add one more thing.
 
This draft= requires to create new registries for subtypes of mptcp option and cryptog= raphic algorithms handshake in MP_CAPABLE.  
For this, you will nee= d to add the description of the policy used for managing these registries i= n the IANA considerations section. Please check the section 4 of RFC5226 to= see the available choices (Section 4.1) and update the texts based on the = guideline (Section 4.2).
 
Thanks,
--
Yoshifumi Nishida 
 
 
On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi = Nishida <nishida@sfc.wide.ad.jp&g= t; wrote:
Hello,
 
Sorry for the long delay.
We believe it= 's good time to proceed to submit draft-ietf-mptcp-multiaddressed to IESG.<= br> 
Here's my comments on the draft to prepare a write-up for the = draft.
Please check and update if you agree with them.
 
Than= ks,
--
Yoshifumi
 
 
Page 13:
  3.1. = Connection Initiation
 
    ->  In m= y understanding, the key MUST be unique for each mptcp connection.
&nbs= p;        If so, I think we had bet= ter articulate it here.
 
Page 17:
   A host M= UST store the Address IDs associated with all established subflows.
&nbs= p;
   -> Does this mean both local Address IDs and rem= ote Address IDs advertized from the receiver?
    &n= bsp;  It might be better to clarify this.
 
Page 18:   therefore receipt of this packet MUST trigger an ACK in= response
 
   -> Since this is MUST, I think = Figure 8 needs to include this ACK in the sequence.
 
 
=    the packet MUST be retransmitted if this ACK is not recei= ved.
 
   -> In case of MP_CAPABLE, the third = packet is not retransmitted.
       B= ut, in case of MP_JOIN, it's retransmitted. Readers might want to know the = rationale about this.
  
Page 27:
 
  =  Essentially, a host MUST NOT FIN all functioning subflows unless it i= s safe to do so
   
    -> MUST= NOT close?
 
Page 28:
 
   Both hosts= SHOULD send FINS, as a courtesy to allow middleboxes to clean up state eve= n if the subflow is failed.
   -> I'm not very sure wh= ich situations can be addressed by this..
   ..
 =   Note that a host may also send a FIN on an individual subflow t= o shut it down, but this impact is limited to the subflow in question.
&= nbsp;
   -> Sorry. I couldn't understand this sentence= s well..
 
Page 30:
 
    The sen= der also remembers the receive windows advertised by each subflow.
 = ;  
    -> Don't we need to put SHOULD = or MUST here?
 
    The send buffer must be,= at the minimum, as big as the receive buffer
 
  &nbs= p; -> MUST?
 
    When doing this, a= host must still retransmit the original data on the original subflow,
&= nbsp;
    -> MUST?
 
Page 37:
 = ;
   if a response is received, the path is not removed.<= br> 
   a subflow that is still functioning MUST be = closed with a FIN exchange
 
    -> Aren'= t these sentences inconsistent?
 
Page 40:
 
 &n= bsp; fallback to regular TCP can become necessary at any point during = a connection if a non-MPTCP-aware middlebox changes the data stream.
&nb= sp;
    -> The paragraph below this suggest when = multiple subflows are in use, the affected subflow must be terminated, but = not suggesting fallback.
        = ; So, fallback seems not to be necessary?
 
  &nb= sp;Therefore, it is not possible to recover the subflow, and the affected s= ubflow must be immediately closed with an RST.
 
  &nb= sp; -> MUST?
 
   Failed data will not be= DATA_ACKed.
 
    -> MUST NOT be DATA_AC= Ked?
 
 
Page 47:
 
   If this= is dropped, MPTCP SHOULD fall back to regular TCP.
 
 &nbs= p;  -> may be MUST? since we cannot continue to use MPTCP .  
   If packets with the MP_JOIN option are droppe= d, the paths will simply not be used.
 
    = -> MUST NOT be used?
 
 
Page 51:
 
 = ;  Should use RFC6234 instead of RFC4634
 
Page 52: 
   Should use RFC5681 instead of RFC2581
 = ;  Should use draft-ietf-tcpm-secury-03 instead of -02
 &= nbsp; Should use draft-ietf-mptcp-api-04 or 05? instead of -03
&nbs= p;
 
There are some typos in the doc. Please update them by some= tools.
 
 

 

= --_000_9510D26531EF184D9017DF24659BB87F33C4583D02EMV65UKRDdoma_-- From alanford@cisco.com Tue May 29 03:15:00 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A561B21F86F4 for ; Tue, 29 May 2012 03:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7rUahubguwF for ; Tue, 29 May 2012 03:14:47 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id CD50D21F87B5 for ; Tue, 29 May 2012 03:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=57955; q=dns/txt; s=iport; t=1338286485; x=1339496085; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=8JqQAx0EvXcPRLO1JvFmR4CW53qVVKaH9/BHxlAdtq0=; b=KCvc+80HqIuSQ82+PWETtzJeNoV2P5rv+LL1T+Js3a2t7R808YOA2KbB kDkt81pvrAHsorzewmDwJe1HUOF34MXQlNOgd/+XGMMYJWhWcd9h71UU3 K6PDuD6cFFo636mWX9HcQ7Nh4hWdSGHkBXBI7rvLloSmn+ixvylAzBIln g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowHAFygxE+Q/khR/2dsb2JhbABEgkWHJ6pmgQgCgQeCFwEBAQMBEgEHAQwWKg0FBQ0BCBEEAQEBIAEGTQkIAQEEDgUih2QFmHGfTIsDFAGFHAOIDI0LjgwngT6CYYFVAQQC X-IronPort-AV: E=Sophos;i="4.75,677,1330905600"; d="scan'208,217";a="5092534" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 29 May 2012 10:14:43 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4TAEg0T030569; Tue, 29 May 2012 10:14:42 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 12:14:42 +0200 Received: from 144.254.90.168 ([144.254.90.168]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Tue, 29 May 2012 10:14:41 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Tue, 29 May 2012 11:14:38 +0100 From: Alan Ford To: Message-ID: Thread-Topic: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 Thread-Index: Ac0jzbqibAFIshA0T/uPM83vXnJ6ygWkeBYaAMUj+HAAA+vr1w== In-Reply-To: <9510D26531EF184D9017DF24659BB87F33C4583D02@EMV65-UKRD.domain1.systemhost.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3421134878_7464823" X-OriginalArrivalTime: 29 May 2012 10:14:42.0736 (UTC) FILETIME=[DD5B2300:01CD3D83] Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 10:15:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3421134878_7464823 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ah, I think that is a minor error. I mean encroaching on the cryptographic bits. This seems more appropriate: =B3Future specifications may define additional flags at the leftmost bits of this field, thus the number of bits available for cryptographic negotiation may change.=B2 Regards, Alan On 29/05/2012 09:34, "philip.eardley@bt.com" wrote: > All, > It=B9s probably worth pointing out explicitly that Section 8 IANA Considera= tions > has been updated. > - With our option kind assignment (30) >=20 > - RFCs will be used for future assignments of MPTCP option subty= pe > values & flags for crypto algos >=20 > =20 > Alan, > In the crypto algos part of S8 > << Note that the length of this field is not fixed; it is a definition > of the meaning of each bit in this field (i.e. 0x2, 0x4, 0x8, 0x10, > etc). Future specifications may encroach on the non-cryptographic > flags at the other end of this field so the number of flags available > for cryptographic algorithm use may change.>> > I don=B9t understand the =B3encroaching=B2. S3.1 says the flag octet leftmost b= it is > for Checksum required and =B3The remaining bits are used for crypto algorit= hm > negotiation.=B2 > =20 > Thanks > phil > =20 > =20 >=20 > From: Alan Ford [mailto:alanford@cisco.com] > Sent: 25 May 2012 11:18 > To: Eardley,PL,Philip,DUB8 R; nishida@sfc.wide.ad.jp > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-0= 7 > =20 > Hi Phil, >=20 > Many thanks for you comments. Anything I have not directly commented on b= elow > was straightforwardly addressed in =AD08. If there is anything you feel was= n=B9t > sufficiently addressed, please shout. >=20 > Regards, > Alan >=20 > On 26/04/2012 17:57, "philip.eardley@bt.com" wrot= e: > Hi Alan, Costin, Mark, Olivier, > =20 > Here are some comments. Sorry I finally got through it. > The first lot are either significant or something worth thinking about. T= he > second lot are just typos & re-phrasings =AD feel free to ignore if you don= =B9t > like the suggestion > =20 > Thanks! > phil > =20 > -- > =20 > Think it would be good to have a sub-section in S2 on Fast Close > =20 > Also might be worth adding one on MP_FAIL ? >=20 > [Alan] I decided against doing this. S2 is meant to be a light overview o= f the > protocol; it seems unnecessary and potentially confusing to burden reader= s > with these little-used features at this stage. >=20 > S3.1 penultimate para, << If this > option is not present, the connection should fall back to regular > TCP , as documented in Section 3.6.>> > SHOULD? > also S3.6 para 1 is about this =AD but it doesn=B9t have any capitalisation, = which > presumably it should > =20 > I thought that S3.2 could be clearer. Basically there are a lot of minor > things (see below) that add up to making it quite hard work. > =20 > Fig 8 =AD I think the first msg (SYN + MP_CAPABLE) should have (Key-A) > =20 > S3.3.0 =AD do you say somewhere what to do if the checksum is present but i= t > wasn=B9t negotiated in MP-CAPABLE, or it isnt present but wasn=B9t negotiated= ? > =20 > [Alan] We do now: =B3If a checksum is present, but its use had not been > negotiated in the MP_CAPABLE handshake, it SHOULD be ignored. If a checks= um is > not present when its use has been negotiated, the receiver SHOULD close t= he > subflow with a RST as it is considered broken.=B2 >=20 > P36 para 4 < If the Address ID is not in use on a > live subflow, but is stored by the receiver, a new ADD_ADDR SHOULD > take precedence and replace the stored address.> > I found this sentence quite hard to parse. If I understand it right, this= is > advertising a new address by over-writing an old address - using the same > Address ID. Rather than removing the old address and adding a new one wit= h a > different Address ID. Sounds dodgy? why doing this? >=20 > [Alan] You understood it right, however you=B9re right is has a whiff of > dodgyness to it. So I=B9ve removed it =AD now a host that wants to replace an > Address ID MUST remove it first. >=20 > 3.5 =AD Fast Close sends the Receiver=B9s Key in the clear. Does this open an > attack? =20 >=20 > [Alan] Not any new risks. Once it=B9s sent on Fast Close, the connection is > dead, so no further signalling with that key would have any effect. And y= es, > anyone who had seen the key on the initial handshake could Fast Close the > connection. But they can do anything anyway if they=B9ve seen the key on th= e > initial handshake. In Fast Close, usual TCP sequence number verification = is > required to ensure the signal is in-window (so an attacker would need to = know > both the key of the receiver and the sequence space of the sender). >=20 > There might be value in e.g. hashing the key with the sender=B9s DSN for > slightly more protection; I=B9m not sure if that adds anything. In fact, it > probably goes against the point of Fast Close that the sender actively DO= ES > NOT CARE whether its last packets actually get to the end host. >=20 > anyway, it contradicts S3.1 & S5 which say it=B9s only sent in the clear on= ce, > ie on MP-CAPABLE >=20 > [Alan] Fixed this. >=20 > 3.6 =AD I had it in my brain that fallback meant =8Cfallback from mptcp to tc= p=B9. > Here it means =8C.. or close a problematic subflow=B9. I=B9m not absolutely sur= e > it=B9s used consistently throughout the doc, but it=B9s probably worth adding= an > intro para to 3.6 that says there are n ways of coping with some problem, > close the subflow, close the connection (?), shift to tcp >=20 > [Alan] You=B9re right, it has evolved from its original meaning. Now re-wor= ded: > =B3Sometimes, middleboxes will exist on a path that could prevent the opera= tion > of MPTCP. MPTCP has been designed in order to cope with many middlebox > modifications (see Section 6), but there are still some cases where a sub= flow > could fail to operate within the MPTCP requirements. These cases are not= ably: > the loss of TCP options on a path; and the modification of payload data. = If > such an event occurs, it is necessary to "fall back" to the previous, saf= e > operation. This may either be falling back to regular TCP, or removing a > problematic subflow.=B2 >=20 > 3.6 para 1 =AD needs to be a SHOULD somewhere in here > =20 > 3.6 para 1 COMPARE 3.8.3 para 2 =AD 3.6 suggests give up on mptcp after one > MP_CAPABLE fails (& also 6 & 3.1); 3.8 suggests after several. Which is r= ight? >=20 > [Alan] It=B9s up to the implementation. The heuristics are our initial thou= ghts > on this; implementations optimise this. The heuristics now say =B3one or mo= re=B2 > rather than =B3several=B2. >=20 > S4 Receive window last sentence, =B3so a host must=B2 =AD SHOULD? Or maybe =8Cnee= ds > to=B9? Also, this point doesn=B9t appear in S3.3.4 >=20 > [Alan] =B3needs to=B2. Re S3.3.4, I think it is implied =AD there is talk there > about normal subflow processing. >=20 > P48 penul para < If some subflow-level space is left unmapped, > however, the subflow is treated as broken and is closed, as discussed > in Section 3.3. > > do you mean S3.6? I couldn=B9t see anything in s3.3 > =20 > [but it=B9s a big section, so a more accurate ref would be useful =AD same co= mment > on p10 just above the SS pic & p40 para 3] >=20 > [Alan] The reference to S3.6 there are more a general pointer to procedur= e > than a specific instruction =AD I=B9ve clarified this. >=20 > P49 PEPs < MPTCP will > therefore fall back to single-path TCP (see Section 3.6).> > I read S3.6 to say that you close the subflow (rather than fall back to t= cp) >=20 > [Alan] S3.6 is intended to cover both, and hopefully this new intro shoul= d > make this clearer. >=20 > S8 =AD can be updated with Option kind number 30 ! also Wes=B9s comment about= the > subtypes [ie invent a policy for managing them] >=20 > [Alan] It=B9s now been rewritten in RFC5226 style. >=20 > Appendix C =AD should the =8Csnd DATA_ACK=B9 arrows from M_ESTAB & from M_FIN W= AIT-1 > be snd DATA_ACK[DFIN] ? > =20 > -- > =20 > Minor suggestions etc =AD no need to ack these individually [but shout if I > reveal some misunderstanding!] > =20 > Throughout doc:=20 > =20 > Be consistent on =8CDATA_ACK=B9 & =8CDATA_FIN=B9 =AD many times appear without =8C_=B9 = [I > guess I prefer MP_DATA_ACK but that may be too much for your taste!] >=20 > [Alan] Remember those two are flags and not specific options, so it=B9s > definitely inappropriate to call them MP_... But they=B9ve all grown an > underscore for consistency. >=20 > I think it would be more logical if all the subtype names started MP_ [ie= also > DSS, ADD_ADDR, REMOVE_ADDR] [again, maybe too much for your taste] >=20 > [Alan] Given that these are symbols within a MPTCP-specific registry, I o= nly > see MP_ as taking up unnecessary space. Sorry ;) >=20 > The bare =8CID=B9 appears quite often- think you should use =8CAddress ID=B9 > throughout >=20 > [Alan] I found three instances, let me know if I=B9ve missed any. >=20 > -- > =20 > S1.1 < congestion control algorithms as discussed in [5] ensure this does > not act detrimentally.>> > The congestion control algorithm defined in [5] achieves this. > =20 > S1.3 a reference to S4 might be nice > =20 > S1.4 bullet 2, =B3where a TCP connection is established=B2 =AD should be MPTCP > connection > =20 > 2.1 & 2.2 =AD would it be more logical if =8CACK MP_CAPABLE=B9 & =8CACK MP_JOIN=B9 > didn=B9t have =8CACK=B9 since there=B9s no special ACK subtype? But maybe this ma= kes > it harder to understand what=B9s happening? > =20 > 2.4 para 2 << The "Data Sequence Signal" option which carries this "Dat= a > Sequence > Mapping", which consists of the subflow sequence number, data>> > The "Data Sequence Signal" option carries the "Data Sequence > Mapping". The Data Sequence Mapping consists of the subflow sequence > number, data > =20 > 2.7 bullet 1 =B3MP-ADD-ADDR=B2 should be ADD_ADDR (unless you change subtype = names > to all start MP_ !) > =20 > 3.1 para 4, last sentence (The subflow handshake mechanism=8A) is quite har= d to > parse > =20 > 3.1, last para p14 << The leftmost bit - labeled C > - indicates "Checksum required", and SHOULD be set to 1 unless > specifically overridden (for example, if the system administrator has > decided that checksums are not required - see Section 3.3 for more > discussion)>> > The leftmost bit - labelled C - SHOULD be set to 1 to indicate "Checksum > required", unless the system administrator has > decided that checksums are not required - see Section 3.3 for more > discussion) > =20 > also, S3.3 doesn=B9t discuss why someone might decide to use checksums, or > decide not to. Might be nice to add a hint about this somewhere > =20 > also, when there are multiple crypo algos, do we want to point out that t= he > same one MUST be used for everything (generating token, isdn etc)? maybe = this > is obvious and anyway would be better in any subsequent doc about alterna= tive > crypto > =20 > [Alan] That=B9s a good point, however I think it is best to leave it to any= new > documents to decide whether they also want to tie a new crypto algorithm = with > tokens/IDSN generation. >=20 > p15 =AD I thought the first sentence [=B3These bits..=B2 was redundant > =20 > p15 para 2 << The initiator > creates a proposal setting a bit for each algorithm >> > The initiator sets a bit for each algorithm > =20 > P16, last para of 3.1 << The initial Data Sequence Number (IDSN) is gener= ated > as a hash from > the Key, in the same way as the token, i.e. IDSN-A =3D Hash(Key-A) and > IDSN-B =3D Hash(Key-B).>> > The Initial Data Sequence Number (IDSN) is generated as a hash from > the Key, i.e. IDSN-A =3D Hash(Key-A) and > IDSN-B =3D Hash(Key-B). > =20 > Middle p17 =AD the =8Cthis=B9 bonanza made it hard to understand. How about > (includes a couple of other changes):- > The MP_JOIN option includes an "Address ID". This is an identifier > that only has significance within a single connection, where it > identifies the original source address of the packet, even if the IP h= eader > has been changed in transit by a middlebox. This allows > address removal (Section 3.4.2) without needing to know what the sourc= e > address at > the receiver is, and thus allows address removal through NATs. It also > allows correlation between new subflow > setup attempts and address signaling (Section 3.4.1), to prevent > setting up duplicate subflows on the same path. > =20 > P17 last para<< The MP_JOIN option on SYNs >> add =8Cand SYN_ACKs=B9 >=20 > [Alan] =B3Packets with the SYN flag set=B2 >=20 > P18 first para under Fig 5 << Although cryptographic calculations are req= uired > in the > SYN/ACK, it is felt that the 32 bit token gives >> > Although calculating a MAC requires cryptographic operations, it is belie= ved > that the 32 bit token in the MP_JOIN SYN gives > =20 > P18 2nd para, sentence 2 =B3This is to allow..=B2 takes some working out. May= be: > =B3This allow Host B to use random data sent by Host A in the SYN, as part = of > the MAC algorithm; and similarly Host A to use random data sent by Host B= in > the SYN/ACK. > =20 > Last sentence of this para can be shortened: > Due > to option space limitations, the MAC included in the SYN/ACK is > truncated to the leftmost 64 bits, but this is acceptable since > an attacker has only one chance to guess the MAC correctly. > =20 > Next para =AD =B3and this is=B2 -> =B3as=B2 > =20 > Same para =B3MUST trigger an ACK in response=B2 =AD maybe you could stress that= this > is an ordinary data ACK > =20 > P19 =B3The message in each case =B3 -> The message for the MAC algorithm in e= ach > case=20 > =20 > S3.2, the Random Number =3D=3D Nonce in S2. Point out, or change one of them. > =20 > S3.3 para 2 & 3 could be re-phrased slightly:- > During normal MPTCP operation, the Data Sequence Mapping defines how t= he > sequence space on the subflow maps to > the connection level; and the Data ACK acknowledges receipt of > data at the connection level. These functions are described in more > detail in the following two subsections. > The Data Sequence Mapping and the Data ACK are signalled in the Data Sequ= ence > Signal (DSS). Either or both can be signalled in one DSS, dependent on th= e > flags set. > =20 > P23 << The data sequence mapping also contains a checksum of the data tha= t > this mapping covers. >> - to check I understand, this means you need = all > the data before you start to transmit it, so you can calculate the checks= um? > =20 > P24 first para under fig 10, you could delete =B3. Furthermore,=B2 and put th= e > rest of the sentence in (..) > =20 > Last para 3.3.1 =B3data-level length field to =B3 > Data-level Length field of the DSS option to > =20 > P26 para 3, =B3that it is used=B2 can be deleted > =20 > P26 para 4 << An MPTCP sender MUST only free data from the send buffer wh= en it > has > been acknowledged by both a Data ACK received on any subflow and at > the subflow level by any subflows the data was sent on. >> > could be clearer > An MPTCP sender MUST NOT free data from the send buffer until it has > been acknowledged by both a Data ACK received on any subflow and at > the subflow level by all subflows the data was sent on. > [note, 2nd =8Cany=B9 -> =8Call=B9] > =20 > Same para restransmited / re-transmitted > =20 > P27 para 4 < and length 11> and Data-level Length of 11 > =20 > Same thing in next para > =20 > P27 penult para =AD I think =8CData Sequence Signal=B9 would be more accurate h= ere > than =8CMapping=B9. Also Length -> Data-level Length > =20 > P27 last line, think you mean =8CDATA_FIN=B9 and not FIN > =20 > 3.3.4 para 4 << When deciding to accept packets at subflow level, normal = TCP > uses the > sequence number in the packet and checks it against the allowed > receive window. >> > When deciding to accept packets at the subflow level, normal TCP checks t= he > sequence number in the packet against the allowed > receive window. > =20 > P28 last line > Could you spell out what rcv_next is [or at least reference B2.2.2, where= it=B9s > called RCV.NXT] > =20 > 3.3.4 last para =8Cmaximum bandwidth-delay product of any of the paths=B9 won= der > if =8Cany one of the=B9 would be clearer? > =20 > 3.3.6 para 1 =8Cthe best behaviour=B9 -> =8Csensible behaviour=B9 > =20 > P30 last line active ACK -> actively ACK > =20 > 3.3.6 last line - < For example, subflows that perform highly asymmetrica= lly > may be mis- > diagnosed as underperforming.> > For example, a highly asymmetrically path may be mis- > diagnosed as underperforming. > =20 > P33 para 1 =8CThe signal applies to a single direction: > the sender of this option, however, may >> > The signal applies to a single direction =AD and so the sender of this opti= on > may=20 > =20 > Next para < This > applies the given setting of B to all subflows that use the address > identified by the given Address ID. > > do you think it=B9s worth saying that this means all subflows in this > connection? > =20 > S3.4 para 2 < This design makes use of two methods of sharing such > information, > used simultaneously. > > This design makes use of two methods of sharing such information; both ca= n be > used on a connection. > =20 > 3.4.1 understake -> undertake > =20 > P35 para above Fig 12 as does the ephemeral port at the client =AD explain. > =20 > Same para, =B3signalling subflow=B9 =AD should this be =8Cinitial subflow=B9? > =20 > Fig 12 caption =AD can delete =8C(shown for IPv4)=B9 =AD as pic includes v6 > =20 > P36 para 2 < This would be to ensure that this> This would ensure that > =20 > 3.4.1 last para < an MPTCP > implementation MUST NOT treat duplicate ACKs with any MPTCP option > apart from DSS as indications of congestion >> > =B3NOT =8A any .. apart from=B2 is ambiguous. > =20 > P38 last bullet < The number of > retransmissions should be limited > > SHOULD? > =20 > S3.6 =AD end of sentence 1 =AD add =8Cfor instance they aren=B9t blocked or mangl= ed by > a middlebox=20 > =20 > 3.6 para 4 < with the length value of 0 > with the Data-level Length set = to 0 > =20 > P40 para 1 I couldn=B9t parse this:- > (Note that these rules do not apply if an > infinite mapping is included from the start - in which case, each end > will send DSS options declaring the infinite mapping.) > =20 > Fig 15 Length may be 8 & DSN may be 4 octets > =20 > 3.6 penult para =B3fallback mode=B2 =AD what is this? > =20 > 3.8.3 para 2 < a host should fall back> SHOULD > =20 > S4, Duplicate ack. =B3To avoid any=B2 -> To limit > =20 > S4, Receive window penult line also needs to > =20 > S5, big para on p46 < used on subflow setup that verify that > used on su= bflow > setup, in order to verify that > =20 > P47 line 1, =B3will allow=B2 -> allows > =20 > S6 para 1 & P54 para 2 > accomodate -> accommodate > =20 > S6 para 2 < Most middleboxes > should just forward packets with new options unchanged> > Middleboxes should just forward packets with new options unchanged > [I think =AD (all) middleboxes aren=B9t supposed to change options; most don=B9= t] > =20 > P49 Traffic normalisers =AD should you also mention about re-transmitting o= n the > same subflow? > =20 > 9.2 =AD maybe worth adding rfc editor note that hoping this will become rfc= at > the same time > =20 > P54 para 2 <(10B)> 10 bytes > =20 > Appendix C =AD point out that [DFIN] is shorthand for [DATA_FIN] =AD (I think= !) > =20 > That=B9s it, phew. >=20 > =20 > =20 > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org= ] On > Behalf Of Yoshifumi Nishida > Sent: 18 April 2012 07:04 > To: draft-ietf-mptcp-multiaddressed@tools.ietf.org; multipathtcp > Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-0= 7 > =20 > Hi authors, > =20 > Sorry. I would like to add one more thing. > =20 > This draft requires to create new registries for subtypes of mptcp option= and > cryptographic algorithms handshake in MP_CAPABLE. > For this, you will need to add the description of the policy used for man= aging > these registries in the IANA considerations section. Please check the sec= tion > 4 of RFC5226 to see the available choices (Section 4.1) and update the te= xts > based on the guideline (Section 4.2). > =20 > Thanks, > -- > Yoshifumi Nishida > =20 > =20 > =20 > On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida > wrote: > Hello, > =20 > Sorry for the long delay. > We believe it's good time to proceed to submit draft-ietf-mptcp-multiaddr= essed > to IESG. > =20 > Here's my comments on the draft to prepare a write-up for the draft. > Please check and update if you agree with them. > =20 > Thanks, > -- > Yoshifumi > =20 > =20 > Page 13: > 3.1. Connection Initiation > =20 > -> In my understanding, the key MUST be unique for each mptcp connec= tion. > If so, I think we had better articulate it here. > =20 > Page 17: > A host MUST store the Address IDs associated with all established subf= lows. > =20 > -> Does this mean both local Address IDs and remote Address IDs advert= ized > from the receiver? > It might be better to clarify this. > =20 > Page 18: > therefore receipt of this packet MUST trigger an ACK in response > =20 > -> Since this is MUST, I think Figure 8 needs to include this ACK in t= he > sequence. > =20 > =20 > the packet MUST be retransmitted if this ACK is not received. > =20 > -> In case of MP_CAPABLE, the third packet is not retransmitted. > But, in case of MP_JOIN, it's retransmitted. Readers might want to= know > the rationale about this. > =20 > Page 27: > =20 > Essentially, a host MUST NOT FIN all functioning subflows unless it is= safe > to do so > =20 > -> MUST NOT close? > =20 > Page 28: > =20 > Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to cle= an up > state even if the subflow is failed. > -> I'm not very sure which situations can be addressed by this.. > .. > Note that a host may also send a FIN on an individual subflow to shut = it > down, but this impact is limited to the subflow in question. > =20 > -> Sorry. I couldn't understand this sentences well.. > =20 > Page 30: > =20 > The sender also remembers the receive windows advertised by each subf= low. > =20 > -> Don't we need to put SHOULD or MUST here? > =20 > The send buffer must be, at the minimum, as big as the receive buffer > =20 > -> MUST? > =20 > When doing this, a host must still retransmit the original data on th= e > original subflow, > =20 > -> MUST? > =20 > Page 37: > =20 > if a response is received, the path is not removed. > =20 > a subflow that is still functioning MUST be closed with a FIN exchange > =20 > -> Aren't these sentences inconsistent? > =20 > Page 40: > =20 > fallback to regular TCP can become necessary at any point during a > connection if a non-MPTCP-aware middlebox changes the data stream. > =20 > -> The paragraph below this suggest when multiple subflows are in use= , the > affected subflow must be terminated, but not suggesting fallback. > So, fallback seems not to be necessary? > =20 > Therefore, it is not possible to recover the subflow, and the affected > subflow must be immediately closed with an RST. > =20 > -> MUST? > =20 > Failed data will not be DATA_ACKed. > =20 > -> MUST NOT be DATA_ACKed? > =20 > =20 > Page 47: > =20 > If this is dropped, MPTCP SHOULD fall back to regular TCP. > =20 > -> may be MUST? since we cannot continue to use MPTCP . > =20 > If packets with the MP_JOIN option are dropped, the paths will simply = not > be used. > =20 > -> MUST NOT be used? > =20 > =20 > Page 51: > =20 > Should use RFC6234 instead of RFC4634 > =20 > Page 52: > =20 > Should use RFC5681 instead of RFC2581 > Should use draft-ietf-tcpm-secury-03 instead of -02 > Should use draft-ietf-mptcp-api-04 or 05? instead of -03 > =20 > =20 > There are some typos in the doc. Please update them by some tools. > =20 > =20 > =20 --B_3421134878_7464823 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Ah, I think that is a minor error. I mean encroaching on the cryptographic= bits.<BR> <BR> This seems more appropriate: “Future specifications may define additi= onal flags at the leftmost bits of this field, thus the number of bits avail= able for cryptographic negotiation may change.”<BR> <BR> Regards,<BR> Alan<BR> <BR> On 29/05/2012 09:34, "<a href=3D"philip.eardley@bt.com">philip.eardley@b= t.com</a>" <<a href=3D"philip.eardley@bt.com">philip.eardley@bt.com</a= >> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">All,<BR> It’s probably worth pointing out explicitly that Section 8 IANA Consi= derations has been updated. <BR> -          With our option kin= d assignment (30)<BR> </FONT><BR> <FONT COLOR=3D"#1F497D">-         &nb= sp;RFCs will be used for future assignments of MPTCP option subtype values &= amp; flags for crypto algos <BR> </FONT><BR> </SPAN></FONT><FONT COLOR=3D"#1F497D"><FONT SIZE=3D"1"><FONT FACE=3D"Arial"><SPAN= STYLE=3D'font-size:9pt'> <BR> Alan,<BR> In the crypto algos part of S8<BR> <<</SPAN></FONT></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica= , Arial"><SPAN STYLE=3D'font-size:11pt'>   Note that the length of t= his field is not fixed; it is a definition<BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz= e:10pt'>   of the meaning of each bit in this field (i.e. 0x2, 0x4= , 0x8, 0x10,<BR>    etc).  Future specifications may encroach on the non= -cryptographic<BR>    flags at the other end of this field so the number of fla= gs available<BR>    for cryptographic algorithm use may change.>><BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:11pt'>I don’t understand the “encroaching”= ;. S3.1 says the flag octet leftmost bit is for Checksum required and “= ;The remaining bits are used for crypto algorithm negotiation.”<BR>  <BR> Thanks<BR> phil<BR> </SPAN></FONT><FONT COLOR=3D"#1F497D"><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"= ><SPAN STYLE=3D'font-size:10pt'> <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:11pt'> <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:11pt'><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Alan Ford [<a href=3D"mailto:alanfo= rd@cisco.com">mailto:alanford@cisco.com</a>] <BR> <B>Sent:</B> 25 May 2012 11:18<BR> <B>To:</B> Eardley,PL,Philip,DUB8 R; <a href=3D"nishida@sfc.wide.ad.jp">nishi= da@sfc.wide.ad.jp</a><BR> <B>Cc:</B> <a href=3D"multipathtcp@ietf.org">multipathtcp@ietf.org</a><BR> <B>Subject:</B> Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddres= sed-07<BR> </SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12= pt'> <BR> </SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'>Hi Phil,<BR> <BR> Many thanks for you comments. Anything I have not directly commented on bel= ow was straightforwardly addressed in –08. If there is anything you fe= el wasn’t sufficiently addressed, please shout.<BR> <BR> Regards,<BR> Alan<BR> <BR> On 26/04/2012 17:57, "<a href=3D"philip.eardley@bt.com">philip.eardley@b= t.com</a>" <<a href=3D"philip.eardley@bt.com">philip.eardley@bt.com</a= >> wrote:<BR> Hi Alan, Costin, Mark, Olivier,<BR>  <BR> Here are some comments. Sorry I finally got through it.<BR> The first lot are either significant or something worth thinking about. The=  second lot are just typos & re-phrasings – feel free to ign= ore if you don’t like the suggestion<BR>  <BR> Thanks!<BR> phil<BR>  <BR> --<BR>  <BR> Think it would be good to have a sub-section in S2 on Fast Close<BR>  <BR> Also might be worth adding one on MP_FAIL ?<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] I decided against doing this. S2 is meant to b= e a light overview of the protocol; it seems unnecessary and potentially con= fusing to burden readers with these little-used features at this stage.<BR> </FONT><BR> S3.1 penultimate para, << If this<BR>    option is not present, the connection should fall back to= regular<BR>    TCP , as documented in Section 3.6.>><BR> SHOULD?<BR> also S3.6 para 1 is about this – but it doesn’t have any capita= lisation, which presumably it should<BR>  <BR> I thought that S3.2 could be clearer. Basically there are a lot of minor th= ings (see below) that add up to making it quite hard work.<BR>  <BR> Fig 8 – I think the first msg (SYN + MP_CAPABLE) should have (Key-A)<= BR>  <BR> S3.3.0 – do you say somewhere what to do if the checksum is present b= ut it wasn’t negotiated in MP-CAPABLE, or it isnt present but wasnR= 17;t negotiated?<BR>  <BR> <FONT COLOR=3D"#0000FF">[Alan] We do now: “If a checksum is present, bu= t its use had not been negotiated in the MP_CAPABLE handshake, it SHOULD be = ignored. If a checksum is not present when its use has been negotiated, the = receiver SHOULD close the subflow with a RST as it is considered broken.R= 21;<BR> </FONT><BR> P36 para 4 < If the Address ID is not in use on a<BR>    live subflow, but is stored by the receiver, a new ADD_AD= DR SHOULD<BR>    take precedence and replace the stored address.><BR> I found this sentence quite hard to parse. If I understand it right, this i= s advertising a new address by over-writing an old address - using the same = Address ID. Rather than removing the old address and adding a new one with a= different Address ID. Sounds dodgy? why doing this?<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] You understood it right, however you’re = right is has a whiff of dodgyness to it. So I’ve removed it – no= w a host that wants to replace an Address ID MUST remove it first.<BR> </FONT><BR> 3.5 – Fast Close sends the Receiver’s Key in the clear. Does th= is open an attack?  <BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Not any new risks. Once it’s sent on Fas= t Close, the connection is dead, so no further signalling with that key woul= d have any effect. And yes, anyone who had seen the key on the initial hands= hake could Fast Close the connection. But they can do anything anyway if the= y’ve seen the key on the initial handshake. In Fast Close, usual TCP s= equence number verification is required to ensure the signal is in-window (s= o an attacker would need to know both the key of the receiver and the sequen= ce space of the sender).<BR> <BR> There might be value in e.g. hashing the key with the sender’s DSN fo= r slightly more protection; I’m not sure if that adds anything. In fac= t, it probably goes against the point of Fast Close that the sender actively= DOES NOT CARE whether its last packets actually get to the end host.<BR> </FONT><BR> anyway, it contradicts S3.1 & S5 which say it’s only sent in the = clear once, ie on MP-CAPABLE<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Fixed this.<BR> </FONT><BR> 3.6 – I had it in my brain that fallback meant ‘fallback from m= ptcp to tcp’. Here it means ‘.. or close a problematic subflow&#= 8217;. I’m not absolutely sure it’s used consistently throughout= the doc, but it’s probably worth adding an intro para to 3.6 that say= s there are n ways of coping with some problem, close the subflow, close the= connection (?), shift to tcp<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] You’re right, it has evolved from its or= iginal meaning. Now re-worded: “Sometimes, middleboxes will exist on a= path that could prevent the operation of MPTCP.  MPTCP has been design= ed in order to cope with many middlebox modifications (see Section 6), but t= here are still some cases where a subflow could fail to operate within the M= PTCP requirements.  These cases are notably: the loss of TCP options on= a path; and the modification of payload data.  If such an event occurs= , it is necessary to "fall back" to the previous, safe operation. =  This may either be falling back to regular TCP, or removing a problema= tic subflow.”<BR> </FONT><BR> 3.6 para 1 – needs to be a SHOULD somewhere in here<BR>  <BR> 3.6 para 1 COMPARE 3.8.3 para 2 – 3.6 suggests give up on mptcp after= one MP_CAPABLE fails (& also 6 & 3.1); 3.8 suggests after several. = Which is right? <BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] It’s up to the implementation. The heuri= stics are our initial thoughts on this; implementations optimise this</FONT>= .<FONT COLOR=3D"#0000FF"> The heuristics now say “one or more” rat= her than “several”.</FONT> <BR> <BR> S4 Receive window last sentence, “so a host must” – SHOUL= D? Or maybe ‘needs to’?  Also, this point doesn’t app= ear in S3.3.4<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] “needs to”. Re S3.3.4, I think it = is implied – there is talk there about normal subflow processing.<BR> </FONT><BR> P48 penul para < If some subflow-level space is left unmapped,<BR>    however, the subflow is treated as broken and is closed, = as discussed<BR>    in Section 3.3.  ><BR> do you mean S3.6? I couldn’t see anything in s3.3 <BR>  <BR> [but it’s a big section, so a more accurate ref would be useful ̵= 1; same comment on p10 just above the SS pic & p40 para 3]<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] The reference to S3.6 there are more a general= pointer to procedure than a specific instruction – I’ve clarifi= ed this.<BR> </FONT><BR> P49 PEPs < MPTCP will<BR>       therefore fall back to single-path TCP = (see Section 3.6).><BR> I read S3.6 to say that you close the subflow (rather than fall back to tcp= )<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] S3.6 is intended to cover both, and hopefully = this new intro should make this clearer.<BR> </FONT><BR> S8 – can be updated with Option kind number 30 ! also Wes’s com= ment about the subtypes [ie invent a policy for managing them] <BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] It’s now been rewritten in RFC5226 style= .<BR> </FONT><BR> Appendix C – should the ‘snd DATA_ACK’ arrows from M_ESTA= B & from M_FIN WAIT-1  be snd DATA_ACK[DFIN] ?  <BR>  <BR> --<BR>  <BR> Minor suggestions etc – no need to ack these individually [but shout = if I reveal some misunderstanding!]<BR>  <BR> Throughout doc: <BR>  <BR> Be consistent on ‘DATA_ACK’ & ‘DATA_FIN’ –= ; many times appear without ‘_’ [I guess I prefer MP_DATA_ACK bu= t that may be too much for your taste!]<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Remember those two are flags and not specific = options, so it’s definitely inappropriate to call them MP_... But they= ’ve all grown an underscore for consistency.<BR> </FONT><BR> I think it would be more logical if all the subtype names started MP_ [ie a= lso DSS, ADD_ADDR, REMOVE_ADDR] [again, maybe too much for your taste]<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] Given that these are symbols within a MPTCP-sp= ecific registry, I only see MP_ as taking up unnecessary space. Sorry ;)</FO= NT> <BR> <BR> The bare ‘ID’ appears quite often- think you should use ‘= Address ID’ throughout<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] I found three instances, let me know if I̵= 7;ve missed any.<BR> </FONT><BR> --<BR>  <BR> S1.1 <<The<BR>    congestion control algorithms as discussed in [5] ensure = this does<BR>    not act detrimentally.>><BR> The congestion control algorithm defined in [5] achieves this.<BR>  <BR> S1.3 a reference to S4 might be nice <BR>  <BR> S1.4 bullet 2, “where a TCP connection is established” – = should be MPTCP connection<BR>  <BR> 2.1 & 2.2 – would it be more logical if ‘ACK MP_CAPABLER= 17; & ‘ACK MP_JOIN’ didn’t have ‘ACK’ sinc= e there’s no special ACK subtype? But maybe this makes it harder to un= derstand what’s happening?<BR>  <BR> 2.4 para 2 <<   The "Data Sequence Signal" option= which carries this "Data Sequence<BR>    Mapping", which consists of the subflow sequence num= ber, data>><BR>    The "Data Sequence Signal" option carries the &= quot;Data Sequence<BR>    Mapping". The Data Sequence Mapping consists of the = subflow sequence number, data<BR>  <BR> 2.7 bullet 1 “MP-ADD-ADDR” should be ADD_ADDR (unless you chang= e subtype names to all start MP_ !)<BR>  <BR> 3.1 para 4, last sentence (The subflow handshake mechanism…) is quite= hard to parse<BR>  <BR> 3.1, last para p14 << The leftmost bit - labeled C<BR>    - indicates "Checksum required", and SHOULD be = set to 1 unless<BR>    specifically overridden (for example, if the system admin= istrator has<BR>    decided that checksums are not required - see Section 3.3= for more<BR>    discussion)>><BR> The leftmost bit - labelled C - SHOULD be set to 1 to indicate "Checks= um required", unless the system administrator has<BR>    decided that checksums are not required - see Section 3.3= for more<BR>    discussion)<BR>  <BR> also, S3.3 doesn’t discuss why someone might decide to use checksums,= or decide not to. Might be nice to add a hint about this somewhere<BR>  <BR> also, when there are multiple crypo algos, do we want to point out that the= same one MUST be used for everything (generating token, isdn etc)? maybe th= is is obvious and anyway would be better in any subsequent doc about alterna= tive crypto<BR>  <BR> <FONT COLOR=3D"#0000FF">[Alan] That’s a good point, however I think it = is best to leave it to any new documents to decide whether they also want to= tie a new crypto algorithm with tokens/IDSN generation.<BR> </FONT><BR> p15 – I thought the first sentence [“These bits..” was re= dundant<BR>  <BR> p15 para 2 << The initiator<BR>    creates a proposal setting a bit for each algorithm >&= gt;<BR> The initiator sets a bit for each algorithm <BR>  <BR> P16, last para of 3.1 << The initial Data Sequence Number (IDSN) is g= enerated as a hash from<BR>    the Key, in the same way as the token, i.e.  IDSN-A = =3D Hash(Key-A) and<BR>    IDSN-B =3D Hash(Key-B).>><BR> The Initial Data Sequence Number (IDSN) is generated as a hash from<BR>    the Key, i.e.  IDSN-A =3D Hash(Key-A) and<BR>    IDSN-B =3D Hash(Key-B).       = ;        <BR>  <BR> Middle p17 – the ‘this’ bonanza made it hard to understan= d. How about (includes a couple of other changes):-<BR> The MP_JOIN option includes an "Address ID".  This is an ide= ntifier<BR>    that only has significance within a single connection, wh= ere it<BR>    identifies the original source address of the packet, eve= n if the IP header has been changed in transit by a middlebox.  This al= lows<BR>    address removal (Section 3.4.2) without needing to know w= hat the source address at<BR>    the receiver is, and thus allows address removal through = NATs. It also allows correlation between new subflow<BR>    setup attempts and address signaling (Section 3.4.1), to = prevent<BR>    setting up duplicate subflows on the same path.<BR>  <BR> P17 last para<< The MP_JOIN option on SYNs >> add ‘and SY= N_ACKs’<BR> <BR> <FONT COLOR=3D"#0000FF">[Alan] “Packets with the SYN flag set”<BR= > </FONT><BR> P18 first para under Fig 5 << Although cryptographic calculations are= required in the<BR>    SYN/ACK, it is felt that the 32 bit token gives >><= BR> Although calculating a MAC requires cryptographic operations, it is believe= d that the 32 bit token in the MP_JOIN SYN gives <BR>  <BR> P18 2nd para, sentence 2 “This is to allow..” takes some workin= g out. Maybe: “This allow Host B to use random data sent by Host A in = the SYN, as part of the MAC algorithm; and similarly Host A to use random da= ta sent by Host B in the SYN/ACK.<BR>  <BR> Last sentence of this para can be shortened: <BR> Due<BR>    to option space limitations, the MAC included in the SYN/= ACK is<BR>    truncated to the leftmost 64 bits, but this is acceptable= since <BR> an attacker has only one chance to guess the MAC correctly.<BR>  <BR> Next para – “and this is” -> “as”<BR>  <BR> Same para “MUST trigger an ACK in response” – maybe you c= ould stress that this is an ordinary data ACK<BR>  <BR> P19 “The message in each case “ -> The message for the MAC a= lgorithm in each case <BR>  <BR> S3.2, the Random Number =3D=3D Nonce in S2. Point out, or change one of them.<B= R>  <BR> S3.3 para 2 & 3 could be re-phrased slightly:-<BR>    During normal MPTCP operation, the Data Sequence Mapping = defines how the sequence space on the subflow maps to<BR>    the connection level; and the Data ACK acknowledges recei= pt of<BR>    data at the connection level.  These functions are d= escribed in more<BR>    detail in the following two subsections.<BR> The Data Sequence Mapping and the Data ACK are signalled in the Data Sequen= ce Signal (DSS). Either or both can be signalled in one DSS, dependent on th= e flags set.<BR>  <BR> P23 << The data sequence mapping also contains a checksum of the data= that<BR>    this mapping covers.  >> - to check I understa= nd, this means you need all the data before you start to transmit it, so you= can calculate the checksum?<BR>  <BR> P24 first para under fig 10, you could delete “. Furthermore,” = and put the rest of the sentence in (..)<BR>  <BR> Last para 3.3.1 “data-level length field to “<BR> Data-level Length field of the DSS option to<BR>  <BR> P26 para 3, “that it is used” can be deleted<BR>  <BR> P26 para 4 << An MPTCP sender MUST only free data from the send buffe= r when it has<BR>    been acknowledged by both a Data ACK received on any subf= low and at<BR>    the subflow level by any subflows the data was sent on. &= nbsp;>><BR> could be clearer<BR> An MPTCP sender MUST NOT free data from the send buffer until it has<BR>    been acknowledged by both a Data ACK received on any subf= low and at<BR>    the subflow level by all subflows the data was sent on. &= nbsp;<BR> [note, 2nd ‘any’ -> ‘all’]<BR>  <BR> Same para restransmited / re-transmitted<BR>  <BR> P27 para 4 < and length 11> and Data-level Length of 11<BR>  <BR> Same thing in next para<BR>  <BR> P27 penult para – I think ‘Data Sequence Signal’ would be= more accurate here than ‘Mapping’. Also Length -> Data-level= Length<BR>  <BR> P27 last line, think you mean ‘DATA_FIN’ and not FIN<BR>  <BR> 3.3.4 para 4 << When deciding to accept packets at subflow level, nor= mal TCP uses the<BR>    sequence number in the packet and checks it against the a= llowed<BR>    receive window.  >><BR> When deciding to accept packets at the subflow level, normal TCP checks the= <BR>    sequence number in the packet against the allowed<BR>    receive window.  <BR>  <BR> P28 last line<BR> Could you spell out what rcv_next is [or at least reference B2.2.2, where i= t’s called RCV.NXT]<BR>  <BR> 3.3.4 last para ‘maximum bandwidth-delay product of any of the paths&= #8217; wonder if ‘any one of the’ would be clearer?<BR>  <BR> 3.3.6 para 1 ‘the best behaviour’ -> ‘sensible behavio= ur’<BR>  <BR> P30 last line active ACK -> actively ACK<BR>  <BR> 3.3.6 last line - < For example, subflows that perform highly asymmetric= ally may be mis-<BR>    diagnosed as underperforming.><BR> For example, a highly asymmetrically path may be mis-<BR>    diagnosed as underperforming.<BR>  <BR> P33 para 1 ‘The signal applies to a single direction:<BR>    the sender of this option, however, may >><BR> The signal applies to a single direction – and so the sender of this = option may <BR>  <BR> Next para < This<BR>    applies the given setting of B to all subflows that use t= he address<BR>    identified by the given Address ID.  ><BR> do you think it’s worth saying that this means all subflows in this c= onnection?<BR>  <BR> S3.4 para 2 < This design makes use of two methods of sharing such infor= mation,<BR>    used simultaneously.  ><BR> This design makes use of two methods of sharing such information; both can = be used on a connection.<BR>  <BR> 3.4.1 understake -> undertake<BR>  <BR> P35 para above Fig 12 as does the ephemeral port at the client – expl= ain.<BR>  <BR> Same para, “signalling subflow’ – should this  be &#= 8216;initial subflow’?<BR>  <BR> Fig 12 caption – can delete ‘(shown for IPv4)’ – as= pic includes v6<BR>  <BR> P36 para 2 < This would be to ensure that this> This would ensure tha= t <BR>  <BR> 3.4.1 last para < an MPTCP<BR>    implementation MUST NOT treat duplicate ACKs with any MPT= CP option<BR>    apart from DSS as indications of congestion >><BR> “NOT … any .. apart from” is ambiguous.<BR>  <BR> P38 last bullet < The number of<BR>       retransmissions should be limited ><= BR> SHOULD?<BR>  <BR> S3.6 – end of sentence 1 – add ‘for instance they aren= 217;t blocked or mangled by a middlebox <BR>  <BR> 3.6 para 4 < with the length value of 0 > with the Data-level Length = set to 0 <BR>  <BR> P40 para 1 I couldn’t parse this:-<BR> (Note that these rules do not apply if an<BR>    infinite mapping is included from the start - in which ca= se, each end<BR>    will send DSS options declaring the infinite mapping.)<BR= >  <BR> Fig 15 Length may be 8 & DSN may be 4 octets<BR>  <BR> 3.6 penult para “fallback mode” – what is this?<BR>  <BR> 3.8.3 para 2 < a host should fall back> SHOULD<BR>  <BR> S4, Duplicate ack. “To avoid any” -> To limit<BR>  <BR> S4, Receive window penult line <also need to> also needs to<BR>  <BR> S5, big para on p46 < used on subflow setup that verify that > used o= n subflow setup, in order to verify that <BR>  <BR> P47 line 1, “will allow” -> allows<BR>  <BR> S6 para 1 &   P54 para 2<BR> accomodate -> accommodate<BR>  <BR> S6 para 2 < Most middleboxes<BR>    should just forward packets with new options unchanged>= ;<BR> Middleboxes should just forward packets with new options unchanged  <B= R> [I think – (all) middleboxes aren’t supposed to change options;= most don’t]<BR>  <BR> P49 Traffic normalisers – should you also mention about re-transmitti= ng on the same subflow?<BR>  <BR> 9.2 – maybe worth adding rfc editor note that hoping this will become= rfc at the same time<BR>  <BR> P54 para 2 <(10B)> 10 bytes<BR>  <BR> Appendix C – point out that [DFIN] is shorthand for [DATA_FIN] –= ; (I think!) <BR>  <BR> That’s it, phew.<BR> <BR>  <BR>  <BR> From: <a href=3D"multipathtcp-bounces@ietf.org">multipathtcp-bounces@ietf.org= </a> [<a href=3D"mailto:multipathtcp-bounces@ietf.org">mailto:multipathtcp-bou= nces@ietf.org</a>] On Behalf Of Yoshifumi Nishida<BR> Sent: 18 April 2012 07:04<BR> To: <a href=3D"draft-ietf-mptcp-multiaddressed@tools.ietf.org">draft-ietf-mpt= cp-multiaddressed@tools.ietf.org</a>; multipathtcp<BR> Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07<= BR>  <BR> Hi authors,<BR>  <BR> Sorry. I would like to add one more thing. <BR>  <BR> This draft requires to create new registries for subtypes of mptcp option a= nd cryptographic algorithms handshake in MP_CAPABLE.  <BR> For this, you will need to add the description of the policy used for manag= ing these registries in the IANA considerations section. Please check the se= ction 4 of RFC5226 to see the available choices (Section 4.1) and update the= texts based on the guideline (Section 4.2).<BR>  <BR> Thanks,<BR> --<BR> Yoshifumi Nishida<BR>  <BR>  <BR>  <BR> On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida <<a href=3D"nishida@sf= c.wide.ad.jp">nishida@sfc.wide.ad.jp</a>> wrote:<BR> Hello,<BR>  <BR> Sorry for the long delay.<BR> We believe it's good time to proceed to submit draft-ietf-mptcp-multiaddres= sed to IESG.<BR>  <BR> Here's my comments on the draft to prepare a write-up for the draft.<BR> Please check and update if you agree with them.<BR>  <BR> Thanks,<BR> --<BR> Yoshifumi<BR>  <BR>  <BR> Page 13:<BR>   3.1. Connection Initiation<BR>  <BR>     ->  In my understanding, the key MUST be un= ique for each mptcp connection. <BR>          If so, I think we had= better articulate it here.<BR>  <BR> Page 17:<BR>    A host MUST store the Address IDs associated with all est= ablished subflows.<BR>  <BR>    -> Does this mean both local Address IDs and remote Ad= dress IDs advertized from the receiver?<BR>        It might be better to clarify thi= s.<BR>  <BR> Page 18:<BR>    therefore receipt of this packet MUST trigger an ACK in r= esponse<BR>  <BR>    -> Since this is MUST, I think Figure 8 needs to inclu= de this ACK in the sequence.<BR>  <BR>  <BR>    the packet MUST be retransmitted if this ACK is not recei= ved.<BR>  <BR>    -> In case of MP_CAPABLE, the third packet is not retr= ansmitted.<BR>        But, in case of MP_JOIN, it's ret= ransmitted. Readers might want to know the rationale about this.<BR>   <BR> Page 27:<BR>  <BR>    Essentially, a host MUST NOT FIN all functioning subflows= unless it is safe to do so<BR>    <BR>     -> MUST NOT close?<BR>  <BR> Page 28:<BR>  <BR>    Both hosts SHOULD send FINS, as a courtesy to allow middl= eboxes to clean up state even if the subflow is failed.<BR>    -> I'm not very sure which situations can be addressed= by this..<BR>    ..<BR>    Note that a host may also send a FIN on an individual sub= flow to shut it down, but this impact is limited to the subflow in question.= <BR>  <BR>    -> Sorry. I couldn't understand this sentences well..<= BR>  <BR> Page 30:<BR>  <BR>     The sender also remembers the receive windows adver= tised by each subflow.<BR>    <BR>     -> Don't we need to put SHOULD or MUST here?<BR>  <BR>     The send buffer must be, at the minimum, as big as = the receive buffer<BR>  <BR>     -> MUST?<BR>  <BR>     When doing this, a host must still retransmit the o= riginal data on the original subflow,<BR>  <BR>     -> MUST?<BR>  <BR> Page 37:<BR>  <BR>    if a response is received, the path is not removed.<BR>  <BR>    a subflow that is still functioning MUST be closed with a= FIN exchange<BR>  <BR>     -> Aren't these sentences inconsistent?<BR>  <BR> Page 40:<BR>  <BR>    fallback to regular TCP can become necessary at any point= during a connection if a non-MPTCP-aware middlebox changes the data stream.= <BR>  <BR>     -> The paragraph below this suggest when multipl= e subflows are in use, the affected subflow must be terminated, but not sugg= esting fallback.<BR>          So, fallback seems no= t to be necessary?<BR>  <BR>    Therefore, it is not possible to recover the subflow, and= the affected subflow must be immediately closed with an RST.<BR>  <BR>     -> MUST?<BR>  <BR>    Failed data will not be DATA_ACKed.<BR>  <BR>     -> MUST NOT be DATA_ACKed?<BR>  <BR>  <BR> Page 47:<BR>  <BR>    If this is dropped, MPTCP SHOULD fall back to regular TCP= .<BR>  <BR>     -> may be MUST? since we cannot continue to use = MPTCP . <BR>  <BR>    If packets with the MP_JOIN option are dropped, the paths= will simply not be used.<BR>  <BR>     -> MUST NOT be used? <BR>  <BR>  <BR> Page 51:<BR>  <BR>    Should use RFC6234 instead of RFC4634<BR>  <BR> Page 52:<BR>  <BR>    Should use RFC5681 instead of RFC2581<BR>    Should use draft-ietf-tcpm-secury-03 instead of -02<BR>    Should use draft-ietf-mptcp-api-04 or 05? instead of -03<= BR>  <BR>  <BR> There are some typos in the doc. Please update them by some tools.<BR>  <BR>  <BR> </SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'> <B= R> </SPAN></FONT></BLOCKQUOTE><FONT COLOR=3D"#222222"><FONT FACE=3D"Calibri, Verda= na, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt'><BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:11pt'><BR> </SPAN></FONT> </BODY> </HTML> --B_3421134878_7464823-- From nishida@sfc.wide.ad.jp Wed May 30 00:49:52 2012 Return-Path: <nishida@sfc.wide.ad.jp> X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1EB21F865A for <multipathtcp@ietfa.amsl.com>; Wed, 30 May 2012 00:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.843 X-Spam-Level: X-Spam-Status: No, score=-101.843 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OQde8Liyqsv for <multipathtcp@ietfa.amsl.com>; Wed, 30 May 2012 00:49:50 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id A473821F8435 for <multipathtcp@ietf.org>; Wed, 30 May 2012 00:49:47 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CEB39278097 for <multipathtcp@ietf.org>; Wed, 30 May 2012 16:49:44 +0900 (JST) Received: by lbbgo11 with SMTP id go11so3240532lbb.31 for <multipathtcp@ietf.org>; Wed, 30 May 2012 00:49:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr14586750lab.9.1338364182170; Wed, 30 May 2012 00:49:42 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Wed, 30 May 2012 00:49:42 -0700 (PDT) In-Reply-To: <CBE51AAE.9DEB%alanford@cisco.com> References: <CAO249yf4rFyM+vTGiQbFWHJ5nKymp1xrTroaVLF2T=95QEStcw@mail.gmail.com> <CBE51AAE.9DEB%alanford@cisco.com> Date: Wed, 30 May 2012 00:49:42 -0700 Message-ID: <CAO249yewe76T6Xe9mTrOUk4RK3gxowjvMGo44RaPWBXo39n=gA@mail.gmail.com> From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp> To: Alan Ford <alanford@cisco.com> Content-Type: multipart/alternative; boundary=e89a8f22c411a88d8e04c13c3188 Cc: multipathtcp <multipathtcp@ietf.org> Subject: Re: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp> List-Post: <mailto:multipathtcp@ietf.org> List-Help: <mailto:multipathtcp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 May 2012 07:49:52 -0000 --e89a8f22c411a88d8e04c13c3188 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Alan, Thank you so much for updating the draft. I agree the updates in the draft and comments in your mail. Just one very minor thing.. >> Page 13: >> 3.1. Connection Initiation >> >> -> In my understanding, the key MUST be unique for each mptcp connection. >> If so, I think we had better articulate it here. >> [Alan] Unique per host, yes. I believe that is clear already; certainly, I couldn=92t find a way of making it any clearer. I might be too picky. But, I thought "The key MUST be hard to guess, and it MUST be unique for the sending host at any one time." might not be very clear if a unique key is assigned to individual mptcp connection or not. We might be able to guess it from "Connections will be indexed at each host by the token", but I'm thinking explicit expression might be better.. Thanks, -- Yoshifumi On Fri, May 25, 2012 at 3:17 AM, Alan Ford <alanford@cisco.com> wrote: > Hi Yoshifumi, > > Thank you for your feedback. Anything I haven=92t directly commented on > below was straightforwardly addressed in =9608. If there is anything you = feel > wasn=92t sufficiently addressed, please shout. > > Regards, > Alan > > > On 18/04/2012 07:03, "Yoshifumi Nishida" <nishida@sfc.wide.ad.jp> wrote: > > Hi authors, > > Sorry. I would like to add one more thing. > > This draft requires to create new registries for subtypes of mptcp option > and cryptographic algorithms handshake in MP_CAPABLE. > For this, you will need to add the description of the policy used for > managing these registries in the IANA considerations section. Please chec= k > the section 4 of RFC5226 to see the available choices (Section 4.1) and > update the texts based on the guideline (Section 4.2). > > Thanks, > -- > Yoshifumi Nishida > > > > > On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida < > nishida@sfc.wide.ad.jp> wrote: > > Hello, > > Sorry for the long delay. > We believe it's good time to proceed to submit > draft-ietf-mptcp-multiaddressed to IESG. > > Here's my comments on the draft to prepare a write-up for the draft. > Please check and update if you agree with them. > > Thanks, > -- > Yoshifumi > > > Page 13: > 3.1. Connection Initiation > > -> In my understanding, the key MUST be unique for each mptcp > connection. > If so, I think we had better articulate it here. > > [Alan] Unique per host, yes. I believe that is clear already; certainly, = I > couldn=92t find a way of making it any clearer. > > Page 17: > A host MUST store the Address IDs associated with all established > subflows. > > -> Does this mean both local Address IDs and remote Address IDs > advertized from the receiver? > It might be better to clarify this. > > [Alan] Yes it does, and I have clarified that. > > Page 18: > therefore receipt of this packet MUST trigger an ACK in response > > -> Since this is MUST, I think Figure 8 needs to include this ACK in > the sequence. > > > the packet MUST be retransmitted if this ACK is not received. > > -> In case of MP_CAPABLE, the third packet is not retransmitted. > But, in case of MP_JOIN, it's retransmitted. Readers might want t= o > know the rationale about this. > > [Alan] It=92s a completely different exchange, sending completely differe= nt > information: it=92s a crypto handshake not a key exchange. I had hoped th= at > would have been sufficiently clear, but I=92ve added a few words anyway. > > Page 27: > > Essentially, a host MUST NOT FIN all functioning subflows unless it is > safe to do so > > -> MUST NOT close? > > Page 28: > > Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to > clean up state even if the subflow is failed. > -> I'm not very sure which situations can be addressed by this.. > > [Alan] Changed to =93Both hosts SHOULD send FINs on all subflows, as a > courtesy to allow middleboxes to clean up state even if an individual > subflow is no longer operational end-to-end.=94. This is in the case if a > link has failed in the path somewhere, but one of the end hosts is behind= a > middlebox. That host would never receive a FIN on the subflow, and neithe= r > would the middlebox. But the end host knows the subflow should be closed, > so by sending a FIN it aids in cleaning up. > > .. > Note that a host may also send a FIN on an individual subflow to shut > it down, but this impact is limited to the subflow in question. > > -> Sorry. I couldn't understand this sentences well.. > > [Alan] Changed to =93As specified above, a standard TCP FIN on an individ= ual > subflow only shuts down the subflow on which it was sent.=94 > > Page 30: > > The sender also remembers the receive windows advertised by each > subflow. > > -> Don't we need to put SHOULD or MUST here? > > The send buffer must be, at the minimum, as big as the receive buffer > > -> MUST? > > When doing this, a host must still retransmit the original data on th= e > original subflow, > > -> MUST? > > Page 37: > > if a response is received, the path is not removed. > > a subflow that is still functioning MUST be closed with a FIN exchange > > -> Aren't these sentences inconsistent? > > [Alan] Not at all. It says you can=92t remove a functioning subflow with > REMOVE_ADDR, you must use a FIN exchange. > > Page 40: > > fallback to regular TCP can become necessary at any point during a > connection if a non-MPTCP-aware middlebox changes the data stream. > > -> The paragraph below this suggest when multiple subflows are in use= , > the affected subflow must be terminated, but not suggesting fallback. > So, fallback seems not to be necessary? > > Therefore, it is not possible to recover the subflow, and the affected > subflow must be immediately closed with an RST. > > -> MUST? > > Failed data will not be DATA_ACKed. > > -> MUST NOT be DATA_ACKed? > > > Page 47: > > If this is dropped, MPTCP SHOULD fall back to regular TCP. > > -> may be MUST? since we cannot continue to use MPTCP . > > [Alan] I don=92t want to restrict what implementations do in this state = =96 we > don=92t care what happens if MPTCP isn=92t going to be used. > > If packets with the MP_JOIN option are dropped, the paths will simply > not be used. > > -> MUST NOT be used? > > [Alan] It=92s not a restriction, it=92s a consequence of the MPTCP handsh= ake. > If it=92s dropped, it=92s a fact it won=92t be used since the receiver ca= nnot > know the packet turning up has anything to do with an MPTCP connection. > > > Page 51: > > Should use RFC6234 instead of RFC4634 > > Page 52: > > Should use RFC5681 instead of RFC2581 > Should use draft-ietf-tcpm-secury-03 instead of -02 > Should use draft-ietf-mptcp-api-04 or 05? instead of -03 > > > There are some typos in the doc. Please update them by some tools. > > > > > ------------------------------ > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --e89a8f22c411a88d8e04c13c3188 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div class=3D"im" style=3D"font-family:'Times New Roman'">Hi Alan,<= /div><div class=3D"im" style=3D"font-family:'Times New Roman'"><br>= </div><div class=3D"im" style=3D"font-family:'Times New Roman'">Tha= nk you so much for updating the draft. I agree the updates in the draft and= comments in your mail.</div> <div class=3D"im" style=3D"font-family:'Times New Roman'">Just one = very minor thing..</div><div class=3D"im" style=3D"font-family:'Times N= ew Roman'"><br></div><div class=3D"im" style=3D"font-family:'Times = New Roman'"> >> Page 13:<br>>> =A0 =A03.1. Connection Initiation<br>>>= <br>>> =A0 =A0 -> =A0In my understanding, the key MUST be unique f= or each mptcp connection.=A0<br>>> =A0 =A0 =A0If so, I think we had b= etter articulate it here.<br> <br></div><font color=3D"#0000FF" style=3D"font-family:'Times New Roman= '">>> [Alan] Unique per host, yes. I believe that is clear alread= y; certainly, I couldn=92t find a way of making it any clearer.</font><div>= <font color=3D"#0000ff" face=3D"Times New Roman"><br> </font></div><div><font face=3D"times new roman, serif">I might be too pick= y. But, =A0I thought=A0</font><span style=3D"font-family:'times new rom= an',serif">"</span><span style=3D"font-family:'times new roman= ',serif">The key MUST be=A0</span><span style=3D"font-family:'times= new roman',serif">hard to guess, and it MUST be unique for the sending= host at any one=A0</span><span style=3D"font-family:'times new roman&#= 39;,serif">time</span><span style=3D"font-family:'times new roman',= serif">."=A0</span><font style=3D"font-family:'times new roman'= ;,serif">might not be very clear if a unique key is assigned to individual = mptcp connection or not.=A0</font></div> <div><font style=3D"font-family:'times new roman',serif">We might b= e able to guess it from "</font><span style=3D"font-family:'times = new roman',serif">Connections will be indexed at each host by the token= ", but I'm thinking explicit expression might be better..</span></= div> <div><div><font face=3D"times new roman, serif"><br></font></div><div><font= face=3D"times new roman, serif">Thanks,</font></div><div><font face=3D"tim= es new roman, serif">--</font></div><div><font face=3D"times new roman, ser= if">Yoshifumi<br> </font><br><div class=3D"gmail_quote">On Fri, May 25, 2012 at 3:17 AM, Alan= Ford <span dir=3D"ltr"><<a href=3D"mailto:alanford@cisco.com" target=3D= "_blank">alanford@cisco.com</a>></span> wrote:<br><blockquote class=3D"g= mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex"> <div> <font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:= 11pt">Hi Yoshifumi,<br> <br> Thank you for your feedback. Anything I haven=92t directly commented on bel= ow was straightforwardly addressed in =9608. If there is anything you feel = wasn=92t sufficiently addressed, please shout.<br> <br> Regards,<br> Alan<div class=3D"im"><br> <br> On 18/04/2012 07:03, "Yoshifumi Nishida" <<a href=3D"http://ni= shida@sfc.wide.ad.jp" target=3D"_blank">nishida@sfc.wide.ad.jp</a>> wrot= e:<br> <br> </div></span></font><blockquote><div class=3D"im"><span style=3D"font-size:= 11pt"><font face=3D"Times New Roman">Hi authors,<br> <br> Sorry. I would like to add one more thing. <br> <br> This draft requires to create new registries for subtypes of mptcp option a= nd cryptographic algorithms handshake in MP_CAPABLE.=A0 =A0<br> For this, you will need to add the description of the policy used for manag= ing these registries in the IANA considerations section. Please check the s= ection 4 of RFC5226 to see the available choices (Section 4.1) and update t= he texts based on the guideline (Section 4.2).<br> <br> Thanks,<br> --<br> Yoshifumi Nishida<br> </font><font face=3D"Calibri, Verdana, Helvetica, Arial"><br> <br> <br> <br> On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida <<a href=3D"http://n= ishida@sfc.wide.ad.jp" target=3D"_blank">nishida@sfc.wide.ad.jp</a>> wro= te:<br> </font></span></div><blockquote><span style=3D"font-size:11pt"><font face= =3D"Times New Roman"><div class=3D"im">Hello,<br> <br> Sorry for the long delay.<br> We believe it's good time to proceed to submit draft-ietf-mptcp-multiad= dressed to IESG.<br> <br> Here's my comments on the draft to prepare a write-up for the draft.<br= > Please check and update if you agree with them.<br> <br> Thanks,<br> --<br> Yoshifumi<br> <br> <br> Page 13:<br> =A0=A0 3.1. Connection Initiation<br> <br> =A0=A0 =A0 -> =A0In my understanding, the key MUST be unique for each mp= tcp connection. <br> =A0=A0 =A0 =A0 =A0 =A0If so, I think we had better articulate it here.<br> <br> </div><font color=3D"#0000FF">[Alan] Unique per host, yes. I believe that i= s clear already; certainly, I couldn=92t find a way of making it any cleare= r.<br> </font><div class=3D"im"><br> Page 17:<br> =A0=A0 =A0A host MUST store the Address IDs associated with all established= subflows.<br> <br> =A0=A0 =A0-> Does this mean both local Address IDs and remote Address ID= s advertized from the receiver?<br> =A0=A0 =A0 =A0 =A0It might be better to clarify this.<br> <br> </div><font color=3D"#0000FF">[Alan] Yes it does, and I have clarified that= .<br> </font><div class=3D"im"><br> Page 18:<br> =A0=A0 =A0therefore receipt of this packet MUST trigger an ACK in response<= br> <br> =A0=A0 =A0-> Since this is MUST, I think Figure 8 needs to include this = ACK in the sequence.<br> <br> <br> =A0=A0 =A0the packet MUST be retransmitted if this ACK is not received.<br> <br> =A0=A0 =A0-> In case of MP_CAPABLE, the third packet is not retransmitte= d.<br> =A0=A0 =A0 =A0 =A0But, in case of MP_JOIN, it's retransmitted. Readers = might want to know the rationale about this.<br> <br> </div><font color=3D"#0000FF">[Alan] It=92s a completely different exchange= , sending completely different information: it=92s a crypto handshake not a= key exchange. I had hoped that would have been sufficiently clear, but I= =92ve added a few words anyway.<br> </font><div class=3D"im"> =A0 <br> Page 27:<br> <br> =A0=A0 Essentially, a host MUST NOT FIN all functioning subflows unless it = is safe to do so<br> =A0=A0 <br> =A0=A0=A0 -> MUST NOT close?<br> <br> Page 28:<br> =A0<br> =A0=A0 Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to c= lean up state even if the subflow is failed.<br> =A0=A0 -> I'm not very sure which situations can be addressed by thi= s..<br> <br> </div><font color=3D"#0000FF">[Alan] Changed to =93Both hosts SHOULD send F= INs on all subflows, as a courtesy to allow middleboxes to clean up state e= ven if an individual subflow is no longer operational end-to-end.=94. This = is in the case if a link has failed in the path somewhere, but one of the e= nd hosts is behind a middlebox. That host would never receive a FIN on the = subflow, and neither would the middlebox. But the end host knows the subflo= w should be closed, so by sending a FIN it aids in cleaning up. <br> </font><div class=3D"im"><br> =A0=A0 ..<br> =A0=A0 Note that a host may also send a FIN on an individual subflow to shu= t it down, but this impact is limited to the subflow in question.<br> <br> =A0=A0 -> Sorry. I couldn't understand this sentences well..<br> <br> </div><font color=3D"#0000FF">[Alan] Changed to =93As specified above, a st= andard TCP FIN on an individual subflow only shuts down the subflow on whic= h it was sent.=94<br> </font><div class=3D"im"><br> Page 30:<br> <br> =A0=A0=A0 The sender also remembers the receive windows advertised by each = subflow.<br> =A0=A0 <br> =A0=A0=A0 -> Don't we need to put SHOULD or MUST here?<br> <br> =A0=A0=A0 The send buffer must be, at the minimum, as big as the receive bu= ffer<br> <br> =A0=A0=A0 -> MUST?<br> <br> =A0=A0=A0 When doing this, a host must still retransmit the original data o= n the original subflow,<br> =A0<br> =A0=A0=A0 -> MUST?<br> <br> Page 37:<br> <br> =A0=A0 if a response is received, the path is not removed.<br> <br> =A0=A0 a subflow that is still functioning MUST be closed with a FIN exchan= ge<br> <br> =A0=A0=A0 -> Aren't these sentences inconsistent?<br> <br> </div><font color=3D"#0000FF">[Alan] Not at all. It says you can=92t remove= a functioning subflow with REMOVE_ADDR, you must use a FIN exchange.<br> </font><div class=3D"im"><br> Page 40:<br> <br> =A0=A0 fallback to regular TCP can become necessary at any point during a c= onnection if a non-MPTCP-aware middlebox changes the data stream.<br> =A0<br> =A0=A0=A0 -> The paragraph below this suggest when multiple subflows are= in use, the affected subflow must be terminated, but not suggesting fallba= ck.<br> =A0=A0=A0=A0=A0=A0=A0=A0 So, fallback seems not to be necessary?<br> <br> =A0=A0 Therefore, it is not possible to recover the subflow, and the affect= ed subflow must be immediately closed with an RST.<br> <br> =A0=A0=A0 -> MUST?<br> <br> =A0=A0 Failed data will not be DATA_ACKed.<br> <br> =A0=A0=A0 -> MUST NOT be DATA_ACKed?<br> <br> <br> Page 47:<br> <br> =A0=A0 If this is dropped, MPTCP SHOULD fall back to regular TCP.<br> <br> =A0 =A0 -> may be MUST? since we cannot continue to use MPTCP . <br> <br> </div><font color=3D"#0000FF">[Alan] I don=92t want to restrict what implem= entations do in this state =96 we don=92t care what happens if MPTCP isn=92= t going to be used.<br> </font><div class=3D"im"><br> =A0=A0 If packets with the MP_JOIN option are dropped, the paths will simpl= y not be used.<br> <br> =A0=A0=A0 -> MUST NOT be used? <br> <br> </div><font color=3D"#0000FF">[Alan] It=92s not a restriction, it=92s a con= sequence of the MPTCP handshake. If it=92s dropped, it=92s a fact it won=92= t be used since the receiver cannot know the packet turning up has anything= to do with an MPTCP connection.<br> </font><div class=3D"im"><br> <br> Page 51:<br> <br> =A0=A0 Should use RFC6234 instead of RFC4634<br> <br> Page 52:<br> <br> =A0=A0 Should use RFC5681 instead of RFC2581<br> =A0=A0 Should use draft-ietf-tcpm-secury-03 instead of -02<br> =A0=A0 Should use draft-ietf-mptcp-api-04 or 05? instead of -03<br> <br> <br> There are some typos in the doc. Please update them by some tools.<br> <br> <br> </div></font></span></blockquote><span style=3D"font-size:11pt"><font face= =3D"Calibri, Verdana, Helvetica, Arial"><br> <br> <hr align=3D"CENTER" size=3D"3" width=3D"95%"></font></span><font><font fac= e=3D"Consolas, Courier New, Courier"><span style=3D"font-size:10pt">_______= ________________________________________<br> multipathtcp mailing list<br> <a href=3D"http://multipathtcp@ietf.org" target=3D"_blank">multipathtcp@iet= f.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/multipathtcp" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/multipathtcp</a><br> </span></font></font></blockquote> </div> </blockquote></div><br></div></div> --e89a8f22c411a88d8e04c13c3188-- From nishida@sfc.wide.ad.jp Thu May 31 03:19:57 2012 Return-Path: <nishida@sfc.wide.ad.jp> X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3769E21F8645 for <multipathtcp@ietfa.amsl.com>; Thu, 31 May 2012 03:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.876 X-Spam-Level: X-Spam-Status: No, score=-101.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joqEsJpT7NML for <multipathtcp@ietfa.amsl.com>; Thu, 31 May 2012 03:19:56 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 8553C21F863B for <multipathtcp@ietf.org>; Thu, 31 May 2012 03:19:55 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3F01B2780B5 for <multipathtcp@ietf.org>; Thu, 31 May 2012 19:19:51 +0900 (JST) Received: by lbbgo11 with SMTP id go11so767905lbb.31 for <multipathtcp@ietf.org>; Thu, 31 May 2012 03:19:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.39.135 with SMTP id p7mr768798lbk.78.1338459589575; Thu, 31 May 2012 03:19:49 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Thu, 31 May 2012 03:19:49 -0700 (PDT) In-Reply-To: <CAO249ydr0ed+sphx0iCPEcDt9WabneHKRO2jmZhyBLYzda94Rw@mail.gmail.com> References: <CAO249ydr0ed+sphx0iCPEcDt9WabneHKRO2jmZhyBLYzda94Rw@mail.gmail.com> Date: Thu, 31 May 2012 03:19:49 -0700 Message-ID: <CAO249yeLnu_syt979UCA3K0YvcGUM+mNmUjURdrh5s0KwLPpSg@mail.gmail.com> From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp> To: multipathtcp <multipathtcp@ietf.org> Content-Type: multipart/alternative; boundary=485b390f7a766203ef04c15268f5 Subject: Re: [multipathtcp] vancouver meeting slot X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp> List-Post: <mailto:multipathtcp@ietf.org> List-Help: <mailto:multipathtcp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 May 2012 10:19:57 -0000 --485b390f7a766203ef04c15268f5 Content-Type: text/plain; charset=ISO-8859-1 Hello, This is just a reminder. We haven't receive any request yet. We'll need to decide this by 6/4. We appreciate your cooperation. If there's no request, we might skip WG meeting this time. Thanks, -- Yoshifumi & Phil On Fri, May 25, 2012 at 1:11 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>wrote: > Hello folks, > > Phil and I are thinking about the WG meeting slot at vancouver. > If you are planning to make a presentation at vancouver meeting, > or, if you have some topics to be discussed at the meeting, please let us > know. > > Thanks, > -- > Yoshifumi & Phil > --485b390f7a766203ef04c15268f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,<div><br></div><div>This is just a reminder. We haven't receive a= ny request yet.</div><div>We'll need to decide this by 6/4. We apprecia= te your cooperation.</div><div>If there's no request, we might skip WG = meeting this time.=A0</div> <div><br></div><div>Thanks,</div><div>--</div><div>Yoshifumi & Phil<br>= <br><div class=3D"gmail_quote">On Fri, May 25, 2012 at 1:11 AM, Yoshifumi N= ishida <span dir=3D"ltr"><<a href=3D"mailto:nishida@sfc.wide.ad.jp" targ= et=3D"_blank">nishida@sfc.wide.ad.jp</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Hello folks,<br> <br> Phil and I are thinking about the WG meeting slot at vancouver.<br> If you are planning to make a presentation at vancouver meeting,<br> or, if you have some topics to be discussed at the meeting, please let us k= now.<br> <br> Thanks,<br> --<br> Yoshifumi & Phil<br> </blockquote></div><br></div> --485b390f7a766203ef04c15268f5-- From alanford@cisco.com Thu May 31 03:25:38 2012 Return-Path: <alanford@cisco.com> X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A87221F859B for <multipathtcp@ietfa.amsl.com>; Thu, 31 May 2012 03:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.219 X-Spam-Level: X-Spam-Status: No, score=-8.219 tagged_above=-999 required=5 tests=[AWL=0.983, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hVSICiKVaYf for <multipathtcp@ietfa.amsl.com>; Thu, 31 May 2012 03:25:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB3921F8413 for <multipathtcp@ietf.org>; Thu, 31 May 2012 03:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=4132; q=dns/txt; s=iport; t=1338459935; x=1339669535; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=QZfMOX9HqvtL9r7VYtNH8ymFq+3Xb8EmKvV3aI7GcHM=; b=kEqeIc+wE4+96Q1Boah2vL8t2K0C5izStq3v95gAzjVLJwagLEmffJhI sGBUf6zcB/j+TjAKZBWz1XOuFpGGNSHlrV92XvjR1bSiW3H5W7xlPUK3r Ms+5yU5Pt48PxT6aJ8oUasIWJv9aJuf+/t24KiZigIigdY+a3rCedduBV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALFGx0+Q/khR/2dsb2JhbABEgkWwPIEKgQeCGAEBAQMBAQEBDwEqMRANAQgEFFUwAQEEARIih2QFC5kTn2YEixGFRgOIDY0Ljg2BZoJhgVUF X-IronPort-AV: E=Sophos;i="4.75,691,1330905600"; d="scan'208,217";a="138881712" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 31 May 2012 10:25:34 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4VAPYZo027604; Thu, 31 May 2012 10:25:34 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 May 2012 12:25:34 +0200 Received: from 10.61.101.110 ([10.61.101.110]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 May 2012 10:25:33 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Thu, 31 May 2012 11:25:32 +0100 From: Alan Ford <alanford@cisco.com> To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, multipathtcp <multipathtcp@ietf.org> Message-ID: <CBED05AC.A5EB%alanford@cisco.com> Thread-Topic: [multipathtcp] vancouver meeting slot Thread-Index: Ac0/F7Usg59ScKHpwEuBurijHEGQEA== In-Reply-To: <CAO249yeLnu_syt979UCA3K0YvcGUM+mNmUjURdrh5s0KwLPpSg@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3421308333_12087802" X-OriginalArrivalTime: 31 May 2012 10:25:34.0166 (UTC) FILETIME=[B676F760:01CD3F17] Subject: Re: [multipathtcp] vancouver meeting slot X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp> List-Post: <mailto:multipathtcp@ietf.org> List-Help: <mailto:multipathtcp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 May 2012 10:25:38 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3421308333_12087802 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I will be in Vancouver and would be happy to provide an update on the protocol. However, there=B9s really not much to say. It would seem most appropriate to discuss new-charter-related stuff. I do not have anything myself, however. Regards, Alan On 31/05/2012 11:19, "Yoshifumi Nishida" <nishida@sfc.wide.ad.jp> wrote: > Hello, >=20 > This is just a reminder. We haven't receive any request yet. > We'll need to decide this by 6/4. We appreciate your cooperation. > If there's no request, we might skip WG meeting this time.=A0 >=20 > Thanks, > -- > Yoshifumi & Phil >=20 > On Fri, May 25, 2012 at 1:11 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.j= p> > wrote: >> Hello folks, >>=20 >> Phil and I are thinking about the WG meeting slot at vancouver. >> If you are planning to make a presentation at vancouver meeting, >> or, if you have some topics to be discussed at the meeting, please let u= s >> know. >>=20 >> Thanks, >> -- >> Yoshifumi & Phil >=20 >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --B_3421308333_12087802 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [multipathtcp] vancouver meeting slot I will be in Vancouver and would be happy to provide an update on the prot= ocol. However, there’s really not much to say.

It would seem most appropriate to discuss new-charter-related stuff. I do n= ot have anything myself, however.

Regards,
Alan


On 31/05/2012 11:19, "Yoshifumi Nishida" <nishida@sfc.wide.ad.jp> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hello,

This is just a reminder. We haven't receive any request yet.
We'll need to decide this by 6/4. We appreciate your cooperation.
If there's no request, we might skip WG meeting this time.=A0

Thanks,
--
Yoshifumi & Phil

On Fri, May 25, 2012 at 1:11 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Hello folks,

Phil and I are thinking about the WG meeting slot at vancouver.
If you are planning to make a presentation at vancouver meeting,
or, if you have some topics to be discussed at the meeting, please let us k= now.

Thanks,
--
Yoshifumi & Phil
=

___________= ____________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ie= tf.org/mailman/listinfo/multipathtcp




 --B_3421308333_12087802-- From Rolf.Winter@neclab.eu Thu May 31 05:46:49 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A452221F8683 for ; Thu, 31 May 2012 05:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3aC7d3AjznO for ; Thu, 31 May 2012 05:46:49 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC6A21F867E for ; Thu, 31 May 2012 05:46:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 442381005A6; Thu, 31 May 2012 14:47:00 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M64EUflYZGRt; Thu, 31 May 2012 14:47:00 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 2B91A1005C0; Thu, 31 May 2012 14:46:50 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.172]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 31 May 2012 14:46:38 +0200 From: Rolf Winter To: Yoshifumi Nishida , multipathtcp Thread-Topic: [multipathtcp] vancouver meeting slot Thread-Index: AQHNOk4DmV2UMFSynkm0Si8coQEAAZbjl66AgABJScA= Date: Thu, 31 May 2012 12:46:37 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D250F39E6@Polydeuces.office.hd> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.203] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multipathtcp] vancouver meeting slot X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 12:46:49 -0000 Hi, I could present http://tools.ietf.org/html/draft-wr-mptcp-single-homed-02. = I hope to have a significant delta to this version by the cut-off date. So = hopefully there will be new material to be discussed. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of Yoshifumi Nishida > Sent: Donnerstag, 31. Mai 2012 12:20 > To: multipathtcp > Subject: Re: [multipathtcp] vancouver meeting slot >=20 > Hello, >=20 > This is just a reminder. We haven't receive any request yet. > We'll need to decide this by 6/4. We appreciate your cooperation. > If there's no request, we might skip WG meeting this time. >=20 > Thanks, > -- > Yoshifumi & Phil >=20 >=20 > On Fri, May 25, 2012 at 1:11 AM, Yoshifumi Nishida > wrote: >=20 >=20 > Hello folks, >=20 > Phil and I are thinking about the WG meeting slot at vancouver. > If you are planning to make a presentation at vancouver meeting, > or, if you have some topics to be discussed at the meeting, > please let us know. >=20 > Thanks, > -- > Yoshifumi & Phil >=20 >=20