From philip.eardley@bt.com Mon Nov 2 09:08:04 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6292128C1BB for ; Mon, 2 Nov 2009 09:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCkI6JvH2iUO for ; Mon, 2 Nov 2009 09:08:01 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 140D428C1B6 for ; Mon, 2 Nov 2009 09:08:00 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 17:08:19 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5BDF.135E9CDB" Date: Mon, 2 Nov 2009 17:08:19 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363A5F@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed process - towards our first Milestone Thread-Index: Acpb3xNn1VbDeL6FQdWjJb4YvfNZyg== From: To: X-OriginalArrivalTime: 02 Nov 2009 17:08:19.0699 (UTC) FILETIME=[1387EC30:01CA5BDF] Subject: [multipathtcp] Proposed process - towards our first Milestone X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:08:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5BDF.135E9CDB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Our first Milestone is for March 2010, "Established WG consensus on the Architecture" - ie the high-level design decisions (about the protocol, congestion control, API, security, modularity). =20 Our proposed process - please shout with any suggestions /improvements - is the following. =20 The WG will discuss the high-level design decisions /architecture over the next month or two, including at Hiroshima. They will be captured in a single document which will be WG last called in Feb (at the latest), to allow time for a revised version before the March IETF cut-off. We will then resolve any remaining issues at the March meeting. =20 Best wishes, Phil & Yoshifumi ------_=_NextPart_001_01CA5BDF.135E9CDB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our first Milestone is for March 2010, = “Established WG consensus on the Architecture” – ie the high-level design = decisions (about the protocol, congestion control, API, = security, modularity).

 

Our proposed process - please shout with any = suggestions /improvements – is the following.

 

The WG will discuss the high-level design decisions = /architecture over the next month or two, including at Hiroshima. They will be captured in a single document which will be WG last called in Feb (at = the latest), to allow time for a revised version before the March IETF = cut-off. We will then resolve any remaining issues at the March = meeting.

 

Best wishes,

Phil & Yoshifumi

=00 ------_=_NextPart_001_01CA5BDF.135E9CDB-- From philip.eardley@bt.com Mon Nov 2 09:47:44 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662BE3A68D6 for ; Mon, 2 Nov 2009 09:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xdhKlZDWrK1 for ; Mon, 2 Nov 2009 09:47:36 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 45A193A6831 for ; Mon, 2 Nov 2009 09:47:35 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 17:47:54 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5BE4.9B28378F" Date: Mon, 2 Nov 2009 17:47:54 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: High-level design decisions /architecture Thread-Index: Acpb5JtVyCJMgKRdQLqhkxWfqx2wUQ== From: To: X-OriginalArrivalTime: 02 Nov 2009 17:47:54.0929 (UTC) FILETIME=[9B474210:01CA5BE4] Subject: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:47:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5BE4.9B28378F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 In order to help the process of reaching consensus on the high-level design decisions /architecture, we have gone through the current set of I-Ds to identify items that seem like they may fall into the category of high-level design decisions - see below. Note: this list is not to meant to imply our support or non-support of these items (except where our charter requires our support!); the purpose is to identify what needs to be discussed. =20 Please shout if there's something we misunderstood or missed. =20 Please let the WG know your opinions on these items - especially if your disagree with any, have a potential alternative, or think something is part of 'detailed design' and not 'high-level design'. =20 Thanks Phil & Yoshifumi =20 =20 Protocol-related =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * IPv4 & IPv6 will have the same high-level design=20 * [Comment: the Charter implies both v4 & v6 are in scope] * The MPTCP connection is identified, from an apps perspective, by the addresses associated with the original path (even if that subflow /path closes)=20 * A SYN/ACK exchange (on a single path) checks that both ends support MPTCP, with automatic fall-back to TCP if not=20 * each MPTCP subflow looks exactly like an ordinary, semantically independent TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are independent on each subflow=20 * control of the MPTCP connection (as opposed to the subflows) is carried in TCP options, eg DATA FIN for closing an MPTCP connection=20 * the protocol involves an MPTCP stack at both ends of the MPTCP connection=20 * [Comment: this is in our charter]=20 * Either end of the MPTCP connection can add or remove paths to/from the MPTCP connection=20 * [Comment / Question: this seemed a bit unclear in the protocol i-d, but is presumably required?]=20 * Subflow end point definition * [Question: Should we allow subflows in a single MPTCP connection to have different ports?]=20 =20 =20 Congestion algorithm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * the goals are: [1] MPTCP is at least as good as TCP would be on the best subflow path; [2] on any path, an MPTCP connection uses less (or the same) capacity as a TCP connection would do; [3] MPTCP moves traffic off more congested paths and onto less congested ones=20 * increases in the congestion windows of the subflows are coupled; for decreases in the congestion windows, each subflow does new reno independently (ie they are not coupled)=20 * slow start, fast re-transmit and fast recovery are the same as RFC5681=20 =20 =20 API =3D=3D=3D * no changes to existing apps are needed to use MPTCP; MPTCP uses the unaltered TCP socket API=20 * There is an optional, extended API=20 * [Question: would both ends need the extended API, with a fall-back if not?]=20 * [Comment: presumably the actual features of the extended API are outside the initial high-level design decisions]=20 * congestion control state is shared among application-visible transport instances (eg multiple HTTPs between the same pair of hosts)=20 * 3 application profiles are mentioned (Bulk data transport, Latency-sensitive transport with overflow, Latency-sensitive transport with hot stand by)=20 * [Question: how are these supported? Is a negotiation mechanism needed?] =20 =20 =20 Security =3D=3D=3D=3D=3D=3D * exchange a token in the initial SYN for the MPTCP connection, and include the token when subflows /paths are added to the connection=20 * [Question: Is the same token used whether the sender or receiver (of the MPTCP connection) adds the subflow? Is the same technique used for removing subflows? And closing connections, ie DATA FIN?]=20 * security mechanisms will not interfere with end-to-end authentication etc and will be compatible with legacy middleboxes=20 =20 =20 Modularity =3D=3D=3D=3D=3D=3D=3D=3D * the architecture has 2 components, multipath scheduler & path manager - meaning that improved /different modules of each can be slotted in=20 o [Comment: it is unclear from the Architecture i-d how the congestion control & protocol i-ds map to these components; some of the text (strangely?) appears in a section about implementation] o [Question: what are the mechanisms for evolvability? How is it negotiated which new module (for congestion control or path manager) to use?] o [Question: this would seem to imply we need to define an interface between the modules?] * there is a default path manager module, meaning it is the MUST fall-back option =20 o [Comment: the charter restricts us - the path manager we work on will distinguish paths by multiple addresses] ------_=_NextPart_001_01CA5BE4.9B28378F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

In order to help the process of reaching consensus on = the high-level design decisions /architecture, we have gone through the = current set of I-Ds to identify items that seem like they may fall into the category = of high-level design decisions – see below. Note: this list is not to meant to = imply our support or non-support of these items (except where our charter = requires our support!); the purpose is to identify what needs to be = discussed.

 

Please shout if there’s something we = misunderstood or missed.

 

Please let the WG know your opinions on these items = – especially if your disagree with any, have a potential alternative, or = think something is part of ‘detailed design’ and not = ‘high-level design’.

 

Thanks

Phil & Yoshifumi

 

 

Protocol-related

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=
  • IPv4 & IPv6 will have the same high-level = design
    • [Comment: the Charter implies both v4 & v6 = are in scope]
  • The MPTCP connection is identified, from an apps perspective, by the addresses associated with the original path = (even if that subflow /path closes)
  • A SYN/ACK = exchange (on a single path) checks that both ends support MPTCP, with automatic fall-back to TCP if not =
  • each MPTCP subflow looks exactly like an = ordinary, semantically independent TCP = flow. MPTCP effectively runs on top. So re-transmission, FINs etc are = independent on each subflow
  • control of the MPTCP connection (as opposed to = the subflows) is carried in TCP = options, eg DATA FIN for closing an MPTCP connection
  • the protocol involves an MPTCP stack at both = ends of the MPTCP connection
    • [Comment: this is in our charter] =
  • Either end of the MPTCP connection can add or = remove paths to/from the MPTCP connection
    • [Comment / Question: this seemed a bit unclear = in the protocol i-d, but is presumably required?]
  • Subflow end point definition
    • [Question: Should we allow subflows in a single = MPTCP connection to have different ports?]

 

 

Congestion algorithm

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  • the goals are: [1] MPTCP is at least as good as = TCP would be on the best subflow path; [2] on any path, an MPTCP connection = uses less (or the same) capacity as a TCP = connection would do; [3] MPTCP moves traffic off more congested paths and onto = less congested ones
  • increases in the congestion windows of the = subflows are coupled; for decreases in the congestion windows, each subflow does = new reno independently (ie they are not coupled)
  • slow start, fast re-transmit and fast recovery = are the same as RFC5681

 

 

API

=3D=3D=3D

  • no changes to existing apps are needed to use = MPTCP; MPTCP uses the unaltered TCP = socket API
  • There is an optional, extended = API
    • [Question: would both ends need the extended = API, with a fall-back if not?]
    • [Comment: presumably the actual features of the extended API are outside the = initial high-level design decisions]
  • congestion control state is shared among application-visible transport instances (eg multiple HTTPs between = the same pair of hosts)
  • 3 application profiles are mentioned (Bulk data transport, Latency-sensitive transport with overflow, = Latency-sensitive transport with hot stand by)
    • [Question: how are these supported? Is a = negotiation mechanism = needed?]        &nb= sp;  

 

 

Security

=3D=3D=3D=3D=3D=3D

  • exchange a token in the initial SYN for the = MPTCP connection, and include the token when subflows /paths are added to = the connection
    • [Question: Is the same token used whether the = sender or receiver (of the MPTCP connection) adds the subflow? Is the = same technique used for removing subflows? And closing connections, ie = DATA FIN?]
  • security mechanisms will not interfere with = end-to-end authentication etc and will be compatible with legacy = middleboxes

 

 

Modularity

=3D=3D=3D=3D=3D=3D=3D=3D

·        = ; the architecture has 2 components, multipath scheduler & path manager – meaning that improved /different modules of each can be = slotted in

o        [Comment: it is unclear from the Architecture i-d how the = congestion control & protocol i-ds map to these components; some of the text = (strangely?) appears in a section about implementation]

o        [Question: what are the mechanisms for evolvability? How is it negotiated which new module (for congestion control or path manager) to = use?]

o        [Question: this would seem to imply we need to define an = interface between the modules?]

·        = ; there is a default path manager module, meaning it is the MUST = fall-back option =             &= nbsp;           &n= bsp;           &nb= sp;           =

o        [Comment: the charter restricts us - the path manager we work on = will distinguish paths by multiple addresses]

=00 ------_=_NextPart_001_01CA5BE4.9B28378F-- From marcelo@it.uc3m.es Mon Nov 2 11:27:51 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA2E3A67DD for ; Mon, 2 Nov 2009 11:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbUuHax6fB14 for ; Mon, 2 Nov 2009 11:27:50 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 1BF8628C104 for ; Mon, 2 Nov 2009 11:27:49 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.31.227]) by smtp03.uc3m.es (Postfix) with ESMTP id 6782A7F43C3; Mon, 2 Nov 2009 20:28:08 +0100 (CET) Message-ID: <4AEF32BB.7020103@it.uc3m.es> Date: Mon, 02 Nov 2009 20:27:55 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16986.000 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 19:27:51 -0000 philip.eardley@bt.com escribió: > > Security > > ====== > > * exchange a token in the initial SYN for the MPTCP connection, > and include the token when subflows /paths are added to the > connection > o [Question: Is the same token used whether the sender or > receiver (of the MPTCP connection) adds the subflow? Is > the same technique used for removing subflows? And closing > connections, ie DATA FIN?] > I have been thinking about alternatives mechanisms that without requiring heavy crypto would remove the threats from passive on path attackers that can laucnhh attacks to the token based security (and require the attacker to actively change the traffic in order to launch the attack). I think this could be worth considering since the work required by the I haven't been able to write an ID about that just yet, but i was hoping to do something in the few next weeks. Regards, marcelo > o > > > > > * security mechanisms will not interfere with end-to-end > authentication etc and will be compatible with legacy middleboxes > > Modularity > > ======== > > · the architecture has 2 components, multipath scheduler & path > manager – meaning that improved /different modules of each can be > slotted in > > o [Comment: it is unclear from the Architecture i-d how the congestion > control & protocol i-ds map to these components; some of the text > (strangely?) appears in a section about implementation] > > o [Question: what are the mechanisms for evolvability? How is it > negotiated which new module (for congestion control or path manager) > to use?] > > o [Question: this would seem to imply we need to define an interface > between the modules?] > > · there is a default path manager module, meaning it is the MUST > fall-back option > > o [Comment: the charter restricts us - the path manager we work on > will distinguish paths by multiple addresses] > > ------------------------------------------------------------------------ > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From wherrin@gmail.com Mon Nov 2 13:28:38 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A4F28C0F3 for ; Mon, 2 Nov 2009 13:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oek+1HNIz62M for ; Mon, 2 Nov 2009 13:28:37 -0800 (PST) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id C1E0A28C0E9 for ; Mon, 2 Nov 2009 13:28:36 -0800 (PST) Received: by ewy18 with SMTP id 18so4856903ewy.43 for ; Mon, 02 Nov 2009 13:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=LJqvuDlFjiwtxhWZJn0rMa6ByFBHTozzcvFyuF3zY74=; b=dOWTJcG4yTwkkmFoynV3or8tjFg3EmieadALKQeqy5GduvFnH6ZmJt0T+kLnm9BlZ3 TlujDFlQd7/OIA8BbGgfSYLNx2CJ9MJRmsk7tqWYXJ9Lwg+N4imhbJgcQ4uVhfuLFmiG oLM5tUjSJL58YJP45YSzb0cPMQzH/Pop81w0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=eGnT23M3o5nUnXSUGN55CtJ7JZCH1qYUH6sPAJyIbUW8XDipX0pszqeuw1LwR+Ay+h g2vhpXgFosod70cLLxO4dUmi1CUw6BiANTuEseDR7wbQg5nBOBudhwWDTNYVtBiFEL4C lw6BeU/EKBuiFt922Fx4qKC2Mry4Opm1qFZHg= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.85.5 with SMTP id t5mr5230773wee.142.1257197332457; Mon, 02 Nov 2009 13:28:52 -0800 (PST) In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> Date: Mon, 2 Nov 2009 17:28:52 -0400 X-Google-Sender-Auth: 7a74bdccdfcdf2a0 Message-ID: <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> From: William Herrin To: philip.eardley@bt.com Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 21:28:38 -0000 On Mon, Nov 2, 2009 at 1:47 PM, wrote: Hi Philip, Apologies if any of this rehashes discussions you've already had. > The MPTCP connection is identified, from an apps perspective, by the > addresses associated with the original path (even if that subflow /path > closes) I'm concerned about this idea. One of the corner cases where shim6 falls apart is: once the connection migrates away from the original addresses, how do the endpoints decide whether a new connection request for the original addresses means the migrated addresses or the current holder of the addresses? Think: FTP. > A SYN/ACK exchange (on a single path) checks that both ends support MPTCP, > with automatic fall-back to TCP if not We have an awful lot of TCP options that are only valid in the SYN-SYN/ACK exchange and only 40 bytes to put them all. What's wrong with starting all TCP connections in non-MP mode and allowing the connection's initiator to request MPTCP starting with any packet that expects an ACK? > each MPTCP subflow looks exactly like an ordinary, semantically independent > TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are > independent on each subflow I'm almost sold on the idea of subflows. Can you give me a run down on the pros and cons, particularly the cons? Thanks, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marcelo@it.uc3m.es Mon Nov 2 14:45:41 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045353A67F3 for ; Mon, 2 Nov 2009 14:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM4YMEWsG40b for ; Mon, 2 Nov 2009 14:45:40 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 254DE3A67F1 for ; Mon, 2 Nov 2009 14:45:39 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.31.227]) by smtp03.uc3m.es (Postfix) with ESMTP id EB5EC7F4480; Mon, 2 Nov 2009 23:45:54 +0100 (CET) Message-ID: <4AEF6114.6070106@it.uc3m.es> Date: Mon, 02 Nov 2009 23:45:40 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: William Herrin References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> In-Reply-To: <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16986.000 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 22:45:41 -0000 William Herrin escribió: > On Mon, Nov 2, 2009 at 1:47 PM, wrote: > > Hi Philip, > > Apologies if any of this rehashes discussions you've already had. > > >> The MPTCP connection is identified, from an apps perspective, by the >> addresses associated with the original path (even if that subflow /path >> closes) >> > > I'm concerned about this idea. One of the corner cases where shim6 > falls apart is: once the connection migrates away from the original > addresses, how do the endpoints decide whether a new connection > request for the original addresses means the migrated addresses or the > current holder of the addresses? Think: FTP. > could you expand on this? I wasn't aware shim6 falls apart in any case neither this particular approach... Regards, marcelo > > >> A SYN/ACK exchange (on a single path) checks that both ends support MPTCP, >> with automatic fall-back to TCP if not >> > > We have an awful lot of TCP options that are only valid in the > SYN-SYN/ACK exchange and only 40 bytes to put them all. What's wrong > with starting all TCP connections in non-MP mode and allowing the > connection's initiator to request MPTCP starting with any packet that > expects an ACK? > > > >> each MPTCP subflow looks exactly like an ordinary, semantically independent >> TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are >> independent on each subflow >> > > I'm almost sold on the idea of subflows. Can you give me a run down on > the pros and cons, particularly the cons? > > Thanks, > Bill Herrin > > > From wherrin@gmail.com Mon Nov 2 15:38:29 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1503A6934 for ; Mon, 2 Nov 2009 15:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQOVY+bYbxFv for ; Mon, 2 Nov 2009 15:38:28 -0800 (PST) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id 5AFA13A6919 for ; Mon, 2 Nov 2009 15:38:28 -0800 (PST) Received: by ewy18 with SMTP id 18so4971231ewy.43 for ; Mon, 02 Nov 2009 15:38:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=HYFq+cHwcwun3uDXW0D8PxBE0rHVNCDgxlbXFZg822o=; b=T62TOOvUSjWB2caMAffjN2sRRjSHZMlAggxi4NRkbQwz00r5beyLm1lIqS42kSa1zd 6rkFIomWJHjngMu4Axsw5cp1lEwgn2KQQqG6tKca7WU2Z6VKWpRADUidwR6hJk31MEyg DBGgLWyfjMgrzkQxUmHXG6Rf/gKs/F4nTVU0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=a/f5EbSFqQiD3A+HEH7Cy/p/syi5cjaSQnKPagz5/wELm1w0mSZsdbLjiclJWUAh80 NBk+HRR710LpZ8j0+Zm96RNaHHJE3DimMlYpoy8q0QVCiLoi3c+Q5hbA6KpbNX98S1tX nOqLC+AY38jLLaago0urwtwVPHUkUl98s8PrU= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.85.5 with SMTP id t5mr5399993wee.142.1257205126330; Mon, 02 Nov 2009 15:38:46 -0800 (PST) In-Reply-To: <4AEF6114.6070106@it.uc3m.es> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> Date: Mon, 2 Nov 2009 19:38:46 -0400 X-Google-Sender-Auth: 7f14d9c709f23c5f Message-ID: <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> From: William Herrin To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 23:38:29 -0000 On Mon, Nov 2, 2009 at 6:45 PM, marcelo bagnulo braun wrote: >> I'm concerned about this idea. One of the corner cases where shim6 >> falls apart is: once the connection migrates away from the original >> addresses, how do the endpoints decide whether a new connection >> request for the original addresses means the migrated addresses or the >> current holder of the addresses? Think: FTP. >> > > could you expand on this? > I wasn't aware shim6 falls apart in any case neither this particular > approach... Hi Marcelo, Consider the following scenario: Host A comes online with 1.2.3.4. Host A requests a new TCP connection to 5.6.7.8. Established with host B at 5.6.7.8. Host B adds 8.7.6.5 Host B removes 5.6.7.8 Host C comes online with 5.6.7.8. Host A requests a new TCP connection to 5.6.7.8. Which host does A connect to? If the answer is C, protocols like FTP which initiate multiple TCP connections to the same IP address fail once an endpoint gives up its original address. That'll also impact web browsers which employ dns pinning. If the answer is B, I can hijack hotmail's IPs with respect to your mail server for the few fractions of a second it takes to establish and move a TCP connection over to an IP address I legitimately control. You'll then indefinitely send subsequent hotmail-addressed email to me. If I diligently pass it on to hotmail, you may never even know. If we identify the connection by the original IP address even after that address is gone, effectively lying to the application, we can induce it to incorrect behavior. That can have security implications that may be hard to get a handle on. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From touch@ISI.EDU Mon Nov 2 15:44:36 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514993A67F4 for ; Mon, 2 Nov 2009 15:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHWtt2AgAE5s for ; Mon, 2 Nov 2009 15:44:35 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 67ABC3A67D7 for ; Mon, 2 Nov 2009 15:44:32 -0800 (PST) Received: from [75.212.97.118] (118.sub-75-212-97.myvzw.com [75.212.97.118]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA2NiWYb003739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Nov 2009 15:44:35 -0800 (PST) Message-ID: <4AEF6EE0.1080500@isi.edu> Date: Mon, 02 Nov 2009 15:44:32 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: William Herrin References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> In-Reply-To: <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 23:44:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 William Herrin wrote: ... > If we identify the connection by the original IP address even after > that address is gone, effectively lying to the application, we can > induce it to incorrect behavior. That can have security implications > that may be hard to get a handle on. This is the reason I raised the issue of "as goes the original IP address, so goes the connection" during the Stockholm meeting. I can see how to make things work when this is true, basically by authenticating based on this address pair rather than the address pair in the packet. If not, as noted above, there's an opportunity for hijacking (if malicious), or at least unintended behavior (if not). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrvbuAACgkQE5f5cImnZrvgGgCg0qhfw/7eem7uIwnDD25uYCsJ tzQAn3A0mqarLjV3BMNtL5otuZnFdfpO =J+kU -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Nov 2 16:24:04 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA0628C135 for ; Mon, 2 Nov 2009 16:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HedZ1usteczS for ; Mon, 2 Nov 2009 16:24:03 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BE6FA3A67A3 for ; Mon, 2 Nov 2009 16:24:03 -0800 (PST) Received: from [75.212.97.118] (118.sub-75-212-97.myvzw.com [75.212.97.118]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA30O145013062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Nov 2009 16:24:04 -0800 (PST) Message-ID: <4AEF781E.4070009@isi.edu> Date: Mon, 02 Nov 2009 16:23:58 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 00:24:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'll jump in here ;-) philip.eardley@bt.com wrote: ... > Protocol-related > > ============ > > * IPv4 & IPv6 will have the same high-level design > o [Comment: the Charter implies both v4 & v6 are in scope] Definitely. > * The MPTCP connection is identified, from an apps perspective, by > the addresses associated with the original path Yes, IMO. > (even if that > subflow /path closes) Yes, although, as noted, if the IP address goes away altogether, then IMO the connection needs to be terminated. > * A SYN/ACK exchange (on a single path) checks that both ends > support MPTCP, with automatic fall-back to TCP if not Yes, with as few bytes as possible. > * each MPTCP subflow looks exactly like an ordinary, semantically > independent TCP flow. MPTCP effectively runs on top. So > re-transmission, FINs etc are independent on each subflow Don't care. Seems to make sense for middleboxes that track such things, but IMO they shouldn't care either, esp. since the packets could be encrypted. > * control of the MPTCP connection (as opposed to the subflows) is > carried in TCP options, eg DATA FIN for closing an MPTCP connection I disagree. The option stream is neither reliable or ordered, and so it's a bad idea to put state management there. If you want a control channel, open a separate connection IMO. > * the protocol involves an MPTCP stack at both ends of the MPTCP > connection > o [Comment: this is in our charter] Agreed (as per the charter), but seriously this begs the question of what is "TCP" about the result. I don't like the idea of doing this all inside TCP solely as NAT camouflage. > * Either end of the MPTCP connection can add or remove paths to/from > the MPTCP connection > o [Comment / Question: this seemed a bit unclear in the > protocol i-d, but is presumably required?] Depends on when the paths are created. If they are created at SYN time, then it's OK IMO to develop support asymmetrically. If they can be created once open, AFAICT TCP is memoryless w.r.t. who opened the connection, so I can't see why either side would have privileged rights (or could even tell). > * Subflow end point definition > o [Question: Should we allow subflows in a single MPTCP > connection to have different ports?] Seems like you'd have to - or you have to coordinate port use on different addresses at a single endpoint constantly. > Congestion algorithm > > =============== > > * the goals are: [1] MPTCP is at least as good as TCP would be on > the best subflow path; [2] on any path, an MPTCP connection uses > less (or the same) capacity as a TCP connection would do; [3] > MPTCP moves traffic off more congested paths and onto less > congested ones These sound OK, though it might be useful to consider that [1] and [2] are requirements (IMO), where [3] is an optimization goal, and thus OK to break. > * increases in the congestion windows of the subflows are coupled; > for decreases in the congestion windows, each subflow does new > reno independently (ie they are not coupled) I would assume that both increases and decreases are not coupled. If they are, it seems like a subflow could use bandwidth on one path to justify being more aggressive on another, which seems to violate [2] above. > * slow start, fast re-transmit and fast recovery are the same as > RFC5681 Yes. > API > > === > > * no changes to existing apps are needed to use MPTCP; MPTCP uses > the unaltered TCP socket API I would say this in a way that flows into the next idea below better, e.g., "no changes are required to use MPTCP in its simplest mode". > * There is an optional, extended API > o [Question: would both ends need the extended API, with a > fall-back if not?] Seems like one end could want the extended API for explicit control of flows, but the other end doesn't need to care. > o [Comment: presumably the actual features of the extended API > are outside the initial high-level design decisions] > * congestion control state is shared among application-visible > transport instances (eg multiple HTTPs between the same pair of > hosts) IMO (RFC2140, e.g.), yes ;-) > * 3 application profiles are mentioned (Bulk data transport, > Latency-sensitive transport with overflow, Latency-sensitive > transport with hot stand by) > o [Question: how are these supported? Is a negotiation > mechanism needed?] Seems at odds with the claims above for [1],[2],[3]. I.e., bulk transport seems compatible with all three, but latency-sensitive seems like it might not be compatible with any of these. > Security > > ====== > > * exchange a token in the initial SYN for the MPTCP connection, and > include the token when subflows /paths are added to the connection > o [Question: Is the same token used whether the sender or > receiver (of the MPTCP connection) adds the subflow? Is the > same technique used for removing subflows? And closing > connections, ie DATA FIN?] Let's please not call this "security". Call it a flow identifier, but it's trivial for on-path attackers to see, and anything small enough to be appropriate for a SYN is likely to be too small to prevent exhaustion attacks. > * security mechanisms will not interfere with end-to-end > authentication etc Yes. Specifically IMO there ought to be a TCP-AO mode supported - e.g., using socketpair of the original connection for the pseudoheader used for MAC calculation. (i.e., where this mentions "security mechanisms" I think of TCP-AO, not a nonce) > and will be compatible with legacy middleboxes Well, legacy middleboxes do all sorts of nasty things - many of which are more correctly considered attacks - so this can't be a requirement as worded. E.g., some middleboxes remove unknown options. That's clearly going to break things here. Others change packet boundaries (splitting, joining, etc.). Others rewrite all sorts of header fields. IMO, be more specific about what you would like to support (e.g., simple NATs), and make this a goal, not a requirement. > Modularity > > ======== > > · the architecture has 2 components, multipath scheduler & path > manager – meaning that improved /different modules of each can be > slotted in This seems to confuse architecture with implementation. Although they are specified separately, an implementation might conflate the two to the point where it cannot be modularly modified. I don't know what you're going for here, but IMO just state that they're independently *specified*. > o [Comment: it is unclear from the Architecture i-d how the > congestion control & protocol i-ds map to these components; some of the > text (strangely?) appears in a section about implementation] That might be a place where the implementation cannot reasonably separate the two specification issues. > o [Question: what are the mechanisms for evolvability? How is it > negotiated which new module (for congestion control or path manager) to > use?] This seems like an independent question, i.e., how are versions of the protocol identified and established for each connection? > o [Question: this would seem to imply we need to define an > interface between the modules?] Sounds suspiciously like an API - which I think is needed, and is a good idea, but you ought to get buy-in on this, since it's intraprotocol, and could be easily confused with an implementation issue. It'd be important to make sure this is an architecture interface, not an implementation one. > · there is a default path manager module, meaning it is the MUST > fall-back option > > o [Comment: the charter restricts us - the path manager we work > on will distinguish paths by multiple addresses] See above - version issue. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrveB4ACgkQE5f5cImnZrvxfACg4p2+t723PQIFk8OPB4l1wVfI fY8AoPENpgkIi56NIWerwlGQT9A4uv4a =4eEh -----END PGP SIGNATURE----- From mark.j.handley@gmail.com Mon Nov 2 16:40:41 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751023A6847 for ; Mon, 2 Nov 2009 16:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2KhDEk3+0JV for ; Mon, 2 Nov 2009 16:40:39 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 9AE9E3A6820 for ; Mon, 2 Nov 2009 16:40:38 -0800 (PST) Received: by bwz23 with SMTP id 23so7009895bwz.29 for ; Mon, 02 Nov 2009 16:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=VGVzlRyvN/77rprLG7zsuccNQDRpHb93mc2kn+u4SxA=; b=LRNLb7/wDMwP2r93gqrIXlQ16A2i63kkqSDN4IxvhDwL+CxYpP1iWvp228RRMqtNYC bsbHZG1S0nsahXQwHkNIS82ksojHMTu8/cxbVqza9VP9rYywWoqK58WGXJMAohdZqwnd lrwUtl4hpeB8v4tabd1SHMBHoWPnBGGMv4WvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=jabzSyfOsAm2l6L3PPOaSo3Otub3p7E7DVtUfvvK6nFlMADtjYSTuVdOjCxqaIwmNH Nhq7JHf+DjwqBYsqXfD52VyWhAQ0N3ooXmIyy/Jnxi1xcOmrAI2Ilmy135GE0jRiCEOa cx5zfDWRa31GRrJGkB3mSd4Bz9XfpxAmF0LuU= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.16.72 with SMTP id n8mr838958faa.26.1257208854259; Mon, 02 Nov 2009 16:40:54 -0800 (PST) In-Reply-To: <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> From: Mark Handley Date: Tue, 3 Nov 2009 00:40:34 +0000 X-Google-Sender-Auth: 4dc22fe94be2c2a6 Message-ID: <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> To: William Herrin Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 00:40:42 -0000 2009/11/2 William Herrin : > Consider the following scenario: > > Host A comes online with 1.2.3.4. > Host A requests a new TCP connection to 5.6.7.8. > Established with host B at 5.6.7.8. > Host B adds 8.7.6.5 > Host B removes 5.6.7.8 > Host C comes online with 5.6.7.8. > Host A requests a new TCP connection to 5.6.7.8. > > Which host does A connect to? I'm not sure I see the problem. When host B removes 5.6.7.8, that address is removed from that connection only. It has no relation with any other connections, ongoing or future. If A has any other connections with 5.6.7.8, they are unaffected (after all, 5.6.7.8 may be a NAT with several hosts behind it) unless they also explicitly remove the address. When A requests a new TCP connection to 5.6.7.8, that's what A's app specified at that moment in the connect call, and that's the address the SYN will be sent to. No previous behaviour for any other connection affects that. - Mark From touch@ISI.EDU Mon Nov 2 17:03:52 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40BA13A6862 for ; Mon, 2 Nov 2009 17:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyoGNmzMwjLh for ; Mon, 2 Nov 2009 17:03:51 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 78DEA3A684C for ; Mon, 2 Nov 2009 17:03:51 -0800 (PST) Received: from [75.212.97.118] (118.sub-75-212-97.myvzw.com [75.212.97.118]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA30uJSV020781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Nov 2009 16:56:22 -0800 (PST) Message-ID: <4AEF7FB3.4020604@isi.edu> Date: Mon, 02 Nov 2009 16:56:19 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Handley References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> In-Reply-To: <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 01:03:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Handley wrote: > 2009/11/2 William Herrin : >> Consider the following scenario: >> >> Host A comes online with 1.2.3.4. >> Host A requests a new TCP connection to 5.6.7.8. >> Established with host B at 5.6.7.8. >> Host B adds 8.7.6.5 >> Host B removes 5.6.7.8 >> Host C comes online with 5.6.7.8. >> Host A requests a new TCP connection to 5.6.7.8. >> >> Which host does A connect to? > > I'm not sure I see the problem. > > When host B removes 5.6.7.8, that address is removed from that > connection only. It has no relation with any other connections, > ongoing or future. If A has any other connections with 5.6.7.8, they > are unaffected (after all, 5.6.7.8 may be a NAT with several hosts > behind it) unless they also explicitly remove the address. > > When A requests a new TCP connection to 5.6.7.8, that's what A's app > specified at that moment in the connect call, and that's the address > the SYN will be sent to. No previous behaviour for any other > connection affects that. How do you know whether 5.6.7.8 is the same place as the first connection, or a new place? Don't you need to figure that out to know whether you end up with new capacity, or need to share capacity? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrvf7MACgkQE5f5cImnZruzbgCePtU/NMkZd/JxuEPcYDZp8RmO ZzcAn1JyiFj5q5iZqpFgS0pc6b8veSxf =Jukr -----END PGP SIGNATURE----- From lars.eggert@nokia.com Mon Nov 2 20:07:38 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522803A6809 for ; Mon, 2 Nov 2009 20:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl5IazfHN4sr for ; Mon, 2 Nov 2009 20:07:37 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 515983A67E3 for ; Mon, 2 Nov 2009 20:07:37 -0800 (PST) Received: from [172.20.100.59] ([66.201.48.54]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA347YRf088913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 06:07:42 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-78--258825711; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4AEF7FB3.4020604@isi.edu> Date: Mon, 2 Nov 2009 20:07:28 -0800 Message-Id: <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 03 Nov 2009 06:07:46 +0200 (EET) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 04:07:38 -0000 --Apple-Mail-78--258825711 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-11-2, at 16:56, Joe Touch wrote: > How do you know whether 5.6.7.8 is the same place as the first > connection, or a new place? Don't you need to figure that out to know > whether you end up with new capacity, or need to share capacity? I don't think you care whether it's the same location or not - the linked congestion control proposal doesn't infer topology information from IP addresses. Lars --Apple-Mail-78--258825711 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwMzA0MDcyOFowIwYJKoZIhvcNAQkEMRYEFGJ0WTEVB8/CvtQNIGi8PGSci/GkMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCLBNtq0J+/dwrq/36PlBSGsb2EIptxhbn1wA8Gbva6SdPRpY+EHpLcj5s6Yr17TvczH73z Yekm6DSNfQCVsCpLJSKvz/F6ebw2fI1C1/nqfXFROHJ8/fA1BYQzT2Slk55NanmpOgpnUfYUndVK Sx5OwTEMO7bnXqEhiiDZnppXb1CgqMSfmzRhx5hP8hA3lKYusWArGZdQNlpHumOM2S0NGnrEv9JH 5sTzCr6FGWL6+qkaNMthRiz/+WSawXes4RBuCrG+mMMfhRPYU5xqfVkOW5tyqmGh4PkIuZO/F9X1 SohtpaqS6xaq/dQIMKCBf4eejDCMm347rDLm4Uv3dSOuAAAAAAAA --Apple-Mail-78--258825711-- From nishida@sfc.wide.ad.jp Mon Nov 2 23:54:10 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287CB3A676A for ; Mon, 2 Nov 2009 23:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.351 X-Spam-Level: * X-Spam-Status: No, score=1.351 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2M+6GzGAzr3 for ; Mon, 2 Nov 2009 23:54:09 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 4C4DE3A6405 for ; Mon, 2 Nov 2009 23:54:09 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 561F14C09A; Tue, 3 Nov 2009 16:54:24 +0900 (JST) Date: Tue, 03 Nov 2009 16:54:24 +0900 (JST) Message-Id: <20091103.165424.165327321.nishida@sfc.wide.ad.jp> To: bill@herrin.us From: Yoshifumi Nishida In-Reply-To: <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> References: <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 07:54:10 -0000 From: William Herrin Subject: Re: [multipathtcp] High-level design decisions /architecture Date: Mon, 2 Nov 2009 19:38:46 -0400 Message-ID: <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> > On Mon, Nov 2, 2009 at 6:45 PM, marcelo bagnulo braun > wrote: > >> I'm concerned about this idea. One of the corner cases where shim6 > >> falls apart is: once the connection migrates away from the original > >> addresses, how do the endpoints decide whether a new connection > >> request for the original addresses means the migrated addresses or the > >> current holder of the addresses? Think: FTP. > >> > > > > could you expand on this? > > I wasn't aware shim6 falls apart in any case neither this particular > > approach... > > Hi Marcelo, > > Consider the following scenario: > > Host A comes online with 1.2.3.4. > Host A requests a new TCP connection to 5.6.7.8. > Established with host B at 5.6.7.8. > Host B adds 8.7.6.5 > Host B removes 5.6.7.8 > Host C comes online with 5.6.7.8. > Host A requests a new TCP connection to 5.6.7.8. > > Which host does A connect to? > > If the answer is C, protocols like FTP which initiate multiple TCP > connections to the same IP address fail once an endpoint gives up its > original address. That'll also impact web browsers which employ dns > pinning. In case of ftp, the choice would be something like this? 1: we don't support this case. ftp will fail. 2: ftp client/server performs getsockname() before port/pasv to check its own active IP address. (But, we need to define getsockname() should return active IP address instead of original IP) 3: Develop new ftp for MPTCP (using new API etc..) I personally prefer 1.. then might do 3 later.. In case of dns pinning, I don't see any issues. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From marcelo@it.uc3m.es Tue Nov 3 01:42:32 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34F73A698F for ; Tue, 3 Nov 2009 01:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLa6V+0vivQf for ; Tue, 3 Nov 2009 01:42:31 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id BAEB33A680F for ; Tue, 3 Nov 2009 01:42:30 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.31.227]) by smtp02.uc3m.es (Postfix) with ESMTP id 67E396C0F18; Tue, 3 Nov 2009 10:42:49 +0100 (CET) Message-ID: <4AEFFB0C.8010702@it.uc3m.es> Date: Tue, 03 Nov 2009 10:42:36 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: William Herrin References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> In-Reply-To: <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16986.006 Cc: multipathtcp@ietf.org Subject: [multipathtcp] This shim6 part of the answer (was Re: High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 09:42:33 -0000 I am splitting the answer in the shim6 part and the mptcp part, so that people not interested in shim6 (which i guess are plenty since this is the mptcp ml, can simply drop this email) William Herrin escribió: > On Mon, Nov 2, 2009 at 6:45 PM, marcelo bagnulo braun > wrote: > >>> I'm concerned about this idea. One of the corner cases where shim6 >>> falls apart is: once the connection migrates away from the original >>> addresses, how do the endpoints decide whether a new connection >>> request for the original addresses means the migrated addresses or the >>> current holder of the addresses? Think: FTP. >>> >>> >> could you expand on this? >> I wasn't aware shim6 falls apart in any case neither this particular >> approach... >> > > Hi Marcelo, > > Consider the following scenario: > > Host A comes online with 1.2.3.4. > Host A requests a new TCP connection to 5.6.7.8. > Established with host B at 5.6.7.8. > Host B adds 8.7.6.5 > Host B removes 5.6.7.8 > Host C comes online with 5.6.7.8. > Host A requests a new TCP connection to 5.6.7.8. > > Which host does A connect to? > > first of all Shim6, as one may guess from the acronym :-) only works for IPv6 identifiers. So, non of them apply to shim6 Second, due to large space of IPv6 iid, the situation you describe there is very unlikely to happen by a coincidence. It may be due to an attack, where the attacker is host C, agree? assuming that above were IPv6 addresses, the host you actually connect to depends whether you are using forking or not. But in general, you will be connecting to host B, as long as the shim6 state is on host A > If the answer is C, protocols like FTP which initiate multiple TCP > connections to the same IP address fail once an endpoint gives up its > original address. That'll also impact web browsers which employ dns > pinning. > > If the answer is B, I can hijack hotmail's IPs with respect to your > mail server for the few fractions of a second it takes to establish > and move a TCP connection over to an IP address I legitimately > control. You'll then indefinitely send subsequent hotmail-addressed > email to me. If I diligently pass it on to hotmail, you may never even > know. > No, In order to do that you would have had to generate an HBA for that address, which in computationally impossible in a reasonable timer frame. So, no hijacking attacks in shim6 If you do think there is the possibility of a hijacking attack, please describe it. So, i don't see shim6 breaking in this case... Regards, marcelo > If we identify the connection by the original IP address even after > that address is gone, effectively lying to the application, we can > induce it to incorrect behavior. That can have security implications > that may be hard to get a handle on. > > Regards, > Bill Herrin > > From marcelo@it.uc3m.es Tue Nov 3 01:45:04 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769E23A6979 for ; Tue, 3 Nov 2009 01:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssAOCDxkrAp0 for ; Tue, 3 Nov 2009 01:45:03 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 367CC3A6821 for ; Tue, 3 Nov 2009 01:45:02 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.31.227]) by smtp01.uc3m.es (Postfix) with ESMTP id 850B3BA4AD3; Tue, 3 Nov 2009 10:45:20 +0100 (CET) Message-ID: <4AEFFBA3.9060303@it.uc3m.es> Date: Tue, 03 Nov 2009 10:45:07 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: William Herrin References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> In-Reply-To: <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16986.006 Cc: multipathtcp@ietf.org Subject: [multipathtcp] The MPTCP part (was Re: High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 09:45:04 -0000 William Herrin escribió: > On Mon, Nov 2, 2009 at 6:45 PM, marcelo bagnulo braun > wrote: > >>> I'm concerned about this idea. One of the corner cases where shim6 >>> falls apart is: once the connection migrates away from the original >>> addresses, how do the endpoints decide whether a new connection >>> request for the original addresses means the migrated addresses or the >>> current holder of the addresses? Think: FTP. >>> >>> >> could you expand on this? >> I wasn't aware shim6 falls apart in any case neither this particular >> approach... >> > > Hi Marcelo, > > Consider the following scenario: > > Host A comes online with 1.2.3.4. > Host A requests a new TCP connection to 5.6.7.8. > Established with host B at 5.6.7.8. > Host B adds 8.7.6.5 > Host B removes 5.6.7.8 > Host C comes online with 5.6.7.8. > Host A requests a new TCP connection to 5.6.7.8. > > i don't see how this applies to MPTCP, since MPTCP as oposed to any L3 solution works per connection. So in the MPTCP case, the original connection would still be with host B and the new connection would be with host C, which is the same baheviour that you would have with normal TCP (only that with normal TCP the first connection would have break while with MPTCP is still preserved) So i don't see this as a problem, but rather as a feature... what am i missing? Regards, marcelo > Which host does A connect to? > > If the answer is C, protocols like FTP which initiate multiple TCP > connections to the same IP address fail once an endpoint gives up its > original address. That'll also impact web browsers which employ dns > pinning. > > If the answer is B, I can hijack hotmail's IPs with respect to your > mail server for the few fractions of a second it takes to establish > and move a TCP connection over to an IP address I legitimately > control. You'll then indefinitely send subsequent hotmail-addressed > email to me. If I diligently pass it on to hotmail, you may never even > know. > > If we identify the connection by the original IP address even after > that address is gone, effectively lying to the application, we can > induce it to incorrect behavior. That can have security implications > that may be hard to get a handle on. > > Regards, > Bill Herrin > > From marcelo@it.uc3m.es Tue Nov 3 01:48:14 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8943A6979 for ; Tue, 3 Nov 2009 01:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtew58vKG-EK for ; Tue, 3 Nov 2009 01:48:14 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id EB2713A687D for ; Tue, 3 Nov 2009 01:48:13 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.31.227]) by smtp02.uc3m.es (Postfix) with ESMTP id 4F5A56C0DF2; Tue, 3 Nov 2009 10:48:32 +0100 (CET) Message-ID: <4AEFFC63.10202@it.uc3m.es> Date: Tue, 03 Nov 2009 10:48:19 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Joe Touch References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> In-Reply-To: <4AEF781E.4070009@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16986.006 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 09:48:15 -0000 Joe Touch escribió: > >> Security >> >> ====== >> >> * exchange a token in the initial SYN for the MPTCP connection, and >> include the token when subflows /paths are added to the connection >> o [Question: Is the same token used whether the sender or >> receiver (of the MPTCP connection) adds the subflow? Is the >> same technique used for removing subflows? And closing >> connections, ie DATA FIN?] >> > > Let's please not call this "security". Call it a flow identifier, but > it's trivial for on-path attackers to see, and anything small enough to > be appropriate for a SYN is likely to be too small to prevent exhaustion > attacks. > > >> * security mechanisms will not interfere with end-to-end >> authentication etc >> > > Yes. Specifically IMO there ought to be a TCP-AO mode supported - e.g., > using socketpair of the original connection for the pseudoheader used > for MAC calculation. > > It would make sense to contrast the protection provided by TCP-AO witht he threats identified in the threat analysis and see how many of these it solves. Regards, marcelo From toby.moncaster@bt.com Tue Nov 3 04:35:25 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1143A68E2 for ; Tue, 3 Nov 2009 04:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF8EgM7ewme3 for ; Tue, 3 Nov 2009 04:35:24 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 825EA3A6816 for ; Tue, 3 Nov 2009 04:35:23 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 12:35:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2009 12:35:40 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] FW: New Version Notification fordraft-ford-mptcp-multiaddressed-02 Thread-Index: AcpWg4RSrGHNwQZaQ++6OyDlcY6EAAAo6YjgASEwbqAANObhcAAAoCYg From: To: X-OriginalArrivalTime: 03 Nov 2009 12:35:42.0831 (UTC) FILETIME=[287DAFF0:01CA5C82] Subject: [multipathtcp] FW: FW: New Version Notification fordraft-ford-mptcp-multiaddressed-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 12:35:25 -0000 forwarded to list at chair's request > -----Original Message----- > From: Moncaster,T,Toby,DEE1 R > Sent: 03 November 2009 12:15 > To: Ford, Alan > Cc: Eardley,PL,Philip,DEE1 R; Yoshifumi Nishida > Subject: RE: [multipathtcp] FW: New Version Notification = fordraft-ford- > mptcp-multiaddressed-02 >=20 > Hi Alan, >=20 > I had a look through the new version and in general it is pretty good. = It > still needs tightening in a few places. Here are a few random comments = on > the draft... (sent to you not copied to list as it is getting rather a > long review! If you think it would be useful on the list let me know. = I > have copied the WG chairs) >=20 > Incidentally - in general it seems a pretty OK document apart from a > tendency to use flowery language and to put things in a strange order = in > sentences and paragraphs... >=20 > General comment: You really should include a changelog in the = document, > especially as this is likely to be quite an "active" document... >=20 >=20 > Abstract: >=20 > this really needs to explain that this document is using multiple > addresses to identify multiple paths. >=20 > 1.1 Design Assumptions: >=20 > Is there actually also an implicit assumption that those multiple > addresses are known to the other endpoint? Also is this version = assuming > both endpoints are modified? If so that needs to be spelt out as well. >=20 > "The congestion control algorithms as discussed in [4] ensure this = does > not act detrimentally." I don't like the vagueness of this sentence. = You > need to give an idea as to what sort of detrimental action you are = trying > to avoid... >=20 > "Application Constraints" I feel could be improved. Something like = "The > protocol must still correctly implement the standard TCP API to ensure > that legacy applications can still use it as a transport. This doesn't > preclude the creation of additional features for use with modified > applications." >=20 > 1st bullet of areas for further study. This seems to be a complete = throw- > away sentence. In what sense might this aid transition? Having normal = TCP > understand both v4 and v6 hasn't helped. Can you put a bit more detail = in > here about what you were thinking? >=20 >=20 >=20 > 2nd bullet potenitally --> potentially. Again, this bullet isn't quite > clear. I think what you are saying is that the extensions in this = document > are sufficiently generic that they may be easily extended to cover > alternatives to multi-addressed multipath. >=20 >=20 > 1.2 Layered Representation: >=20 > "MPTCP operates at the transport layer, and its existence aims to be > transparent to both higher and lower layers." --> "... and it offers a > transparent interface between higher and lower layers." >=20 > 1.3 Operation Summary: >=20 > I think in the longer term this section could be tightened up a bit. = It > makes perfect sense but sometimes the language is a bit stilted. As an > example take bullet 3: "If extra paths are available, additional TCP > sessions are created on these paths, and are combined with the = existing > session, which continues to appear as a single connection to the > applications at both ends." Could be re-written as "If extra paths are > available then additional TCP sessions can be created using those = paths. > These are then added to the existing session which continues to appear = as > a single connection to the applications at both ends." >=20 > Not sure that figure 2 really helps all that much... >=20 >=20 > 1.4. Open Issues: >=20 > Would it be helpful to add a note to the effect that as these issues = are > addressed it is hoped this section can be reduced? >=20 > 3rd bullet makes little sense to me... >=20 > 4th bullet is a little unclear >=20 >=20 > 2. Terminology: >=20 > Subflow. Add "single" to give "A stream of TCP packets sent over a = single > path." >=20 > Endpoint needs to be defined before token since it is used in the > definition of token... >=20 > 3. Semantic Issues: >=20 > The bullet relating to FIN implies there is a need for a defined term = in > section 2 for DATA FIN? >=20 > Ditto Address List... Does this need a definition? >=20 > 4.1. Session Initiation: >=20 > Will the version be IANA controlled as well? >=20 > "This token is generated for the sender...". This sentence is a little > confusing. I think you mean that the sender needs to ensure each of = its > sessions has a unique token? But this isn't clear from the wording you > have used (and since you are using a MUST it needs to be clear). >=20 > "... in order to identify the connection; all following connections = will > use ...". surely you mean "all following sessions"? Or something? Not > following connections anyway... >=20 > I think it would be clearer to add that if a SYN does not contain an = MPTCP > option then any option on the SYN/ACK will be ignored... >=20 > Should we actually specify a proper fallback procedure so as to avoid = the > issue that exists in Linux wit ECN negotiation? Perhaps specify that = after > 3 attempts it MUST fall back to sending a non-MPTCP SYN? I also think = it > sounds unsafe to suggest you can revert to multipath even after giving = up > an attempt to negotiate it... >=20 > You need to explain circumstances in which you might not try = alternative > addresses before reverting to regular TCP... >=20 > 4.2. Starting a New Subflow: >=20 > "The "Join" TCP option (Figure 4) is used to identify of which = connection > the new subflow should become a part." --> "The "Join" TCP Option = (figure > 4) identifies which connection this new subflow will belong to." Or > perhaps "The "Join" option (figure 4) is used to identify which = connection > a new subflow should be joined to." >=20 > " This option can only be present when the SYN flag is set." --> would = it > be better to make this a MUST? >=20 > 4.3. Address Knowledge Exchange (Path Management): >=20 > "path management" sounds like it should be defined in section 2... >=20 > "This design makes use of two methods of sharing such information, = used > simultaneously." -->"This design allows for two methods of sharing = such > information which are used simultaneously." Are you really saying you = HAVE > to do both always? >=20 > "This approach, of two complementary mechanisms, has been chosen to = allow > addresses to change in flight, and thus support operation through = NATs, > whilst also allowing the signalling of previously unknown addresses, = such > as those belonging to other address families (e.g. IPv4 and IPv6)." >=20 > Aaargh! You can't have a sentence with that many clauses it hurts the > brain trying to parse it...! How about "This second approach has been > included because it allows addresses to be changed in flight, thus > supporting operation through NATs. It also allows previously unknown > addresses to be signalled such as those belonging to other address > families (e.g. IPv4 and IPv6)." NB would it be better to say = "including" > instead of "such as" in the second sentence? >=20 > " Here is an example of typical operation of the protocol:" --> "The > following example illustrates the key points of the approach:" >=20 > 2nd bullet "intiated" --> "initiated". "multhomed" --> "multihomed". = Whole > bullet is rather hard to parse... >=20 > I'm not convinced setting this out in bullets in this form is the best > way. In particular bullet 4 seems out of place... And the other = bullets > are sometimes describing a single operation and sometimes a whole > discussion... >=20 > ***** getting back to this a day later ***** >=20 > 4.3.1 Adding Addresses: >=20 > To me it would seem logical to put this before the example scenario in > 4.3. which refers forward to this option... >=20 > General point might it be clearer to say {ID, address} pair rather = than > (ID, address)? I keep reading it as a parenthetic comment, realise it > isn't and have to re-parse the sentence (that may just be me being = thick). >=20 > "Multiple addresses can be added if there is sufficient TCP option = space, > otherwise multiple TCP messages containing this option will be sent." = --> > "Multiple addresses can be added in each message if they are needed = and if > TCP option space permits. Otherwise multiple versions of this option = will > be needed on different segments." >=20 > Meta-point which TCP options trump which? We wouldn't want to end up = with > a stack that crammed lots of Add Address options into a segment then > realised it didn't have enough space left to do SACK or timing or > something. Might it in fact be neater to limit this to a maximum of 1 = IPv6 > (=3D=3D 4 IPv4)? Actually reading further, it seems to complicate = matters to > have multiple entries in one option. Is there a strong requirement for > this? Would it function just as well if you had to declare each = address in > a new option on a subsequent segment? >=20 > 4.3.2 Remove Addresses: >=20 > I would prefer to see something that started "The Remove Addresses = Option > is used when a previously announced address becomes invalid during the > lifetime of a flow...". Otherwise the whole section reads in a strange > manner. Also is "invalid" the best word? It seems to imply something = has > actually happened to that address, but in fact it might just be that = the > sender no longer wants to use it... >=20 > "Address removal is undertaken by ID, so as to permit the use of NATs = and > other middleboxes." Just because this is a standards doc doesn't mean = you > need to use flowery language. "Addresses are removed by ID to allow = for > NATs and other middleboxes." >=20 > 4.4 General TCP Operation: >=20 > Second paragraph: "The sender thus knows, if subflow data goes > unacknowledged, which part of the original data stream this equates = to, > and thus what data must be retransmitted." ---> "If subflow data goes > unacknowledged the sender is able to tell which part of the original = data > stream needs to be re-transmitted". Why use such complicated language! >=20 > Figure 7 could be a little clearer to me. I had to parse it twice to > realise you had left out a block of 4 octets... But this may be = standard > practise in which case ignore me... >=20 > Para starting "A receiver MUST NOT accept data..." sentence "To do = this, > the receiver..." seems an odd way of phrasing it. I suspect you mean = "This > is achieved by the receiver not acknowledging the unmapped data.." >=20 > How do you keep track of whether a packet had the mapping information? = How > does the mapping info get re-transmitted? Can the sender infer the = loss of > mapping data from the receiver's lack of acks. E.g. if it sees no acks > should it send the mapping option again? >=20 > "Although it is expected that initial implementations..." This = paragraph > is clumsy. I think it would sound better if you put the second half = first > (e.g. start "64-bit sequence numbers MUST be considered valid..." and = then > go on to say that initially it is believed that 32 bit will suffice... >=20 > Would it be a good idea to show an example of the combined Data = Sequence > Mapping and Multipath Capable option? >=20 > Do you need to make it crystal clear how the mapping happens (e.g. is = it > the start sequence + the length exclusive or inclusive). I ask because > SACK differs from normal ACKs in that it is inclusive (if I remember > correctly - it's subtly different anyway...) >=20 >=20 > 4.4.3. Subflow Policy: >=20 > "The ability to make effective choices at the sender requires full > knowledge of the path "cost", which is unlikely to be the case." I = think > you mean that you can never know the exact cost. Otherwise the = sentence is > saying you can never do anything without full knowledge of the path = cost > which you can't get... >=20 > I still think we need to look in much more detail at all the issues > surrounding faking ECN signals... Especially if this is going to run = in > parallel with re-ECN or COnEx... And this is more than an overload of = the > ECN signal! It's a complete hijack! >=20 > 4.5. Closing a Connection: >=20 > "Specifically, when a DATA FIN has been received, IF all data has been > successfully received, timeouts on all subflows MAY be reduced. > Similarly, when sending a DATA FIN, once all data (including the DATA = FIN, > since it occupies one octet of data sequence space) has been = acknowledged, > FINs must be sent on every subflow." This block of text includes lower > case must (you prob mean MUST) and an IF which is best avoided = (uppercase > is really best left for the standards language...). >=20 > Reading this section makes me realise you probably want to pull out = all > the 2119 language (MUST, SHOULD, MAY, etc) into bullets at the end of = each > sub-section so that someone quickly wanting to check on a particular > behaviour need only read some bullets. >=20 >=20 > That's as far as I have got so far. I will try and read the rest = before > next week but no promises... >=20 > Toby >=20 > ____________________________________________________________________ > Toby Moncaster, Senior Researcher, Network Infrastructure Practice > B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > > bounces@ietf.org] On Behalf Of Ford, Alan > > Sent: 27 October 2009 17:03 > > To: multipathtcp@ietf.org > > Subject: [multipathtcp] FW: New Version Notification fordraft-ford- > > mptcp-multiaddressed-02 > > > > Hi all, > > > > We now have a new version of the MPTCP protocol draft available, = which > > will be presented in Hiroshima. > > > > Questions and discussion very much welcome beforehand too! > > > > http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt > > > > Cheers, > > Alan > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: 26 October 2009 21:30 > > To: Ford, Alan > > Cc: c.raiciu@cs.ucl.ac.uk; m.handley@cs.ucl.ac.uk > > Subject: New Version Notification for = draft-ford-mptcp-multiaddressed- > > 02 > > > > > > A new version of I-D, draft-ford-mptcp-multiaddressed-02.txt has = been > > successfuly submitted by Alan Ford and posted to the IETF = repository. > > > > Filename: draft-ford-mptcp-multiaddressed > > Revision: 02 > > Title: TCP Extensions for Multipath Operation with Multiple > > Addresses > > Creation_date: 2009-10-26 > > WG ID: Independent Submission > > Number_of_pages: 26 > > > > Abstract: > > 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 - reliable = bytestream > > - and provides the components necessary to establish and use = multiple > > TCP flows across potentially disjoint paths. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp From scott.brim@gmail.com Tue Nov 3 06:08:27 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339F83A6A0F for ; Tue, 3 Nov 2009 06:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.048 X-Spam-Level: * X-Spam-Status: No, score=1.048 tagged_above=-999 required=5 tests=[AWL=-3.648, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf3xHar84rVt for ; Tue, 3 Nov 2009 06:08:26 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 47A2F3A6932 for ; Tue, 3 Nov 2009 06:08:26 -0800 (PST) Received: by gxk28 with SMTP id 28so2526425gxk.9 for ; Tue, 03 Nov 2009 06:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=l3SGeT1qiroFWvGGnRGbpRox5jnmgK+2/SwmGevQTxs=; b=SEs9SpDs+cRgYOHDgEgZQwICiEsssZQxGNWYiySq3A/yJKoURayrWBJ3jxMVTDH24/ EhBnS+RRh3r/bE0EU1kXzECuhvtHfFgx1mn+EukoHJL39Y8kbh5tviWSPa3Hdmknb47S ERjnOXvUovKJaYrpYjmvBYSe+tpPNy8p37yY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=YITRw9CpjGDMjAvpvnP6aJnoh50OWdZJ40Q7YtlVniYlyTSsBhV2YDxSlCx5wJtdvF 5OYrsePGcQXhRNc4jThDujzCQnO6Jq+xtb4HGkiDTk4xNxCh1kWHibLi8d6biL/ROMoc fFiaFR9kRoe9wpgvQ0C1etR2cXqI4GyC07FSw= Received: by 10.90.226.13 with SMTP id y13mr240361agg.107.1257257317563; Tue, 03 Nov 2009 06:08:37 -0800 (PST) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 8sm40768ywg.34.2009.11.03.06.08.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Nov 2009 06:08:34 -0800 (PST) Message-ID: <4AF0395E.4000600@gmail.com> Date: Tue, 03 Nov 2009 09:08:30 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: lucy yong References: <00e001ca5c60$470c88a0$340ca40a@china.huawei.com> In-Reply-To: <00e001ca5c60$470c88a0$340ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] =?gb2312?b?KioqU1BBTSoqKiA2LjEwNiAoNSkgtPC4tDog?= =?gb2312?b?ICoqKlNQQU0qKiogNi4zOCAoNSkgtPC4tDogSGlnaC1sZXZlbCBkZXNpZ24g?= =?gb2312?b?ZGVjaXNpb25zIC9hcmNoaXRlY3R1cmU=?= X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:08:27 -0000 lucy yong allegedly wrote on 11/03/2009 3:33 AM: > Thanks, Yoshifumi fro the response. > How does MPTCP determine splitting app. traffic into different subflows > without aware of app. flows. > Best Regards, > Lucy Hi Lucy. I don't quite understand the question. MPTCP is responsible for transport of the application flow, therefore it is quite aware of it. From scott.brim@gmail.com Tue Nov 3 07:00:12 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3416D3A6A31 for ; Tue, 3 Nov 2009 07:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqp1sJTjk6u6 for ; Tue, 3 Nov 2009 07:00:08 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 542683A67E4 for ; Tue, 3 Nov 2009 07:00:08 -0800 (PST) Received: by yxe30 with SMTP id 30so6448289yxe.29 for ; Tue, 03 Nov 2009 07:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=2N4dUp/ml955oOHal+ydXstHMW1hmtubgcRCFdAlF0g=; b=bTKypFIV0XBJRU6qNwSlNEtFq3EpDiXhig1b72Y9p80RYykUXSf6kG6jIvgk4vigyG 4E541uHrbnLjfpjAP2NYdLkpHJdf6jBQAWRPqM0tOCvldpOE6eS+BShn/SAE/JQRhsFr OsWDt0Uw/UaS97q/524o1AylmqLuQR34HPlUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UolgjjaA0AVixqHDmKmDTxe/DPueg36B+RzgO3lBHboTg2TAYqUjNF64Pr0JEA5Srv GVX83oHuQ6HN1T+DJjtiirKhF3eL8LfU1pmosYk1ah1RB5rZBoTo0w8cCyD8qhHuxO1W fJYsRy2gWm4j2dduByP5U/oynuOsL9Tprpm6s= Received: by 10.101.179.24 with SMTP id g24mr127929anp.62.1257260426489; Tue, 03 Nov 2009 07:00:26 -0800 (PST) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 7sm54382ywc.21.2009.11.03.07.00.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Nov 2009 07:00:24 -0800 (PST) Message-ID: <4AF04585.2050700@gmail.com> Date: Tue, 03 Nov 2009 10:00:21 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: William Herrin References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> In-Reply-To: <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:00:12 -0000 William Herrin allegedly wrote on 11/02/2009 4:28 PM: > On Mon, Nov 2, 2009 at 1:47 PM, wrote: >> The MPTCP connection is identified, from an apps perspective, by the >> addresses associated with the original path (even if that subflow /path >> closes) > > I'm concerned about this idea. One of the corner cases where shim6 > falls apart is: once the connection migrates away from the original > addresses, how do the endpoints decide whether a new connection > request for the original addresses means the migrated addresses or the > current holder of the addresses? Think: FTP. An e2e security mechanism / token that identifies the flow. See the security bullet. But there are corner cases where it is extremely difficult to establish a stable src/dst address pair. In particular if BGP and NAT are set up such that you contact me on one address, I reply on my other address ... and you do the same on your end. Since NAT is now architecture, it is important that initial setup be as independent from addresses as possible. I believe we're essentially there but we have to prove it. >> A SYN/ACK exchange (on a single path) checks that both ends support MPTCP, >> with automatic fall-back to TCP if not > > We have an awful lot of TCP options that are only valid in the > SYN-SYN/ACK exchange and only 40 bytes to put them all. What's wrong > with starting all TCP connections in non-MP mode and allowing the > connection's initiator to request MPTCP starting with any packet that > expects an ACK? See previous paragraph. >> each MPTCP subflow looks exactly like an ordinary, semantically independent >> TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are >> independent on each subflow > > I'm almost sold on the idea of subflows. Can you give me a run down on > the pros and cons, particularly the cons? My biggest con is if your destination is multiply connected behind two non-synchronized intrusion prevention devices. Scott From lucyyong@huawei.com Tue Nov 3 07:04:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80A43A6960 for ; Tue, 3 Nov 2009 07:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8-DhPM+2sm1 for ; Tue, 3 Nov 2009 07:04:40 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 3C6E53A67E4 for ; Tue, 3 Nov 2009 07:04:36 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSJ003K8GK8NB@usaga01-in.huawei.com> for multipathtcp@ietf.org; Tue, 03 Nov 2009 07:04:56 -0800 (PST) Received: from y736742 (137.91.88.117.broad.nj.js.dynamic.163data.com.cn [117.88.91.137]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSJ00A7HGK1OH@usaga01-in.huawei.com> for multipathtcp@ietf.org; Tue, 03 Nov 2009 07:04:56 -0800 (PST) Date: Tue, 03 Nov 2009 09:05:05 -0600 From: Yong Lucy In-reply-to: <4AF0395E.4000600@gmail.com> To: 'Scott Brim' Message-id: <007901ca5c97$08179220$bf05a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcpcjzVuUEDwVLFkQQSr9L2qh68Z8AABlx9g References: <00e001ca5c60$470c88a0$340ca40a@china.huawei.com> <4AF0395E.4000600@gmail.com> Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:04:40 -0000 Hi Scott, Yes, MPTCP is responsible for transport of application traffic. Does one MPTCP connection support multiple applications or just one application? = One application may contain multiple http, is MPTCP aware of each http = instance? In short, is MPTCP connection aware of individual flows that it carries? = Hope this makes clear. Thanks, Lucy > -----Original Message----- > From: Scott Brim [mailto:scott.brim@gmail.com] > Sent: Tuesday, November 03, 2009 8:09 AM > To: lucy yong > Cc: 'Yoshifumi Nishida'; multipathtcp@ietf.org > Subject: Re: [multipathtcp] ***SPAM*** 6.106 (5) =B4=F0=B8=B4: = ***SPAM*** 6.38 (5) > =B4=F0=B8=B4: High-level design decisions /architecture >=20 > lucy yong allegedly wrote on 11/03/2009 3:33 AM: > > Thanks, Yoshifumi fro the response. > > How does MPTCP determine splitting app. traffic into different = subflows > > without aware of app. flows. > > Best Regards, > > Lucy >=20 > Hi Lucy. I don't quite understand the question. MPTCP is responsible = for > transport of the application flow, therefore it is quite aware of it. From marcelo@it.uc3m.es Tue Nov 3 07:08:52 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2523B3A696F for ; Tue, 3 Nov 2009 07:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.258 X-Spam-Level: X-Spam-Status: No, score=-5.258 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CquriAVx7lqc for ; Tue, 3 Nov 2009 07:08:51 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1BDFB3A6960 for ; Tue, 3 Nov 2009 07:08:50 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.187]) by smtp02.uc3m.es (Postfix) with ESMTP id D61806C1C24; Tue, 3 Nov 2009 16:09:08 +0100 (CET) Message-ID: <4AF04787.3060606@it.uc3m.es> Date: Tue, 03 Nov 2009 16:08:55 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Yong Lucy References: <00e001ca5c60$470c88a0$340ca40a@china.huawei.com> <4AF0395E.4000600@gmail.com> <007901ca5c97$08179220$bf05a8c0@china.huawei.com> In-Reply-To: <007901ca5c97$08179220$bf05a8c0@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16988.000 Cc: multipathtcp@ietf.org, 'Scott Brim' Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:08:52 -0000 Yong Lucy escribi¨®: > Hi Scott, > > Yes, MPTCP is responsible for transport of application traffic. Does one > MPTCP connection support multiple applications or just one application? one MPTCP connection (wihtout the extended API) looks like just a normal TCP connection for the application So, i guess that the answer to your question is one MPTCP connection is associaed with one application > One > application may contain multiple http, is MPTCP aware of each http instance? > no > In short, is MPTCP connection aware of individual flows that it carries? > > yes, it is aware of each flow, but i think you and me mean different things when we say flows and subflows Regards, marcelo > Hope this makes clear. > > Thanks, > Lucy > > > > >> -----Original Message----- >> From: Scott Brim [mailto:scott.brim@gmail.com] >> Sent: Tuesday, November 03, 2009 8:09 AM >> To: lucy yong >> Cc: 'Yoshifumi Nishida'; multipathtcp@ietf.org >> Subject: Re: [multipathtcp] ***SPAM*** 6.106 (5) ´ð¸´: ***SPAM*** 6.38 (5) >> ´ð¸´: High-level design decisions /architecture >> >> lucy yong allegedly wrote on 11/03/2009 3:33 AM: >> >>> Thanks, Yoshifumi fro the response. >>> How does MPTCP determine splitting app. traffic into different subflows >>> without aware of app. flows. >>> Best Regards, >>> Lucy >>> >> Hi Lucy. I don't quite understand the question. MPTCP is responsible for >> transport of the application flow, therefore it is quite aware of it. >> > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From scott.brim@gmail.com Tue Nov 3 07:17:48 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C65128C0F6 for ; Tue, 3 Nov 2009 07:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC4K8M4jpPEQ for ; Tue, 3 Nov 2009 07:17:47 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id CD4953A659B for ; Tue, 3 Nov 2009 07:17:46 -0800 (PST) Received: by qyk41 with SMTP id 41so3011967qyk.29 for ; Tue, 03 Nov 2009 07:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=lDYQFvYIJMbyL+N36vlcYu6DwDFKUxBFd/NQk9IB1LY=; b=R9M/d+2rj4BT9ms80vwiW9DCsHX3BqDJYGiiHiuN7sHssGonloV8r6vjeQJyJgUFUl 8tc+pzTHx/5GhcaQ47HnGOpBxqFN9J2Pab87fsU/Zme6S1HHz20TPV0Do1v63ttC8o9F ShEQrvUWxTvwwAZFgUGykDuXtQZTnpSg0rlxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=pMBcfEo3R4S+WPsxokVBXEda2FwMYtV4jyKOtnmhOcYAQeE2I0jtQYC2iI5mSrhezK v/8IaDetMBMiJB6VQa5GaQFsY4Yt96hZ+DbFyb0KK/CXS1EvHej6aKRGTU2u6enRZk/U QDA9+bMNhIPWFBwGXg6PE69yof2Llm026yAcw= Received: by 10.224.44.77 with SMTP id z13mr58957qae.195.1257261484326; Tue, 03 Nov 2009 07:18:04 -0800 (PST) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 20sm100982qyk.13.2009.11.03.07.18.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Nov 2009 07:18:03 -0800 (PST) Message-ID: <4AF049A8.2060501@gmail.com> Date: Tue, 03 Nov 2009 10:18:00 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:17:48 -0000 philip.eardley@bt.com allegedly wrote on 11/02/2009 12:47 PM: > Protocol-related > > ============ > > * IPv4 & IPv6 will have the same high-level design > o [Comment: the Charter implies both v4 & v6 are in scope] > * The MPTCP connection is identified, from an apps perspective, by > the addresses associated with the original path (even if that > subflow /path closes) ... for a legacy API. An up-to-date API, with extensions, MUST have a way of identifying the connection which is independent of addresses. > * A SYN/ ACK exchange (on a single path) checks that both ends > support MPTCP, with automatic fall-back to TCP if not > * each MPTCP subflow looks exactly like an ordinary, semantically > independent TCP flow. MPTCP effectively runs on top. So > re-transmission, FINs etc are independent on each subflow retransmission must be sub-flow specific for the moment but we know that can slow things down so we should actively investigate ways of retransmitting on any sub-flow. > * control of the MPTCP connection (as opposed to the subflows) is > carried in TCP options, eg DATA FIN for closing an MPTCP connection > * the protocol involves an MPTCP stack at both ends of the MPTCP > connection > o [Comment: this is in our charter] > * Either end of the MPTCP connection can add or remove paths to/from > the MPTCP connection > o [Comment / Question: this seemed a bit unclear in the > protocol i-d, but is presumably required?] Yes, the protocol must support this. However, as a meta-issue ... I suggest that "path" is good for marketing but not technically exact. An endpoint can even have multiple addresses associated with a single interface. Both of them can. We should figure out how to restrict the use of "path" to contexts where its use is accurate. > * Subflow end point definition > o [Question: Should we allow subflows in a single MPTCP > connection to have different ports?] Don't know. > Congestion algorithm > > =============== > > * the goals are: [1] MPTCP is at least as good as TCP would be on > the best subflow path; This is a hard one. One use for multipath transport is in environments where the network situation is (ahem) "dynamic", so it is difficult to maintain a connection using a single src/dst address pair. In this case, if there are problems then multipath transport is certainly better, but if one of the paths is clean, then just using that path for a simple TCP gets better goodput then MPTCP would, trying to use that path plus some poor ones in addition. Let's try to find some better wording at the meeting. > [2] on any path, an MPTCP connection uses > less (or the same) capacity as a TCP connection would do; [3] > MPTCP moves traffic off more congested paths and onto less > congested ones > * increases in the congestion windows of the subflows are coupled; > for decreases in the congestion windows, each subflow does new > reno independently (ie they are not coupled) > * slow start, fast re-transmit and fast recovery are the same as > RFC5681 > > API > === > > * no changes to existing apps are needed to use MPTCP; MPTCP uses > the unaltered TCP socket API > * There is an optional, extended API > o [Question: would both ends need the extended API , with a > fall-back if not?] > o [Comment: presumably the actual features of the extended API > are outside the initial high-level design decisions] Agree with all. > * congestion control state is shared among application-visible > transport instances (eg multiple HTTPs between the same pair of > hosts) How do you arrange for this? Currently, if a single app has multiple HTTPs running, each one has independent congestion control state. HTTP in this case is the "client layer" of transport, so each HTTP would be an independent client, each getting its own independent MPTCP state. No? > * 3 application profiles are mentioned (Bulk data transport, > Latency-sensitive transport with overflow, Latency-sensitive > transport with hot stand by) > o [Question: how are these supported? Is a negotiation > mechanism needed?] > > Security > > ====== > * exchange a token in the initial SYN for the MPTCP connection, and > include the token when subflows /paths are added to the connection > o [Question: Is the same token used whether the sender or > receiver (of the MPTCP connection) adds the subflow? Is the > same technique used for removing subflows? And closing > connections, ie DATA FIN?] > * security mechanisms will not interfere with end-to-end > authentication etc and will be compatible with legacy middleboxes The last bullet is difficult because some legacy middleboxes will not allow unknown TCP options. I don't know anything about modularity :-) Thanks ... Scott > Modularity > > ======== > > · the architecture has 2 components, multipath scheduler & path > manager – meaning that improved /different modules of each can be > slotted in > > o [Comment: it is unclear from the Architecture i-d how the > congestion control & protocol i-ds map to these components; some of the > text (strangely?) appears in a section about implementation] > > o [Question: what are the mechanisms for evolvability? How is it > negotiated which new module (for congestion control or path manager) to > use?] > > o [Question: this would seem to imply we need to define an > interface between the modules?] > > · there is a default path manager module, meaning it is the > MUST fall-back option > > o [Comment: the charter restricts us - the path manager we work > on will distinguish paths by multiple addresses] From scott.brim@gmail.com Tue Nov 3 07:27:47 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922623A6832 for ; Tue, 3 Nov 2009 07:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diacd9aHaacS for ; Tue, 3 Nov 2009 07:27:46 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 8DA8B3A67E4 for ; Tue, 3 Nov 2009 07:27:46 -0800 (PST) Received: by yxe30 with SMTP id 30so6479064yxe.29 for ; Tue, 03 Nov 2009 07:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=GG7p80xF4vlseABQpGo7cRPyFcd8pol2tvP7LEFiKx4=; b=OEpS6D0Cg7lkn6CfEgGrUol3Rt8YrGMD49st20laAdOqN+nYbTdEZtYO2MtvW88LQN C4Fnf4A8insRArY9TzygmPhdqU3MMY35O42rAH4HhhUvNhwLmQmwWlJBwMUjdFImGyqW l7ecwYYUk4hrYGHkU4C+GjaH3SC2/F5xbEHWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=kvKTv6H89r1058deovyvvPepiqnoo8p2R5pvkZ+f1FKbDTbEEh+HKANMIDARJFez0L zEhHqV+3R0K24UIfIyoWQNAfSoYLYClfoOD5qGUDnVf8Js/lh0njy9edRarucfGw+VEv xtTm4rgwaTIE76Z2e77ZZy0ptbT0whzVSBs7U= Received: by 10.101.21.9 with SMTP id y9mr207754ani.39.1257262084663; Tue, 03 Nov 2009 07:28:04 -0800 (PST) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 4sm62495ywg.13.2009.11.03.07.28.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Nov 2009 07:28:03 -0800 (PST) Message-ID: <4AF04C00.10504@gmail.com> Date: Tue, 03 Nov 2009 10:28:00 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Joe Touch References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> In-Reply-To: <4AEF781E.4070009@isi.edu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:27:47 -0000 Joe Touch allegedly wrote on 11/02/2009 7:23 PM: >> (even if that >> subflow /path closes) > > Yes, although, as noted, if the IP address goes away altogether, then > IMO the connection needs to be terminated. Joe, that's just not necessary except for legacy endpoint stacks. See the iPhone and "connectByName". If the API revolves around a connection ID, regardless of underlying addresses, then IP addresses can come and go as they with as long as the transport layer has some mechanism of maintaining session authenticity and continuity. The scenario where a new node gets an IP address that an old node was just using is only relevant if the connection is maintained using IP addresses ... which it isn't. >> * the protocol involves an MPTCP stack at both ends of the MPTCP >> connection >> o [Comment: this is in our charter] > > Agreed (as per the charter), but seriously this begs the question of > what is "TCP" about the result. I don't like the idea of doing this all > inside TCP solely as NAT camouflage. Why not? NAT is now architecture, and we have to deal with it. You could just as easily say we should be able to run lots of protocols over the Internet but we have to put things in IP as "router camouflage". >> * There is an optional, extended API >> o [Question: would both ends need the extended API, with a >> fall-back if not?] > > Seems like one end could want the extended API for explicit control of > flows, but the other end doesn't need to care. Agree. The API is to access controls for the endpoint's implementation of the protocol. How an endpoint implements its APIs is independent of the protocol. Scott From touch@ISI.EDU Tue Nov 3 07:55:31 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97323A69CE for ; Tue, 3 Nov 2009 07:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ2hsavcc4lh for ; Tue, 3 Nov 2009 07:55:31 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1ED243A69B7 for ; Tue, 3 Nov 2009 07:55:31 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3FtTol000360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 07:55:32 -0800 (PST) Message-ID: <4AF05270.1050501@isi.edu> Date: Tue, 03 Nov 2009 07:55:28 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Scott Brim References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> <4AF04C00.10504@gmail.com> In-Reply-To: <4AF04C00.10504@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:55:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Brim wrote: > Joe Touch allegedly wrote on 11/02/2009 7:23 PM: >>> (even if that >>> subflow /path closes) >> Yes, although, as noted, if the IP address goes away altogether, then >> IMO the connection needs to be terminated. > > Joe, that's just not necessary except for legacy endpoint stacks. See > the iPhone and "connectByName". If the API revolves around a connection > ID, regardless of underlying addresses, then IP addresses can come and > go as they with as long as the transport layer has some mechanism of > maintaining session authenticity and continuity. The scenario where a > new node gets an IP address that an old node was just using is only > relevant if the connection is maintained using IP addresses ... which it > isn't. This is fine if you're defining a new transport protocol. TCP *defines* a connection by the socket pair. If that socket pair disappears and you keep the connection up, I would argue you need to use a different protocol number because you've seriously changed the semantics. >>> * the protocol involves an MPTCP stack at both ends of the MPTCP >>> connection >>> o [Comment: this is in our charter] >> Agreed (as per the charter), but seriously this begs the question of >> what is "TCP" about the result. I don't like the idea of doing this all >> inside TCP solely as NAT camouflage. > > Why not? NAT is now architecture, and we have to deal with it. You > could just as easily say we should be able to run lots of protocols over > the Internet but we have to put things in IP as "router camouflage". Inside TCP, vs. inside SCTP or a new transport - one that would interact poorly with NATs. IP is more than a way to interact with routers; it's a uniform end-to-end multiplexing unit, it allows e2e transport security while allowing router interaction, etc. NATs may be ubiquitous, but they are NOT part of the 'architecture'. They violate what little of the architecture is specified (RFCs 1122, 1123, 1812). Architecture is deliberate, not de-facto; the latter applies to implementations. >>> * There is an optional, extended API >>> o [Question: would both ends need the extended API, with a >>> fall-back if not?] >> Seems like one end could want the extended API for explicit control of >> flows, but the other end doesn't need to care. > > Agree. The API is to access controls for the endpoint's implementation > of the protocol. How an endpoint implements its APIs is independent of > the protocol. Whoa on two counts. First, *IF*, as you say, "NAT is now architecture", then the API affects nodes inside the network, not just at the endpoints. Second, the API is two things - an abstract specification and an implementation. Consider TCP, which has OPEN, CLOSE, STATUS, READ, WRITE. Those are part of the *specification*. There's also the Un*x "open()" call, which implements part of what OPEN specifies (arguably, in Un*x, this also includes listen(), connect(), and bind()). My claim here is that the API can be asymmetric, i.e., extended on one side and not the other. That's just claiming that all extensions are optional on both sides, and not coordinated. Joe Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwUnAACgkQE5f5cImnZru5RgCg5DcydBItssvuc5QtwECzd5hl Ya0AoNvUj276M8fkBMqaE1bEviY0nZFT =ozlV -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Nov 3 08:16:39 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16B83A6A2B for ; Tue, 3 Nov 2009 08:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQwEI4Lluf21 for ; Tue, 3 Nov 2009 08:16:39 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3F9753A65A6 for ; Tue, 3 Nov 2009 08:16:39 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3GGOv9005992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 08:16:27 -0800 (PST) Message-ID: <4AF05758.4080309@isi.edu> Date: Tue, 03 Nov 2009 08:16:24 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> In-Reply-To: <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:16:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Eggert wrote: > Hi, > > On 2009-11-2, at 16:56, Joe Touch wrote: >> How do you know whether 5.6.7.8 is the same place as the first >> connection, or a new place? Don't you need to figure that out to know >> whether you end up with new capacity, or need to share capacity? > > > I don't think you care whether it's the same location or not - the > linked congestion control proposal doesn't infer topology information > from IP addresses. That's news to me. Seems like this whole thing assumes topology information from IP addresses. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwV1gACgkQE5f5cImnZrsdhwCgpGpXMJGcK3WgHIP5XC6JD6GE IggAn2xfi6jqoZ6RUTaUll4TDjGMS4js =pDxD -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Nov 3 08:17:23 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF59D3A6A0C for ; Tue, 3 Nov 2009 08:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJPYEAiVmNgw for ; Tue, 3 Nov 2009 08:17:23 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1F9123A6A21 for ; Tue, 3 Nov 2009 08:17:23 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3GGqKo006068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 08:16:55 -0800 (PST) Message-ID: <4AF0576B.9050505@isi.edu> Date: Tue, 03 Nov 2009 08:16:43 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> <4AEFFC63.10202@it.uc3m.es> In-Reply-To: <4AEFFC63.10202@it.uc3m.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:17:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 marcelo bagnulo braun wrote: > Joe Touch escribió: >> >>> Security >>> >>> ====== >>> >>> * exchange a token in the initial SYN for the MPTCP connection, and >>> include the token when subflows /paths are added to the connection >>> o [Question: Is the same token used whether the sender or >>> receiver (of the MPTCP connection) adds the subflow? Is the >>> same technique used for removing subflows? And closing >>> connections, ie DATA FIN?] >>> >> >> Let's please not call this "security". Call it a flow identifier, but >> it's trivial for on-path attackers to see, and anything small enough to >> be appropriate for a SYN is likely to be too small to prevent exhaustion >> attacks. >> >> >>> * security mechanisms will not interfere with end-to-end >>> authentication etc >> >> Yes. Specifically IMO there ought to be a TCP-AO mode supported - e.g., >> using socketpair of the original connection for the pseudoheader used >> for MAC calculation. >> >> > It would make sense to contrast the protection provided by TCP-AO witht > he threats identified in the threat analysis and see how many of these > it solves. Agreed. Same for the nonce. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwV2sACgkQE5f5cImnZrt0iwCeKyrt4rYoszR1MwS60Y5IkS0y FXIAmwUg6K05KwRc26wBPWLxTVM40l9p =Dgpo -----END PGP SIGNATURE----- From c.raiciu@cs.ucl.ac.uk Tue Nov 3 08:24:55 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4BF33A681C for ; Tue, 3 Nov 2009 08:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okE8HrBSJhUx for ; Tue, 3 Nov 2009 08:24:54 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id BB59D3A657C for ; Tue, 3 Nov 2009 08:24:54 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N5M9Q-000Bvs-8s; Tue, 03 Nov 2009 16:22:32 +0000 In-Reply-To: <4AF05758.4080309@isi.edu> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> <4AF05758.4080309@isi.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E3D84BC-F010-4035-A053-76D99901294F@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Tue, 3 Nov 2009 16:24:59 +0000 To: Joe Touch X-Mailer: Apple Mail (2.753.1) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:24:55 -0000 Hi Joe, The proposed congestion controller gives the aggregate multipath connection the throughput a TCP would get on the best (fastest) of the paths available (to the multipath connection). It does so only by looking at loss rates and rtts on the different paths. It does not need to know whether there is a shared bottleneck or not. Cheers Costin On 3 Nov 2009, at 16:16, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Lars Eggert wrote: >> Hi, >> >> On 2009-11-2, at 16:56, Joe Touch wrote: >>> How do you know whether 5.6.7.8 is the same place as the first >>> connection, or a new place? Don't you need to figure that out to >>> know >>> whether you end up with new capacity, or need to share capacity? >> >> >> I don't think you care whether it's the same location or not - the >> linked congestion control proposal doesn't infer topology information >> from IP addresses. > > That's news to me. Seems like this whole thing assumes topology > information from IP addresses. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkrwV1gACgkQE5f5cImnZrsdhwCgpGpXMJGcK3WgHIP5XC6JD6GE > IggAn2xfi6jqoZ6RUTaUll4TDjGMS4js > =pDxD > -----END PGP SIGNATURE----- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From touch@ISI.EDU Tue Nov 3 08:28:07 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BCA3A6978 for ; Tue, 3 Nov 2009 08:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOTY5MK7cdck for ; Tue, 3 Nov 2009 08:28:07 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E987C3A691D for ; Tue, 3 Nov 2009 08:28:06 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3GRxd7008756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 08:28:02 -0800 (PST) Message-ID: <4AF05A0F.6040705@isi.edu> Date: Tue, 03 Nov 2009 08:27:59 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Costin Raiciu References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> <4AF05758.4080309@isi.edu> <6E3D84BC-F010-4035-A053-76D99901294F@cs.ucl.ac.uk> In-Reply-To: <6E3D84BC-F010-4035-A053-76D99901294F@cs.ucl.ac.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:28:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Costin Raiciu wrote: > Hi Joe, > > The proposed congestion controller gives the aggregate multipath > connection the throughput a TCP would get on the best (fastest) of the > paths available (to the multipath connection). It does so only by > looking at loss rates and rtts on the different paths. It does not need > to know whether there is a shared bottleneck or not. If it doesn't, then you will create the potential for a single multipath group to fight with itself, which seems less than productive. Joe > On 3 Nov 2009, at 16:16, Joe Touch wrote: > > > > Lars Eggert wrote: >>>> Hi, >>>> >>>> On 2009-11-2, at 16:56, Joe Touch wrote: >>>>> How do you know whether 5.6.7.8 is the same place as the first >>>>> connection, or a new place? Don't you need to figure that out to know >>>>> whether you end up with new capacity, or need to share capacity? >>>> >>>> >>>> I don't think you care whether it's the same location or not - the >>>> linked congestion control proposal doesn't infer topology information >>>> from IP addresses. > > That's news to me. Seems like this whole thing assumes topology > information from IP addresses. > > Joe _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwWg8ACgkQE5f5cImnZrsl9QCg5mq7XhPTgxWBr7DL59oUYMWh FF8AoOOsZ02iVPDNdce69te6rWtwb24v =9OnI -----END PGP SIGNATURE----- From mark.j.handley@gmail.com Tue Nov 3 08:43:47 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C7D28C0EF for ; Tue, 3 Nov 2009 08:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY+7X8A3adap for ; Tue, 3 Nov 2009 08:43:47 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id C943A28C0E0 for ; Tue, 3 Nov 2009 08:43:46 -0800 (PST) Received: by bwz23 with SMTP id 23so7817042bwz.29 for ; Tue, 03 Nov 2009 08:44:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=l/0uwATGO6ivLJ85y/27OHF7ZJi629ii+HqefviIPo8=; b=jqBOPW0lrQodhxEbRYWNYHZZf/LbxOeyaRx1NnMXGiWe5pfnq/XB6j2eYzwUmVUCIP y0skamwZzF+r2g5WFfEZ56ElF2u3Kpv6m2/zANQmciICvHXRwbPJv/xjuz0PoUxEpefK ucUkbzG2NBLszuROfnmVf4AX4hVBHh2OSqwFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=tpJ5JCe9ySlTDmWCokBBB2n12HSNvK6NlqtPaGqzhMV/ffq8X93AYLTbvz96nOCNeU t4QZDZSTR5zY4ojuTMaG2h+t7oqLl3vK+b7MszAVRR/ZTSJ4Zjx+ns9s+VopNxpMtqyZ NHXAlL/vrm4OJod8Qnut2oYLgH3+awHsrYo7s= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.29.193 with SMTP id r1mr35389fac.29.1257266643261; Tue, 03 Nov 2009 08:44:03 -0800 (PST) In-Reply-To: <4AF05A0F.6040705@isi.edu> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> <4AF05758.4080309@isi.edu> <6E3D84BC-F010-4035-A053-76D99901294F@cs.ucl.ac.uk> <4AF05A0F.6040705@isi.edu> From: Mark Handley Date: Tue, 3 Nov 2009 16:43:43 +0000 X-Google-Sender-Auth: cb9b31cfc5b9114c Message-ID: <84a612dd0911030843u22f0aa19u6384886afa2342d8@mail.gmail.com> To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:43:47 -0000 2009/11/3 Joe Touch : > Costin Raiciu wrote: >> Hi Joe, >> >> The proposed congestion controller gives the aggregate multipath >> connection the throughput a TCP would get on the best (fastest) of the >> paths available (to the multipath connection). It does so only by >> looking at loss rates and rtts on the different paths. It does not need >> to know whether there is a shared bottleneck or not. > > If it doesn't, then you will create the potential for a single multipath > group to fight with itself, which seems less than productive. Well, so long as the total window increase per RTT of all the subflows in a connection is no more than a single vanilla TCP would get, then you don't fight with yourself any more than one TCP would ("fighting" in this context is pretty much equivalent to how much unacked traffic per RTT a flow can inject - the ack-clocked traffic already had its space last RTT, so isn't "fighting" for extra space). This is exactly how the proposed congestion control algorithm works through a common bottleneck. - Mark From c.raiciu@cs.ucl.ac.uk Tue Nov 3 08:44:19 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2576428C0EF for ; Tue, 3 Nov 2009 08:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjJSXokcDgCU for ; Tue, 3 Nov 2009 08:44:18 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id B066B28C0E0 for ; Tue, 3 Nov 2009 08:44:17 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N5MSB-000BwL-Qy for multipathtcp@ietf.org; Tue, 03 Nov 2009 16:41:55 +0000 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <4AF05A0F.6040705@isi.edu> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> <4AF05758.4080309@isi.edu> <6E3D84BC-F010-4035-A053-76D99901294F@cs.ucl.ac.uk> <4AF05A0F.6040705@isi.edu> Content-Type: multipart/mixed; boundary=Apple-Mail-10--213411055 Message-Id: From: Costin Raiciu Date: Tue, 3 Nov 2009 16:44:23 +0000 To: "multipathtcp@ietf.org Mailing List" X-Mailer: Apple Mail (2.753.1) Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:44:19 -0000 --Apple-Mail-10--213411055 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I don't understand what you mean by subflows fighting each other. look at the examples in the picture attached . Say for simplicity that the RTT of the multipath subflows is the same in both cases, and say link 1, link 2 and link 3 have the same loss rate p (i.e. disregard flows B,C and E). The controller will give the **same** throughput to the multipath connection in the two cases, i.e. what a TCP would get if it saw loss rate p. In this case, there is no throughput benefit for using multipath; multipath increases throughput when it can affect the loss rates. In the same picture, if the flows B,C and E have the same throughput as the multipath subflows, the connection will get: 1. (link1 + link2)/3 in the first case 2. link3 / 2 in the second case. Hope this makes things clearer. Cheers, Costin --Apple-Mail-10--213411055 Content-Type: multipart/appledouble; boundary=Apple-Mail-11--213411055 Content-Disposition: inline --Apple-Mail-11--213411055 Content-Transfer-Encoding: base64 Content-Type: application/applefile; name=Picture 1.png Content-Disposition: inline; filename="Picture 1.png" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAJAAAAMgAAAAoAAAADAAAAPAAAAA0AAAAAAAAA ABAAUGljdHVyZSAxLnBuZw== --Apple-Mail-11--213411055 Content-Transfer-Encoding: base64 Content-Id: <4F3A5D9E-8361-4911-88D5-27A95BF7EE13@cs.ucl.ac.uk> Content-Type: image/png; x-mac-type=0; x-unix-mode=0644; x-mac-creator=0; name=Picture 1.png Content-Disposition: inline; filename="Picture 1.png" iVBORw0KGgoAAAANSUhEUgAAAX4AAADOCAIAAAC2Bf5qAAACOWlDQ1BJQ0MgUHJvZmlsZQAAeAGt k89r02AYx79tkY1VypTRHQTJyR/QSdeuIHpp13alW6mlS9V5S5M0qTZpSNJOhwf/AG+CInoaKB48 KnUXGYLoQWGiuOl5/8FgHmRkz5vwtggOLz4heT/55nm/D+/zvgEiu5JldcIADNO166V54frKDWHs B6KIYAJxXJJkx8rVahVKOSL2vyPEPn2dYV6nVi1t/VNcPz3YfvC68it2xCQux2wqCIQSJExpAWcZ NwMWGa+6lks5OmNZlxTiu8QJW6zniV8Qx7SA3zBuBvyRcV/W2Nwd4qSptE0gPE58UVEdmThLrCqO bBAzn13D6JJ/5D7xOdmyaW7kFfEM6wuNFM0NIPOUPN+OtM5VYPCMym2NtLMfgJPfgHePR9rejt+r UHzcaaVTvl0oOgCOPfS8vWvA2HngYNvzfg887+A51f4JbO7LPbvv51LR0GfgX+/BmgN34AutgcLf o79z0Bc/Kwms3wNWskBjE3hCfOYRcOIyUCNNzCKcTvM76CFYRAvFSkUopeZmyeF/h9Hp0V75MUnP 4223LNI4RfdWy16oczab1SucVae4zLnVXihzttzacO6aLlLPA5+b0mKNs9mpsvPu+ytqocjZ7tUb nG91l4Z1VbMxrOX0l4f5ilRY4vlrer7KGQUUUaFLQAkpzGEWyeDcUQYmXwLZxVxmvvF+Y5oJf4Sr 3naZkO9ad+y2prtCjv46Vch3DavnqnZCKJvyhYSQSiYzLO8QSEGuXidH1IMAACAASURBVHgB7Z0H YBVFGoCFkJBOEpKQQAjSexUUEBWkWUFQURA8URHbWQ49e0Xs3tkVERuKBSynoNjo0jsK0msgpPdK wn0vA+O6773NK/tKklnjY3Z26r+z//x96p04ceI0dSkIKAgoCHgXAvW9253qTUFAQUBBwAIBhXrU OlAQUBDwAQQU6vEB0FWXCgIKAgr1qDWgIKAg4AMIKNTjA6CrLhUEFAQU6lFrQEFAQcAHEFCoxwdA V10qCCgIKNSj1oCCgIKADyCgUI8PgK66VBBQEFCoR60BBQEFAR9AQKEeHwBddakgoCCgUI9aAwoC CgI+gIBCPT4AuupSQUBBQKEetQYUBBQEfAABhXp8AHTVpYKAgoBCPWoNKAgoCPgAAgr1+ADoqksF AQUBhXrUGlAQUBDwAQQU6vEB0FWXCgIKAgr1qDWgIKAg4AMIKNTjA6CrLhUEFAQU6lFrQEFAQcAH EFCoxwdAV10qCCgIKNSj1oCCgIKADyDQwAd9qi49CYGcnJwDBw5kZWWJwx3r1asXHx/fokWL8PBw T3ar2lYQcA4C9dTpo84BzL9Lf/vtt7/99ltsbGxoaChIh8FWVlYWFhYWFxcPGTJkwIAB/j18Nbo6 BAFF9dSel/3DDz+sWbMmOTlZIB0xsfr160dERISEhMybN69Ro0Zdu3atPRNWM6nJEFCynpr89jRj P3To0OrVqxMSErR4Rz5v0KBB06ZN586dCzsmM1VCQcCHEFCox4fAN7PrJUuWBAcHQ+PYaxTs07Bh Q9CTvQIqX0HAmxCwu1K9OQjVl5sQQGC3Z8+esLAw43Zgu7Zv325cRj1VEPAOBBTq8Q6cPdtLeXn5 8ePHAwICjLuB8MnLyzMuo54qCHgHAgr1eAfOnu0FnFJRUVFtH2i7qkVP1TaiCigImAIBhXpMAaOP G0HEExkZWVZWZjwOiKO4uDjjMuqpgoB3IOAp5TqGJPv27Tt69GhJSQk63datW9tTvnhnnrW+F7Tm W7ZsCQoKMphpaWlpt27dDAqoRwoCXoOAR1DPr7/+unz5crgAxJ9Q+PySA+oZPXq02nVdfrV//PHH +vXrAwMDAaz295xzzgHjnH322ULJhRrLZhf5+flU7Nmzp82nKlNBwMsQMNmaGSzz7rvvokY5/fTT WejaySDgLCoquvvuu6Ojo7X5Xkj/+OOPGNoxnp07d1588cW6Hnft2mUzXxabM2fO4MGDY2JiZI5P ElCR7dq108l0Jk6cOHPmTDGelJSUV199tUmTJmjZdSPEnCc1NfWBBx5ITEzUPVK3CgI+gYDJsp7v vvuOLwT2Sod3mBvCCK7HHnvM+0oWRrV161ZYv9zcXGsogyi//vpr63yR88EHH1x99dW4RNkr4LX8 li1bjh07Vttdjx493njjDZnTrFmzSZMmgd9BNPwi2UH6U1BQkJ2dDe05bdo0hXckrFTC5xD4G2Hi 5mj4PuEIWN82DWppHMci9uRFixaNHDmS288///z5558nAR2Ee9H9999vvV27OSRtdfwJGBtf4/z5 8xs3brx06dJzqy5ZBvS0e/fuUaNGyRwQ5Z9//tmpUyeZ48PE5s2btVgbCRrWyTqItWnT5l//+tfG jRuZC3gW8TMcLvIdLng0Hw5eda0goIOAmahHiDmN1bd8/5s2bbr00kv5KviqEQD997//RRp96623 Ypny1FNP6cZn4i3Dw7uyV69e11133ZgxY4YOHTpu3LiffvpJdMGoyOdj1vYIexgVFdW/f39tppfT aMS/+eabV155BVrmn//8J7d4YzGGjz76qFWrVtaDAb8j9+GyfqRyFAT8BwJmoh5YLWMNC9OGEYMm yszMFPJmMBHyC66rrrpq1apV3oELih7wHUEkfv75523btjFmeK7hw4cvW7YMqkE7BvCO9tbLacb5 3nvvvf766927dwcpI05mADBZoB6kNqBvL49HdacgYCIEzJT1EJzBmOQR46YMqnftHKB6+JwuvPBC babn0s2bNxfBa+BWhNSWAQwbNuzjjz/2XKdOtQzSgczp06cPsuGFCxfOnj1b4B0a6d2799NPP/3k k0861aAqrCDgbxAwE/VAwuj0LzZnC2MlvY2++uorNEeow4hu5cN4Dueff/7bb7/96aefbtiwweaY vZYJP/X++++DX5ATr1ix4oknnkA6pusdoZgjKF5XS90qCPgVBMxEPe3bt7dnUMvujZ6FmVMAeSdS XgEFLH0QTqN7euaZZy666CKK+Qo6YEO0RYh77E3BCwNDAH/GGWeAcRYvXgxLpeIKegHmqgtfQcBM ux4YrhdeeAF1lbUyBb9qaIp+/fohtkCZBZXBhNnSEbJ89tlnYvKwP7BdBNNzExYl5RVlx0+42Yhx 9YB69cKCq/HVNG5B95RoO2imEHUj3JG8la6MulUQqE0QMFPMDOGA2giVedu2bXUcAZY+9957L7Z5 a9euHTRokA6CcBmffPIJmV26dNE9cuq28sSJr9emrd6d61nEUzWm1vEh153XNDjQXQQE+4nMG6Mb CK4PP/wQ/ZRTU1aFFQRqKATMZLgAATpdbHYED6WFCMgFmxREGGAfRBWTJ0+Gt8IyhVuCyCAk+s9/ /vO///0PXbu2lrPp5TtyVnkF7zCwPWnFoDlnR6grj20RGiuMrfE7efnllxXe0cFH3dZiCJhJ9Qgw 4XOA4nzBggXp6elClU4+KhtYLaQ5cFXosLFJgfZBoY7Zm1kSjfLjlb/8nklfTaMbpuWVHa84ERcR lByrdykw5V1mFpTvTy/esD9/cJfG8ZFGHpv2uoPTfPjhhw8ePAiL6jXVnr3BqHwFAe9DwExZj3b0 kDnHjh1LS0sD6YBccAKAutEWQLSMwxHanNtvv/2GG27QWeVqSzqY3nQg/5PfjlJ4aNfGe9OK9xwr CmpQ7+x20fZMqx1s1maxysoTv+3MLq84cX7nmAu7x9osYy8TlhN0g3AH6k9YddsrqfIVBGoxBExm uCSkMFbGawFK58wzz8QRQYd3KAau+fe//83JLUKt/txzz2m9BGQ7jid2HCmkcFRog7DgBs1iLN7b CJsLSqoPoOV4F7Jk/fr14qqIHdGpzDdI4FiLA8fAgQMffPBB+M2VK1cqvGMALvWo1kPAU6jHQcBh 1IMbF0e4IG3Fgo7PEh7Ewbq6YvvSLWaKAiNEhwUG1LecQpVTVK4rZtZtVKjFJepITmlpeaVxm9B3 M2bMwIsKk0UkyphQw5MaV1FPFQRqPQR8jHoEfNHHP/TQQ7hHYmdMUAtEQngtgYwch35xWQXyF8qD dPiFyYL8IZFf7BGqh5YjQyztnzhhwT4kbF6I2zEg6NChA+5jeM9jXqDC5dgElMqsgxDwC9Qj4A4L dsstt+By/cgjj8CbdO7cecqUKdjXwapU+2Iy8k9SN5FVGIfyIlFU5inUExJUv+p0z9My8myEJSUu F7PAPhuXEYQ7r732Ghbb1c5CFVAQqDsQ8CPUI4GO5SEcCj4NMCnIgLASQhRNnEMk1rKMLpGRf/L7 Dw06aWgT1tCSgBrSlTTrFsIqJNACPUFtyWaRH7/11lsYKGFgCbHz7LPPqsCMEjgqoSAgIWC+cl02 7WYCA8V/VF14MxHaAkHJjTfeiKYMrTwXgiFtJND8KnFycCDSbYuIhyukCgehhOLyhJKLLhoGBhSV VeaXWBjDvXv3YhWJOSXqPKIAYbDTokULyzjUpSCgIGALAp5Srtvqy4Q8gpliFoQBHhE2MJjGHg8l GldKecyWjODoiJDzu5z0DkvPK/tth8VrbED76KAGHiHu/jicv+/wsbztv+xZMx8Pteuvv378+PEq EqAJr9l+E5hrXHLJJXgpszNBDl922WXa4CHoK/BHIWgs5hr22zDnCTsi2+FNN92E78uVV16JWayu XXv5FCNSFXakrN7zzjtPV6vu3Pov1WPzHbDauPjIeUroLCKl//777wQAW7xq48H9+wMC6s1NSmqS mNQ4PiEsKi61NIzf/QGt4uNjIyKjA/4eK9pm+/YyiTWal52Vk52enX4s/diRjNSU9GMpxCdKP3Kw e7/BL774om/Didkbdu3LJ9ITsjM4WQK/wpKDYkD3mMIzUwKJEAgB719sWb0wcVAPBuignoyMDJsB Gwi0RCQWa5SEXcUdd9xxzz33oIIAS06YMMELo/XDLmoY6tFCkDheVdH4LOH4vliVunZvXmx4QPuY srSjKWmpR46kpGTt33dk58aUNYXFBbn5edmVFZX1A+qfduK0oIbBIWHhIaFhQUEN6wc0COCvAQ6h 9Ssr0Kodr+C3vLy4sKC4qKCosKDieHl9SgQGNoqOjYqObRTduFFMXNPkVh17nNkvJKG4YUJy4+D+ /ZO1A1NpT0MAURpMNDJBeFuUhtdccw0e/3379sU4Qxvf1tPDEO2LExCgxLEU+eWXX2Dw2RolxsG2 Ftt9fBuJnC3Kgxnfeecdhk1J9J4K9XjnNXmql4pKixYMv424JrFxTZp2Pu20otKKsC0ZZPZu1Ugo wkXfvO/CgryCvByQS1lZaVlJseUX65yyEnTyAVVoBsQUGhoe3igKdBMaFm5v0BhMH8goFl3bK6Py PQoBdIhgHBFsBBLDo33ZaxxNAjTvl19+iSYEdg+mD6EkUj/Kg3cI1E/EJXyDZfURI0aQ5uAWEBB2 7TK/riVqMNWjfVVC/X5Swlz1QGi+tWVEmt0yPKIRf9aPnM0R3Tmg+ne2YVXeCQgkJSWhVXSkAnYb SOJiY51zfHGkZVEGqRMoBgKHYLsih1janMJCVEnrRsBKRK1CcFlnxT0ekb9aA9rTOQ2qFFsEzZAd 4WYl0vZwkCzpckJ0h4DJ5RZURfchgKsglqgG7eCggzAOQw2C/KMYJSgddg8G5V1+JE4uwTxNin6I 24+rEKJxbZtIoyiAkAjKCCkVZxZpn9addC1BPcJt4hS2sby+ilNY6KTlnwdeqehOYD0PNK+arB4C 4B2kzvgJ2iyKPSeyZ54iwoMbQhCDZBrxMKeSEBoJ1ttmLRMzsYnlwlBW2yY5eE2TA7FGYE/ruHra wrU4XUtQT8Mq6z7iZshXJdNIlj10EZeDlkXXHupCNWsPAnjGrVu3DqEyIh6EzdbFEACBdBD/gW4I EiAMO3HZmTp1KmwOujBELda1TM/hlCfwIz40suX77rsPwRCRUu666y5xDp18VKcSNcyux967Wbwt a/6mjNCg+sO6x4kyR7NLCFdIemDHGGlnaK+6a/mbD+RhynxGy8ir+7kV4cy13utmLbyL4WKwHCWs GglCPiHZFYQDaAh0AzMFugE4PMUTEFMMm4CCCQJh4TaoNUy1WdJDmRgHmBWpykMj9HSztUTMLCIl l5Qjfjlpu0wa2EHyCLyDYU7akUOZ6ak5Wel52Zn5eTno0NGjn6isrG/RajXgB3V7WHhkeGRU47jE 2ISmMbH6oyB0L6O0isgSHhu6R+rWQxBITk6251csTq9mAcDg4EPHUfQGQaDi4+MxR+TEISK3WA91 yfbsTQfytPy7dRkzciyR7Ry5EqMajjwjThjoO1K+RpSpJagnpsphnbUCxhFvaM+uHdvWrMs+vH1B 6s6jh/ezXhvHJWBqGJ/YHJwS26QpBjvo1NGsl5eWcDh5SXFhblZGKf8U5IGbsjKOFebnJTZv2b5L r+5nDujWZwC2QLo3WlxmwW6Nwy2+8uryEwigzIYIws64Wu8ZzvzAGogTaNGRaQe/fl/evI3eMErU dmqcPpLNGq247tyTlkHGhWvK01qCekSYnvLS4gXffvnn+iU7t20Ji2sR1bxz5z4D+/W8JTahWWCg 02FMUX+mpx7evW3z5jXLZ73xbFLLthdcfm33PgPEqyVMj7DoiY1QqMdfVjtiFJRH+B5Xi3cYMaHB OdMVe2iC+crykM0LNlvMwcSFDqFZjEdi7J7qofp/yysqQT1/HC48lFnSvLGPB1P9cB0uUUtkPYgS Jz/w0u7Ny/ucM+yKMVd16t57waYMGKKW8SEt48w542H39s3z53xwYPf2cZPv7X32YHzltxzMB86P jmoVURW7x2GYq4IegQDHqP3www/Id4Ssx8E+sMRBN4/sWZTflVr0zsLDpDs3D//jUAGJfm2jfM7p rNqdg4lsv7aNRvepRgjg4Kz9oViNRz2rV68mvjpKhH4jJoW2HdS0cXj/9tH5xcd/rQoR3/P0SBE8 zCxYw7vNfvv53OzMi258rCioCdzW/SNamtW4asdlCHCcCZZ7HBKNW6lTjRCJhdB02PU9+uijVPx2 fdqyHTkRwQGDOjf+fmP68coT7RJCkxr/Lay4U+27VhjaLTszLeOUt+CevQdSjqSU5meGnVZIrGHo cc5TQJ7FZLFLxE6yTZs2nDfVrl07XExqigNzDUY9uI+i3cBkCyMxtBsrduV+sy4N08ILesRxXMS2 wwWkz+kQI0x+XFsB9mr9uXX9C4/9q0P/EbfcfseVZyn1lj04eSkfxRYRncA71odEOzICzH9wfWA5 YXm4YH8o3A3EcvcWkSt2ZHO0CSeOdGmu90p3pFnjMqCPnMy0zPRjmWlHT/6lp5LISk8tLipsEBgU E9cE0WRsXGLj+MTgqCbp5RHhMU2mTjgzPuovPAj2wXkVpzAUdjgz4xCPwQGxMTGnhprj7CnjMfj2 qZdQD0pQtInEHtTO1p0QBwTNwGUZRh0DraAgixynoOT4U9/srag8rWOzsAPpxUTSSWgU1CnJ/EVD X3BbG3ZnLJ/zcsOC/XM++7im7DNa4PtJmu2dc4E4dvXIkSOY+aJvJp4s9ji4Yjo4QiQ1mCl///33 xHJysIrNYtBNT02bllUe2qH/JZdeNLxru+Tthwt2HC0kCFT/dtE2qxhkomgryM/Ny87IykhDqZqd kQYVw29OZjqJvJws6kbFxMZUqT6qfhNRg4hERGSUrmUsyJb+aakyYUBit+RqljQ4FMaTkB2YIBAL XNhY6xp0/BZbcJAav7CxUFj4yorPzfEW7JX0BuohyA6H+WJFyr4kMbEMcXDttddi8WVvfDbzOSsZ SgeHYCL1aAt8tfbYyl0WWx55ecjHQZjB4rPeonQTp6oiZXD/vGY55rqTANdMnz6dT4XVjH0NAZhQ REKDwARxdAcB4YxBwedN2ArsksEapgRmg96Z8vJXu9b+mLVnXVlJUWKLdgHRLaKatBh4VteEpkmV FRUlxUXyr5R0SSG3RQX52GoU5Gbn5WbnW/5ySosL69WvHxbRiDgH0Y3jG8XERsfEYbLBH9pV8EtU TBx4wXh2uqcrdmajvR3aJWZYN0d90LDexqARvKwzp9a1bO+WFwFgt23bJlg8UYytgm+52ldjr01t vjdQz2OPPQYRCOLElpS1Iron8CAnr8MoEfjCKdSD3hSvX6xRrTdGFJBv/XKYBaSdoYfSmPPcOrQ5 1Pju3btHjx49ZswYIttLRYmHOq1NzQrXKpY1mibdvFjfCO8GDBhwwQUX6B7J240bN0LwEomCsDjW LchiTiXQG8xabjnK7ZJe8cfLin///Y+flm/KSTsYVJKWl5XWgMgpDRuCJIOCQyyoMjgkNDwiNCwC W7CTiYjIyEYxEVHRPHCqX0cKb9qfl1VY3qNFxDVnJzpSXpQhgh2cFy6saP0MrJysG8QyE+MDyBy8 bbWrmr2BrQIyHyMG61pO5XgD9SAAmzVrFnwp8U4PHz6sVUDg7OsU6oGSBJHB29uTJh6vqERJUXrc s+45WCq2jg8NrQr/DLj5isaOHcs+xjSJIuTUC6ibhZF04MdA3C92I5sQoMCePXvwsezYsaO2AAQR bPsHH3yQkpKCatzcg1uXbM+atzGDkyMv6hlPp2i152+wGPh0bR4hrDe0I/Fy+s8jBeypLWKDbx+W 7FTX0IawCGzVs2fPRg6trcsReE2bNrV2IgPIHM8Jm2IvrDhCJegGbDK1rTmb9rhdD0dKsIkR1Ylf 1hOnULm8XKCYYLUAoj28w+QbBNTv2Mz8PccYrOwqxHyC84KdZHg4SRuXV08tAR7T09lU7YGC1cK6 B5jg9NTUVNY6VZChEpcS3hbvJ2h+7W5srx2n8nOLLGG2gwMDRC3OcmOPQXoozNadasr0wg2rgvyK ETrVOFAighpRjdjmb6u6YGxFC8iD5s2bx36pkwfxzYJ97OEd6oLCoDr5qF2T64vePY564I9wFMZh j/4wHuXWNdSDCgMikHDrZkm5xPzN+oXkeemllzjABzUtR98gAjer5VrZDhIE+QFYTxA2AQaB7ZoL +SA7M65b0PkcnYgBjhQXWld0M0ceLiDbAQ0VllaUadyS5SMvJ4SXshihC11DpKCZQSbAvkhsVmy4 Ea7t2LEDDMJXiV0C2FyicgxWDHZ3eme1U52dgFPzXBiMqOJZ1IMckaAkBElB0k5/bGVYfLngOEcs W6qLUAMuT9ULFYmMSRgE5D7E32XK/oklvQCHartAlGNN58tacGHCtQoRIR8JjqA84iMBDcFuo05m 9yISO4heVjElIY5O0oYiIA3qESEKTOnC5UbE0QYY0MMGQo650A5QffPNNyEe8VzDYx6MQ1BX2oHA QWoG2Q4bi4sc0gOiAkDIG3eBkA4pp3EZ46euzMG4Re1TRDMEqUX9iWsfF1H4kQ1DRWvLVJt+/PHH Ic4hJaot6Q8FEF3xkcAgoAiAl/aHIfnhGNiEHFHxUIaSYvwEM+YLQdDDZgadjxgI9AQhbOLshMtx oCb2m0j7A+qR5mklVZ6Drs0aYpPwHTt37mSVIn4+etQiUxfX4sWLIYhgSgCpVhp76rn+X4hWN4Hv WaqHVQKvLkcNRcctmSjUZYgDVIBEtwXp8q3KkjLB4VYABXWYpAblI79N4BWNSIu9BR0NxwFyeIvf DtVXA0MYD1fFzmk8APQp1tsvpiVoizEC5GJjox2zNFynUM9f+zGiQ0Z4vNLiJ2zvwgsZZ2OLzU5W RmG+5QACHI/JDG8UHR4RyVEoxEIgzndEBL/RBqG+7bUv8mVEOgYZUQ3YbLSExANVILJ5qEgsJ6Fu YGDhZ2VRMDvGd6xYopEAdplvL8GWUO3rs1dX5HsW9WB6o2PpOU1UTAwiyHhkPIXnRDjvt/Idg/Gz XWNPQQBwofnCVN+gcB18hN6qWnIdbp3t156wE34Nix7aQW06Z84cA/bNcfAKmQ6nk8gqgupB0iwv VCX48eHQd2jfrpQDe/B14OQSEQshIirGEvY7MiqhWQs072AiDlCiTEFeLvY+nERQFaqlnLMGMPaJ jo3nF0sffmPiEyy/hkFaZBxeZwVPfEQEn0ddhbQURlVu4eQzKRwvwDhcuGLIOQJ2gG8sLsDqx02G 17Oox5pyY+YOrhL0GqyquXPnWtvvSBj5eQKrAjQIhNFLSEhA1u7no/Xm8EAZMOPGUj+eYlhozJfh qo7SBvaBD0l+VC5PRBA32sBy4ixbqAPiPa1b/uvGVYv+2Lgaz4YOXc9o3aHr+RdfiX1gZJSjhtcM jHb+smzOSsNzAiwGkuJkN6K1xCUkEdQlvmnVb2JSk6bJRHcR8xIjoQUHT0BBggPpjXgU2Q2iUu1B iQI+ED6oC3W2C+IRgnxEyAbfXRVAyiGURHnXfr1h1+PCyEC6aE8hHK644goXqvtVFVhrZKJwXuqY QO17QdI8bdo0PgAofG2+SCPdw24NRxkd1WxdEjKETZtGUBVXW9i6ujbnia/2FJRU4KnQqsnJIW09 mL9156Edy+Ye2PRrm47de/Ub2KvfIAwItbXMSpeVlqQdPZx29JDl78hhArakp6bghMGhb0kt2iQk t86o1ySmaat7R3c7PU7PcYFoENxw4cyFQIdzMTl+A38UNB6ckOEsUkaIgz0hYYzsxVHE6wWcxfFn 7szdT1EPqiJWHkvTnbn5T12s49h2EGmJM5j8Z2C+HQnaFlhyCHtUuZJAhpLHLRsRD77BxiSPHDzY h8IIMvBoQdAm851NPDp3N+HfepwecXpVoJW8nOw3X391zZIFPc4bOX78NbHxTpgRO9u1vfLEroNl O7x/18G9uzZu3Z59dF9sZGCv7l0x0AVBwEZB1EAegnkxO+aTwRAB1gk2CgWWO7IY2kckhAG0To4G qNEwolnHik2+MnuDN873R9QDxlm/fj2sloMrz3iGfvKU7ejyyy+HlEM97Obm7CczMmUYqM+XLFnC Fo3YkqXMyTAId1A44J3n7F6NeTRBUR955BGX5foS9bSIDfn5uzlffPBmp34XJp4xMj4+rk8rvbeH KdN3vBGOOVi2I5vyY3oEl+ccBteAr0HQJKBNnIWVI/0ivyd8PQgdCQntg3T4hbyCHcOcx/1v0+9Q D6sHyhm1lzs42xHIer8Mr43NGQYbFaYuKKf3B+NvPbLNYk7CV+TOe+csdnZjXNixkTMQVdibu2C4 mjXM/d+Mpwhref0dD+TUj+eM2UYhDc7wNepBury8CvXgOdjSiuGyNyM385HpwBfv3bsXNARxyq6A +FKe6exm406LmRkNnB7WpRB74F1eszvG1LrRv/3221DgBEBwZ/3p2vSfW8hUOALMmjgLAYtSNMSe 2Kz8Z75OjYQF7f6axjIFuT7+R6hykFY462TEkW1bFn3x5fK511x/ywWXXc34sw/k8eu5UyQdB5E8 3lKjf3O8toslWZ9oSLhcrG9YzTmqh/AXGOCwQUGDgYMYGRQyNhojR47E2sKwo2oe0ho28viF4qdv bcpRTeWa9hjmC70MQkHsJN1UE9S0qZswXsx5MNqEaWXJYSjP4cLCJxsZBPEqMVtlceJygT0nsg+M MxyU/iCdvWrSPRWnNZg05fEzu7YWA8VfnLBzBLok3KUJQ3ejCSytV+7KoYE7L0hO8nW4aDfm8VfV v6yn/sqzk4JT4FOBJ4fuAt1gl80vafgI2Gywkp161WfzEaKBxsYJdWCtxzuAg48BUxSc+q6++mo+ JMwIqoeRKnEKAvgiYRfHkkNvyEaI1QJ7IQ/JJ2oPpvNwW4RVOfn0UAAAIABJREFUwY0OtI5UQnv8 3qk2/vYv0RSwmMe6t/uAiy++7cWImL/iHws7Zpf8Fv7Whfs3Uqce5A+jcX8+OII52Ag6GiQUsFfW fmXw50jXwUou+A1A7CDZQaxI+A/On3ZTZm5vLixT2EPkRygdrcvYy6ckLC52a99++y3KfuuKbuZg Z4hsQgTlgztA4Opmg3WnOpKyHj16gHogk1kz4BrmjnQZMOJDh0EGUmp2SozovvjiC+hoUBXe2Dr4 sIkSXRfnDGh2GHxORu47+FLKaN0mcJgiRzox6Frw5q0cVXCQo9+sN4fnQl+OToPPD7kd0gqbfUDx ErSJMjaf2sskQCoaH4yVWRYYINgr5n4+zD8KSNSQKG6tW0O0RIBO63yqEGoA2ScIy+bRutZVnM0B ngh9QECwrnwtaGfgGpxtpC6Xh+3C9ge3Ui0QMJffv38/OJ1MNksCrYCMMKM/66yzMK5Dc4raGFce yCV2u65du+JkgGkikibhOCrQjWhQfPBa+2ZtR95ME6BedEfAVm/267m+HBIzI1fmu4W3MhgHbw5h OFKMallrtHQQGhh30xrRnnAbMWjWxEeIwzFSwJZECO1ZneA7rf04YgK4SAyxRKco+FmpkydP5hbZ MCGEbZp+uj9C+Fb2bXAQbl98D3i33XnnncJd2/3GnWoBxMexQvDO2IygtQU48CwmqhGcGoyDhaGA Dh06pC2MsxIg1RqjEkaSCz0x7xGOjElNnDgRyxcddx9S9VVzwppsTUTqaeBkMFNZ3cSE8J/Aplm4 sJvYsq+acgj1oM9CdFftENnDWQT2UA+rGW4cyggdBEGGcNtnBVTbpokFMFLgwwZFIl7B6Rk0RBAT MJHogogBhHEjpofskcg7XNyCpBAHeFodDlH5xBNPsP2i48PykMPCQUB4EsjxeDrBqwHbokOF++BV wmNyS/QPPlF4GfftODw0fjYSDtKSjRMIAjCCX6yVpBDmyKRlSetEeLDlc9CiHuFQStxC68Lwa2lH DqYfO5KVlkoE+KLCfM6zZVsNDLKETuUQ7YYhocHBIYFBwQRTJbQqvyFh4QRU5Y+Dtq0bNM4RqEeM 0LhkTXnqEAjAGghl7E0JKSlME/sM6IkFiikq/BeyZ8RD8BFQTCRgvJFlgHHYfFA6sKPaa80L+cRY w/qDjgh7iDSHBDQ53oywXUJXoh0DRg1oapEWua/61TZrLw1kbq66MLSjUyQRkGY4CripQBTdgUd4 HbwC3otuADj7oDYCMhLF8DaBBt8StaAXXAstruvFE7dImiWhimkidpuI5+CtXOgrsuoox+JTVA/c lmC4RIRAGsStYf2KRds3reY0pKz0YzhzcYxEdFwTzPpAN+CasJBQUAzn0mKFTLj4ysoKztQGK1n+ Ciy/BI3HY4tntGY5kSK2SbTlLz6uSbOk09sknd6WA3BsjlzE/I0MCbD5tCZmOoR6+B6sF6ucLWEu safgG0ZRhfiG0Gdo3NkTyIF655sB4xCjCD2orOLbhAwHyafFOBkMiBXMgtARpax2bITdwTYECToK OG2+F9KC5oLPhViD6UPwRIx0JNMQbgbvwnhg6AEQuNIC/J12RghrIVcR0Fq3DCaCpgD/Ik+BSDRu 35tPeWUQ47walhy4hq7Z4QAREdpc9laJCTtJ9aBOQrSMPhvckX5ge+aGnYd3bTm4dwcETbc+A/oO vHDczf82djSvFhT4keZmZWSmp4pz/o4c2rdp9ZLUlIN5OZlgohatO+Ke2qZjt1btuwSHhNFaSZll oZp7nmW1g/RoAYdQD4vPIIQH26MQ6SHoYW/UigaQ0bJnsrIRZKCJ4DNGkOFpzsUFeBHaArcXNCbg SkndQCCwiOHCPBeRs9qhIoxAKsEFHmd7Rz7KCEGdiL1R8ZDQQrva1tgSKEMLfKK0AALCoxXGCjkr 7Kc13pENsgAog4O4PT2DLOmFBDDBcRFdOKNiV0NIL3h8WGZeGTp1LoaBNxNsslPjaRwRJMqzff6+ etGyRT8fOLA/OuH0Pr3P6D/4kuvveoxjbZxq0KAw1tJ4pfPXvos+pAFn2+7ftW339i3ffTZz17ZN nKjTtffZwUlnxLbuFXtqhAYt15RHDqEemGR06uinDRglmDJ4Lt2XAFmBDosLcGzevBk1J9iHW44H QvXgIRixZUkjCNEFlqCwymRyXgX6CxKCc9bmd+rS7fIrrrz7X1PefOttUWva08+wdmFPxO2sj2f3 699fpDF79bLWA/k3ShkuOCAgSbA+1GGc6AAbizAYmTRYHvMWiCO0eKAYtgoIOhRAyG7kxd4gxs8v PDICfsxeEH9QzFiWx7bBhVxM7DGyEZ8krNXkYhiYpHK5M6SyvGOrvn5z1/pfmiYkDL7g4jG3P5l5 WhyCngHtY9xp1tm64JruZ57Dn6iYmnJg05rlPy6YfXTP/bvOOy9g0rU4o0u+2NnG/ae8o9bMRH5A ccASZx1bjx7JDp8B7ubV6mXAXxjy4DDBrkUkaha0dWvu5MzflL7sz2xtbCd3WjOo2zkpbFz/RJ+o G+AvYDTwg+dsBjAOUnBkMewKUC5gf8ysgCrYhAvsAw7iAhlxQRcQGFxOCskOJ6DhlQMaArXJfJsJ yC5k3hA+Np/W9EwggMrVIrE+c2TT7sO7tE7gsOPVu3KO5pQ2Dg/kEGTfTjC3qHz9vrzjZaW9gnfN +/pz6FYYZ0SCmGv7dmDu9O6ojQDLFGTBu2Gt6/qD3mE/hGepFu9QkS8EQy+kKjDqSC6QC+pac+cW S/PF27yBdxjkH4cLv12f7s5oXavLgkNDjDZKnHcKXQklgogK1gP+Cy4DfgQgwxmBgPiFXAUliYgK kpdEt4itHa4DvFPH908hF3Nt2H5ba+3atYjV4D3RPCA2GjvhxuCwyMz8MmRJmQUWO9KosOp1u56e XU7VKT2RESHjrxpFfGE0xWwViN7Y7LH58HTvHmrfCaID8SQKSxY9uIb1ygXxz3JkoWP/ojWQqXas fAyY+cE1YEeHdskUe0KUET9tzaTrJo2COBMdwic2IrCZZ7xdMvPLD2eVrNmbO6hzdONwG2RgtRBw rQDhRIRlNhjHhRYgfDAcx4Fj+PDhsrqDIReQBEnMJevW6AQifESQoB5OMZIS9PZNQ1fvyc0uPM55 e2VVB0lC9fh8mhl5FiTYITFMyONQ7MAxwCmzCcGDs/fgCAL16vNxOjUAJ1AP7WJThx4ERQlCECQL rEW8ZhAbg4aMe4XJQvXATiut8uDY4RowU4R0xFyYI9iNW6j26fYjBYSYoxik8t60on1pxfnFFTFh llAj1dZ1tkBUaGBqbinIbv3ePMfPwNb2wqaqGxhskTH7iaQMvgC87xreoXdOcSDwo3YYpKFVoWSt x6MtxlN4akeoWm0tf06DcVh4ROBF96oFe8emYSFB9QkYtmFfLuNHoseiEuvKV9NBOplbbInT3uvv Lqww1ChGsJwkzDm/SO4waJKhQlhOmOm7rOzzwmSdQz0MCCyDhNhZITE0DusbWQP27GJWhOblS8CM HVqXzRwLugkTJrgz4e0plnNRCK0SEdIAYgfUgykqhyh5wgoLzSu6htSc0j+PFg3r5tyoWShIiBEG o4hhrYjKfNtsYmhqZI6uUXxrARRudNaWcrqSBrfW/ncUZv/gLWB4Zc8WlDLYarFnQKsaNF6DHqG1 xMedw07gUnXD5giKQZ1ivt+UIcSF7C7bUiw2OD6/mjcObt/UomXXXWxgaELQ3mCZBfZBxYwOB6zE F0dQOjZ1iANdFT+5rYZaMWWUzJ9Qu5C1vHJ4NNEmyghABsZ59NFHycSHgA/SHS9NghvQclwjC/sT E37ylDTBJJsyC10jwsIiJatEKMt0T7W3SBBgLUUOnDkujujIoV+QE+OpTz6EDDQzZYjFbU2ViIoI 5hHuAC5ty2al2RvRlGn1X9qWwTtgRuu44toyNSgNx4pRK0bP1nhHzOLcDtF9WkVyFgUbjJ/8JcU0 HH+2kUQZggBfNmLjw45gMIEdBnsY60q4Afnn23FUw+XO6FGjQK7jOUHMIYJFSL5atMkZWyx9jIkJ nI4JL0JojHd1zEi1vWPw/sic3RTr07qRkO8s3Z6VVVCeGNXQQ0ewF5YeX73bQpPfNrS5Lkw3FArO IqwAOBS8opBnQVkwRyAApQPC5aIi/CZUMd4SyHqR+4J0QMHIiTGDkmypmDiNIJ0BT0lyWuSb+Ivm cfr06SxWJHeSoeOtwVZzsU/ITBM79X5TLD9IbJzUDY579/6ozO0R7QGfmNxIoIbgK83twpTWPE71 8DlB2RKYBssRWFNYBu24eYqUB60NAiPWBLQPDCr6GuCFiYq2pHEaubIoIGzhSYtEUalF+uOJKzQo QAiRZNeiF7wxQBD4ECF3x74WRR5G/aBUKB3scTD4xqhSlAS/wOawQTFTpIZksnfhX2btRk/0GTCX 5/AOXYNxiF6G+hwCB88YTCXQZiKWRvuDi2/twDvopOGzWGC1GO/wKtn5JN7hlpi8vEoS/nY5Letx dgJ8deylCHpgMaACwC8ECZUCCwgiHpEpmsVTEedJlggYCqKAdY/jIiaI1YqxM/ItdrpcoQ1POrmE VSWKqszPxSNzf6HLCF+APDKz4GTXon1htYQYC8abmfIx40qCNB3rBOTEiAMlQQfqwWoW3ATylZl8 7TrLKVghxPN41Zs7fuvW6Jcxc0EBCfLHpmzIumKNyAG/owxiF4SurBEDdm2Q7OXwDdq6GGSRg7si 7DzWeQgZ2WZYk9jo86st6eW0x1EPSASKhpmLiYFEUM/DUnGLzgvtIDY+uiWOFp8LEQNsCxs+LpSw 5dCQ/NKUTQDlV6kAcPODORcFBA4qr2AX1+uSbLbgQmZwYACoBz2arMt75ZhmgUlxOsUEA+82zPyY NeY2+CIQIEYWRqstPnJt7FsMnXTiduSFMGjGEUtkm6YkWJpcpjTlP40gScQfRfjEQBSwpUkzJd4U lJ3/DNWdkYBhsRplu+ISxu4kYMEQOaN9Z8uHgGXixEWB4kZZhJpPq+Bzp2tn63oW9UDREJkJIYX0 LYazABmBeqAOwEeQQjrfCzkB9Cm46nBBQPI9UxJBNd8wCAh6gUNXsaCTOhc0WVQUoZ5EC9LOGOxj M+iB7MjlhDgVV3QtGoFXQluEZIdbDreDvSLBmFnrSEyQ7GjNT7FhIzYjfptI37G1oSRrBbtk7Xmy zJrYRmgDRfvq1zUIgNCRK2OJJ6oDZ5TrOH/xasjxKCfr2oBdrsUOh+++rM6+i1qZFcVXJibLI/Rf ULg8gghCbQoTKh/Jil5IeBb1IPJgu5Z4h/mASjDGh6JB5gqvIZX0GCVKykg3bagGdIdc5FOFRQPC Bp2hLQLQuH2i90mriE6raBycDE3UWFSX6Ab9aJBnZilQj5ang6kG44gBwEPxgtlSQECgTuTE0LeQ MLBXFCAwEMoIjEoQIcMCIMphIjNmzECNJZkvEBnhewCUwGWiWfXrAgTY85G18clp6wJwCWptfm1K s3WxzLQbnpwdc2fh8RQHb5/4x3jmozw1P6LeQtmeurP8S+gMaEK+SeJRaPMdTPNhc0m8DiaiHZD3 HytW79y9f2FO6kcVxU0Sk6Ibx0XGxB8rDgqNbFx5sEl8XBzhm8LCIxvgL9wQkjM00BK9yV0rZMHc aV1VocIgW5gLVgIoU6B0kF7BVxJ0guBkqLFgGzHd5hamDKkWiAluCzQK5kUSAXUj1fAo/vAvZ1m4 FnrGQXjWhWJQNxDOyA11k4UTEbt9tf5ruoo15RYqG9TD9mwwYLAPKw2xgPe3N28o1w1mbtajT1cc 3bA/PyGqYc/k4Kz0NGLHEat15Zb9xQW5jRoUl2PYXMAJc8WlJUWcbE0YJ37heBs2DAYlBVgQUhA4 KSioofglh/8aNLDQLPh0N7DckBNEwQACzJ18FJhRVJlVdCKuUciY/kmUhIxnD0FHznbKLbQeJku8 WrG+QUZkwn4KrxHYb2x55PQRNyBIpgpkICptTA2gFlFpq2PaJYgcTyBq5V2A99nhYKZ4I2yBOAzK FqCX4dalrR269hrnhSDnYpBgh4OXr5adBC+zySFdNWjKE488S/V4YsQ22xQhFJEwg00Sk5L5I85T YawlxHrvVo2kxl1blwVaVlpMELnS0pLj5WUkyspK+CXMJVn8sGmQxuvb4v1NAUv8s+NV0edIUux4 Rm5RdkFxev3KLw4Hwznjosn+CecMi4TsnFshVybkCFsKOk56ZxcCGUH5o0JCxoygB6oNaTR4hwRe uOh9ocqIREMVn3DgWhDVuDTvFDoRsAtEz+4CiY1aQwSl1E0HaNduhgvdliMTZOlCAOqA44XbWoJ6 BO8jT2gEcJWnIvjXO6ny0gOTDxsmjD+LTNila3dq4cHMEizc7xh+Ur4jmoG2R34M80U0LyQ7RFfh G0DcAOsEHQRKwr4ZS0JWBhsvgir2ZExsUXihgHdpIKqSBQJsELjpQDOyz0sug50fr0M0G7wFn0g0 fPhuQMSOoB7KUNL746wlqKdBlU79FLaxgFGmT2nbzYet6ML6RDZMIjFN0vYHmkOVIHNgrFC4yFuV cB8CIPeZM2fyq7VUoFlE9diFgYwgLcFH6B/d76umtMB8oWgcGS2aHEeKmVvG49bM5g7XXmtCla49 QUmmpaWPvbou54ujkWTMcJfbURXdhwCHZyDfgaLUNQV7iyErUjZ+MSKD/6IAdmTwvDC2xDPiwshe V6t23KJRrZIS/GV3Zj0vcBN0olMRb6wbcS2nlqCe8GCL3rTs1FkClnRVsBUSJx1JXQOPYa3y4xYy VZhNGxZUDz0LAb4fhGigEutuiAArRGbC0AEMRRmUpHBnfHLiQhdpXbEW5IBV4fG1ThXWk0LGDENa rSjauqL7ObWE4RLfP06krEJ41+KiwtVLFy9dvOjQ9tWzywvr1UOsExoe2Qj9On/BoYh4Qk/+hoSF 8Gc5IClcHJPEb3gkB/tUr3oXPusK9bi/Ct1sgaBfkDMGQT9E+3yKyPKttexu9u7P1Tl3BNYegw90 HdbjBO+QKSzmrJ96OqeWoB5CggGpjCP7Zm+as275L6lHDrXo2CeuVe8BI68f0sciuy0pLuQIJP4v LMgDMXEQEgcllZLKz+U0Ev4pLiwgk8OSLOcn5WYTzbh+QECj6NhYzlpq0jShWXLT5FbNWrRu0jRZ iu7woqBlAnR4+iWp9o0hAN4xDmsvqsN2gaSMm6plT+ErCWCIFAzaB+cYHClYvWzPePxwwY6hkIUe 9MmsawPqwbh51uzPP/z4i4ahkYOHXXTHQ8+0bNtRxPSWh4cIZVZcgg3cbw/uiP1zMtMy01Iz0o4c PbR/5aLvU/bv5niA2CbNOCCpffezCiI7hUbGyC7staPyPQ0BPh4YqGp74YX66jOrdmyeKwBSRt+K Kwl+JNidgX+BFX4VhMrFlscRlO2hsdVg1IMLAhZT2ARjAoOkcPwjHwSExnROCm+ZaAnmll1ocSgX MiDXYIeMICYugb+2nXtoW0hPTdn5x8a1K5dtWvsipwcGXHPl+LFjMCPUllFpb0IAcyrQCuotnauE bgxIduqm+QJgwc6DCyhhTQb5I+RfOvh4+bZGoh7sYgipQRAAjsHAPlj4/s9cnPLnkUJOEWh7Whgu neK07KhQ8ycI6cRfYtfzu40qrl+ckVS8gaAEeKURmBIPNd6rl1+h6o6dXIQMl+7E1jCBy4C/wGPA +lHdyQHjYD7mJ/OtSRouVg+BtfAtgEHFHQE+Cws9gXeAZtsEyzefnlfGOX9Hsy0n9mDR0yjUU4IY OqKLXp1agXfwDsVsBN8IXIQxZcZfn0fq8iYEcLvFTRcjZnudonrH5KdWOkzYm7Kf59cY1EOcLVwx CfVElGIc3ggVrCMauyWHY7hMNG+CNIs4zUhhPGTUAzcnYmX0aHHSFhpKHjdRdLdEoWZrxYTEz198 LRse6i0Rjg+GQjc1diwOREabQyAk3ZrRlVS33oRADXAf5dgc3L5x/CeeE3S1AXQ+W5nKIY2yAFSP h1APxoSYiRL4+e4L/1J4yX45DpSz2fDDYtgYuWE04UNhnhxVXUjglkVER8SoSDfgwhBtkIbPgjSG FyanLgChpszRr1EP4W/4eolwTHA/bdAfe8AtLKl44+eD6aeCpdorZko+0VFvHpLULFpvxoYWkyhF MIZEd0cAhAM6WhUQFfstthXEOSMyPIHiTRmDasQaAiAaws5y4SKHIQ87FoHlsGmWJhHWVVSOTyDg v6gHYwS8AQnfRzx9x9dNaXklBydxApdHoUlE+HaJoTpBEqF2QJFIHAhRRIgGghwvXLiQqIwcvAWx BvYhuhBGt3iKIhIiSJgi/j36jlTjfg4Bf0Q9WB9wqBDhI1Bj1YjDA6BuCPQFcoFGA+NoXzke6jhM ixg9Ip9imAJQnsiE2pIqrSBQpyDgd2JmaARC+XE8DjY7NQLvIE2AzCHYEnFhdHiHlUT4GF0mFBxE ENiqTq0zNVkFAR0E/EjwhmaUgHKoqJGS2HQ50Q3dT24Ju41VKAfOWo8HhS42/ggadI+wK0XqqctU twoCdQoC/kL14OHGkVUog4hWWYPwDmsFlQoY0+aiwSCAyKe6RwTuZLIE6NTlq1sFgToFAb+geqAC kH1gjOcrJ1p3Xjlx8KRZo7Yd7Po5fwLEpM0kzemXhCXUZapbBYG6BgHfUz2ffvopVjAcDlMT8Q7L BQ2u9aJBxYuAGTrO2mkIu2eCoiIhsq6lchQE6g4EfIx6OBPm9ddfxxEBBgQyAW06+iCICA4I/v33 32vEa2C0TEEY0aK94ugV3DtQnxOekjMLxRTIZ46ceMOBE5wETRB4sM9NN92EyVKNmKMapIKA6RDw mXIdS1O8n7Bwh+oRR7CjgcYSjM8VWQ8SHw6EsXcooOlQcKdBZMkcqssZoTiv40jBETecU8xcxOlO UDfTp09nIhzZDD5FlM4c8QUhgeMrsVQw0daq3t0ZiaqrIFCTIMCG7P2L8AUc48e2z5cpeucAE6x+ ORzG+4MxpUdsZ1evXs28tK1xUCr+XPgWIVcW+aNGjcIvRJZJTU1F0Q59J3NUQkGgjkDgNO/PkyOo iNv4wAMPaLtm/8ecR5tT09Pvv/8+XCR0kJwIrvY4UshbkcAaCCysy1S3CgK1HgIel/UgcOWAMQJT wmFBDZLg9HGwjPZwGPLRE+FvWZPIRcOxgkk//PBDDgKUhzoCh8mTJ+tmTRuYI4KS8FYzbE89VBCo bRDwoHIdoQayVbwi8NtGhIzLEsgF36WJEyfedtttOkAiGQH76DJr6O2LL74IV4UTqVb5he0PXqPo vHSTwrj56quvRu5jDRNdSXWrIFCbIOAp1IM1HbIPEArxmYTzJ/QOqp+ePXtyJJs1BJHR4jlBqGoh crYuUFNyNm7cCL0D6pF4B8oZJ1LiOWBAIGfBOQH4UmBCiSIMj1PlSiohoxJ1BAIe0XCxh6NjJvS0 9DjHnwANNHs+qIeP8L777tOZLIN0MIE599xzMcPjgyQEKoLne+65p8a9BsKkcsYu4mQxcvRfWC0R uPPdd98VMcmJp4FJAe5pCJgJLw1hSBwZDqXDyhlvr/vvv1+Fea5xL10N2AUImE/1wGchvLCJd/r2 7csQOWgcvyfQiqQLyITYIcQEofMJsEKcJw5pg21xYT4+rwJXhaBHHHSJeAtoTJkyhXkxMEQ/YBa4 zrfeegsUTA4YlgsKiIhiKPsQOaOA53R2Yk7zFMsDeFUi/vh8UmoACgKmQ8B8qofvChqHbVyO9Y03 3iC2qcA7IhNVNKSBzehfGLxgnueTQ6DlgN1MHDhwAMqO+PCQM/CbuI8SnRPjZtAQpF/v3r1F+7t2 7SKsz5dffqmNVU58VSCDsQ/A4bA6PPip6OZ4VHUFAT+EgMmoB8TBZ6MleZgzyh1dhFD06+zzyJv9 ECKmDwkUg48IbBeSZinTQfoOisG20PowTIyb0ADCnW3fvr1Pnz6IzEwfkmpQQcDnEDCZ4UJgwVYv RTxiejq8QyZlxKGrPp+/pweANAdnUVAMYizZF8iIsPYvvPCCNd6hDMeVcHw4TCtpjBKx6m7Tpg1p xNUIpLmFZhSMGN4YNZo8lABRiToIAZNRD2IaYb9jDEq+IrCPcZna8RSJMhyTFu+gAsNzYsaMGdaK dqYs7J4E3hEQQPGHZhCc/tlnnwnpD5gdAPJ03rx5gwcPhpMVAuzaATE1izoCAZNNClEVAziseIzB B18GU2ZcpnY8hXvSOq/PmjVr3LhxOK/bxDtMGfk03hXauYN6sMl86KGHMDtE5AyZg76MXy5ucUZ9 5ZVXHEH32jZVWkHA5xAwWdbDfPhUiH8ucJC96fEt4WNZF8Jlbdq0iUjMcEygCUTI4AjgU23g1w0b NmAYxYWNAjAkBCK2COAam/BEf48kG1mSjs+1WVhlKgj4CQTMRz1s2s8++yzRIaxFPGLOSHk4JR37 F7gzP4GCR4cBicfJXIhpmLj1yYXGXaMsI5AImFrLsumqwHyBfdDHI/rRPVK3CgJ+CwHzUQ9TRYuM 8yQsldZyR4CAnZ/vZOrUqQbHY/stsHwyMKRFWCoYS3MwjAbX45DhkxGqThUEXICAybIeMQLsdAl4 inUP+zxGOmz7HEOOAJXdG9cKNDsK7zj4qrBCAHrGeIemMMhEqORgm6qYgoA/QMBTaibkOITvQ9LB CRMgIPRZGDFjO0ckrTrCZ5nydkHcjqgCASkqMFN6VI0oCHgHAp5CPYwec97+VZd3ZlIre8HGB4PM aqeGE4bWfLza8qqAgoDPIeARhsvns6o1A4CTwpkWdtV4RjjfKhmzMYjUU3+DgEI9/vZG9OMhTr7x UaUo7MFNZ511lr6mulcQ8GMIKNTjxy+namjEOQS5oBa0OVA067iqgnfi4+NtFlCZCgL+CQGPKNf9 c6o1d1SIcnB5R9uFoaZWSE8UegLOE39DHaNcc19unR1G/JBrAAAUlUlEQVS5Qj0149UjbOaAII5p xVBT+HBBCqH8GjJkCN7tNWMOapQKAhoIKNSjAYbfJ3GOwzwKSx+wDxJo9F/KecLvX5oaoG0IKNRj Gy4qV0FAQcCjEFBiZo+CVzWuIKAgYBsCCvXYhovKVRBQEPAoBBTq8Sh4VeMKAgoCtiGgUI9tuKhc BQEFAY9CQKEej4JXNa4goCBgGwKuuI9u3rSJ8Bc22yMmRo+ePdH+zvniiw4dO3IGjs1i3snEzDfl cMqAcwY42J3FI6HYrrdUw+CGWnM+B9v0w2KZGRlAprdJ1kBEhlu3Zm2btm07dOzgq8kWFRYtW7Z0 6LBh8sAPORITJ0sAhmOpx9p3aC8br1kJE0FhzsSxxHf22r1r1z8mTGjWJIG/MZdf/v38+SCaxx5+ pG3LVlddcSWtccujjm3bYQjnbOPulweDLF606NprrmEMD9x3v+MNbt2yhSpDBg6adP0Nl182ivSl F108+cZJFw2/gDRtOt6UP5d8+qmneFOYCLk/SF79U08++cP33yc3bbZh/Qb3G3ShhfXr1g89fzAv CB9a6+pmTfarL79s07KlU8vJejC+zTELFGbNwnLEigvXksWLedn8TX/7bVn9l59/FqiHGD3dO3e5 ceL18pE3E+/PfO/1V18Tw3Nqraxds+bfU+4RQ/35p59p4YvPPxe3z0yb9uOCBY7PAizGJul4eW+W xBmVEy9M6bFrp84HDxykqY0bNhQVFprSpguNfDb7U16WRD1a4Ls5WW1T7EBOLScXJmJ6Fe343QSF 6WNzUdaji7tMnKr169YNHjLk9JYtIcY6duy4ceuWGe/NNIcwc7KV666feNs/b49p3NjJeqcxqfHX TrBZa+w11xB+yOYj60yQDrRStZEurCt6JwdHMFMC8sNqZWVmNgi08Oxw2SEOw8f0aYoxiGZ1wHdn srqmdGve9FmY3qBu/O6AwvSx0aArsh7rcfzvm2+Olx8/o3fvx554nBU57cmp+Dryqqa/O4PCbIzf z5+3fdv2I0dSkpo352yGwMCghIQmixYu4ilfO/EMX33l1bzcXNwCZn7wfkZ6xlNTp3JLC1OfnkZr REd/6b//ad2mzYrfVkx/600Og0GoNOXf9wJN68GInKDAQOtHzz39DIfqTXvmGZsce/cePayriBxC LHIR2v2ruV8i57r8yivk10vm8qVLCSfIrjvisstCgoOvHnMVA37ztdc7dup09TjL6em6a+GvvyI1 oJ1WrVtdeNFF4unqVau2bt2ak53Tu0/vgYMGiUx4mdUrV9HOiJEjxLeNmOb7efNHjBy5e/euHxf8 iO/oVWNPhmRmW1u5YkXq0dS9e/dMumly8+TmNAKHz9nKl1x6KQzjgf37H3jooUMHD3391Zc33Xwz Bw1SgDi2n3/6WXp6Gp4ZjJ8Yz6Jr3bw49ELki9/v/vftwoW/kn7rjTfCwsIn3TRJ4HpmwV9OTm7X bl1HXnYZwhd2y5UrVh48cOCsfn3fnznzslGje53RS9sUA2BGzDo7J+eH+fM7de586YgRwJPMnTt3 jr58dNdu3dLS0hgkZx/ec++9lScqP/v00yMpR4YOG9qvf39tU9lZWTrgayeLty3Uem5ODojyy7lz MzMyJ/zj2m7du9OCNeismxId7d2z55uvv87Py594ww3JLZK1vcu0zVdpE87sT0uXLOGYowsvvIhJ HTuWyouTzfIRzZwxA1Cw7THm5BYt+HaICefaOtSCQgzV+mUZj0dO0JyEa3TUit9+ExzNSy+8sGb1 6gF9+8HmyKbemT6dp6cnNScn5fDhTu3aIwsA9Fs2bya/d89e//v6G2QN7Vq15vaD9ywV4aVFg6IR OB1uqTXx2n+cfVZf0q+98uqvv/ySlJD4wnPPI80ZNWIkfwaypDO696CWlkLmUxddPPn4E3Ko9hI6 hotiO/78895/TYG+41G3zp0ff/QxURceE78q0s9Oe3rdunUM6YvPPqOjPXv2UFiU0f6y1GDfyGHB 3X7LreIREPvPiy+SPnzoEHP87ttvST/x2ON8Khnp6Xfe/s/O7TuAwfn27rvnXhr/1113Abdnn36G NGARjVx95ZhZH31EevbHnww851wSAF/IvB596GFAASS3btkq5HS8DkuBlJTzBpzDsEnP++47ZEA/ LfiRNJduXiJT/qJJoF8xTdYrb4RHr7z88m033wLnxcQvu3TElaNHC4UDUhKkZkiFLr7gAi2HThVA 9/gjj9LOHbfdzhJ68fkXeOlT7r4b8H791VcjLr6EidM+JT+eNYtiQIM0mKJ5YlOwHmmuuXPm8AjU rwP+zh07tJNlgixF1iojYRisw1bJLdgRacEadLqmKDPykksvHDac0X7z1dcIBElb+ra6bL5Ke3Bm P+jdo+egc8+dNnUqsxh83kBAJJvkFSA25ZaFxwQR1jBa19ahDhS0afNlGY9HDsyUhIuyHol6rhg1 6trx44GLFvV8+slscgTq4TMg3a/PmQyXxUGaP4RB3Pbs2o20QD1iHXMrZrXghx9ESRAzq5My6Wnp 5593HplC5oJQhjRYzx4UrFEPJR964IFhg4fAANurJfOtUQ/rgM8S1MDf5EmT6J0PjLHxDSAkoiKo RKxjljhPITdka9oECAWI8U2SCWbhF7F969NbglZEMdaEhdhZtQoRvugO1ECDVKQAK4+0RBAsXIHI CKwx5vIrQO6UWbd2LWX4PklDB5EWuEy0L7C8QD1MRKI/noKnwKrgDpvzEtXl77KlS2n50EGLrIeL dwoo9u7dK243bdzI07fffJNbcBBfl8i3/oVroySIRjy66YYbERuL9K6dO3m0Z/dubsWSEKiHW9CZ NeohXwd87WR5OnrkZeOuupoEF7QDjd91xx32QKdrCtQDHy3qsqrZIaBHxK38tfkqeWoPzpZHN04a PmSoaEE0K4RWf263vGj2Sx6tWrmStNghXF6HWlAYvCx74xEjNPHXRVmPpLiGDh/+4axZiFdkji7R qXMncti4+GVNi6eC1NeVtHkLr8GhXf+YODE8Inznjp2U+WTWLPb8bdv+iI2N/XP7dpu17GU+9fTT P/7yc5euXe0VsJdfXFS0fNmyffv3Laq6BpxzzrMvPM+SZWxDhg69cvTlbKRQxVoFsz2fcnifpYuX XDz8gt+W/3bueefR408//tS5c2d5wt8dd955wYUX/vzTT7xm0d32bdvobtD5Fi5MKPgDg06yk41j Y/PyLAHhyf987pzWrdvM+fzz7+d/Tw6rlt+IKp60VevWpMVVv97Jl25p/9eFLVud5LB4euZZfWFD tm3fbjCvU83o/126eDFZyckneZDOXboAkKVLlpIZERHZqtVfA9DVbFDFGstTN+Li44IbNhRlmB2J o0f/dhyrrrrNWwl8OVlRLCCgPlMT6YSEBJg7sJs90IlisiluQ0JDRGaThCZAD2GKuJW/Nl+lAZyp WD+gvhQOsKQpXFhQQD54jV8wOL+8VoQPSUlJ7qxDLSgMXpa98TAMcy9zZD2jq/ZbmyNDgDL+2mvB F9CTacfSKHPFmDFSoGCzijZTvnixFfBo1OUovkdpy3ghnZaeTi/9+vVD7qDrDnnWC8899/abb7Hs Pvx41l9Tq1dPV1LcIun4dv6822+97aorrphy7z13T5mSknIYKQw8i9YsBViFhoWNn2Bb7G2zZehB dD3PvfhCm7btpr/1ls0y2kwoL9Y357jLTCGFQRpCjt15ydJ/TyClYgqQfkIqRCyh7j265+bqP86/ V7JxFxR0Eu/IZydOVMq0owk7wNdVR9YGzUWmEegca0q0bPNVGsNZNyR5C/TOGzgQXW37Dh3gg26Y dCMH2yFDpID769CslyVH60LCXapHdMmSHXPVVfa6v/2ft589YMCRlBQ2tB9++vHlV18RJSVasVdR m49cWZzetWH9epnPWpdpRxIQGrAAcBOOFNaW4XPiW4ICl5nwR3A3CCOPHjn64MMP//DzT0gx//vi S7KAvQT7GPjrl0ULb7nt1pdeeBGxMZRCRkYGXJKsgo0MMsWVv60QH4bIhzuTBawTHHAKqXzv/fc5 HimVAxrRSCLGlq3B1ZLmGDUX5tW+yqQQPlG2lpaWzmcjb01JIFIypR3RyNrVa3r26uUC6OyNwear NICzvXbIZx96YuqTnB+FUmLQ+ec//OijZJq1Dr3zsgxmZ5mg8WN7TyHLxSP5bYSG/aV7Li8v4ymk IxffOawsVC6MRt++/ZqfIsgpIAxqd+/eDQbBQlo0KPACQj7trUiPvWYciU9mfYyklm/jnbff3lhF joqn2l8aQSdCzlHNlk4msoynnpw6Y/o72sI20yXFxeTL2UHuXjlmDBURY6F3WL9+/Sv/+S88RV5+ /qezZ1MSjmni9ROjoqNIR0VF84tOB/TEjkdae0GYICSiQRAWijoUFiNHjSLo15S77gYzQv8/98yz ZWWldAcuQ0aASoVhvPfuzPLy47RTWtWgxLmQLRXHLfkIRGAAt27ewiMMrMjhETnlVeUh1OUYCoss bC+z4PeOu+4E99GpeLpu3dpRo0c3S0qyOS/ZgkggSyKRX8UdkLjo4otRQUI+iKfMHQjcfMst3PI2 BfsgHul+xQgrK07uIswdCleUEcsAjQS3Xbp0Ya/65SfL1JAM8pueniGKlZVagCwK64CvnawoLBYG aeQdCLzQKNkDna4pxAWYTYtGxHS0UBX5Nl8lj+zBmUcMHp2dttnjVfOFm4M0RgeHohBGTBRwZx1q QWHwsuyNRwzAzF+BIJz6hXUa0K8/ci/+OnfoiHBeyhppB+mdsC7lKdL+ZUuXiZLyF80C3wYl+dKw eCaf1h5+8MEWzZIQJKOLQZSISE+Uv/4f16EdEMPjfSMUFPkd2rRFgGpz2GCHG66bKIohjERpwqdF Sb5DMWwp0bRZnUzUCugvaAHtz4fvvy+K8aWNHXOVaPaCocOEPJUNk+m8+fobfHKMHKkwhSmJ9BfV jE6bI9q5/9/3jR87DqEpLcMWiUxAceYZvWkcgAilBvkosFE5kdmyeTIKPnLAWWh/yIHAwYiBiZDu 26cPlBQ4DqAJnSDkGFJ2BOqLFi4UEnEE2yB3WsD2Vxhqo6kRgnCEtYAdnSMyzjv/eQcImmI250W+ vGgHqTa9I3f7/fffRT5YDLs77NrZqGnq5x8t4iqmw6TQJX30wQcgU9mCSNDd1CeeoB1e2YH9BxBd 9z/zLGaBPgswoufiEcblYoGh6EGSDfCxoh466PxbJk9Grg+FiPqMYiiAwNFa4FtPFoH3uWcPYITI 8tGQCgtsm6BDJaRtCjk9b6FHl65sewyGN0iPvEohB9BOyuarpIBNOKOuwSyTloEV6xwRMs2igUU2 yvtlFXEr/uj6jddepx1G5cI6tAaFzZdlMB7tHE1JezxKIZvwrTffvGzJUmGSx1Jjv4UuXbFmNRiU t87eyG7J/gOF6cg5dnwwbHdt2raBA3IWB7Mxcui7zkTFqUboHbpDtsDs2IqZETuz9jRnOiJTSo61 XVCSKuy9sO46lhNBCYYbWokP6PLgwYN056Bgnn1YmP8wAOCja187DG2a7wfVDL0IsS6P7M1LW8te GvwLKcS5YC68IHttynw+PAFnVo6UTMunImEAfJSGMTGNX3n9NWTwiYmJ2oo2QWfQlLauddr6VVLG Gs7WFWUOAoq5c+dC/B5LTcVoLDs7a/qbb7334YexcRYKyP11KDry6MuSc7GdMAWBGTTC3s7WLVS5 FGNNY42iNV4wqKseKQiYCwGoHghGc9v0RGt8JlBngjmQ7WO0JUycZE6NTjhNONhGYPZzY+Pi2KA+ +uBDRGUQPgcO7If9efDhR+zXUE8UBDwFAY4zKykp9VTr5rULudqmTRvM0DAowSoda9JDhw5h5I3E 2rxOfNySxxku5of6FkEDBv7h4WEobjCrcYSx8jFgVPe1DgKzP/kEdV69+vV79uxx1dixDvKwvgID 3BmSFwSacIjnnHsOOg0tJ+6rUZnYrzdQj4nDVU0pCCgI1A4IuKhcrx2TV7NQEFAQ8BUEFOrxFeRV vwoCdRoCNRX1YHYhrRDr9AtUk1cQqJkQqHmoBz39qy+/PHjgoPnz5tVMmKtRKwgoCLjqSGEi5LD+ dKo1fA7uuOuuxL9HrnKqBVVYQUBBwOcQ8DHVg2vSt9984wIUAp03ZXahF1VFQUBBwEMQcN2kEB9l 64CecEPW0TYxwbQZBfKTjz9+7JFHiJmCw+S4a65Jap5kHUnTZoMegoVqVkFAQcBrEHCR6pnxzjvY O904adLYcWMnjLtGRJPAdPCSCy/q0avn/Q8+yMFMwwcPwSmOmYCkHrr/AeLyvjP97cSmicSCuPXm yeTjkov3FkF8b7p5MvmEy/3HhPHYfc3++GMiY+BFba9Br0FHdaQgoCDgKQi44AZiYhRIfKYfvP9+ OQZdJE2DsJL4N+MxLyuqhIKAgkDNgoArVI+JUSBBqFrvam0kTeBoL3ynp9CwaldBQEHAWxBwBfXI KJDaQeIjSjwde9E2tSV1aS3q0T5yuUFtIyqtIKAg4J8QcAX1mBgF0gAoroWVNGhQPVIQUBDwHwi4 gnpMjAJJDEpCYQEOEbaSyEzaSJpGYSXLysrLTgZR9R9oqpEoCCgIOAiBgMcff9zBorIYRn29zuhN kMr33n336y+/4ijOYcOH85T4xETkef7ZZ6Ojogk9SQjRac88DfGC4z+hQlMOp3Tu3CU4JIRTA0E3 8Fl9+/XlJKsP3nufwv3P7k9UTeIuE3M/JiaaM3A4osRmg5UVFfQ7f958gte2bddOHtUoh6cSCgIK Av4PAbeCZrgfBRIAEeoxOibGIBaJU2El/R/iaoQKAgoCQMAt1KMgqCCgIKAg4BoEXJH1uNaTqqUg oCCgICAhoFCPBIVKKAgoCHgPAgr1eA/WqicFAQUBCQGFeiQoVEJBQEHAexBQqMd7sFY9KQgoCEgI KNQjQaESCgIKAt6DgEI93oO16klBQEFAQkChHgkKlVAQUBDwHgQU6vEerFVPCgIKAhICCvVIUKiE goCCgPcg8H/jWUhkyh9FDgAAAABJRU5ErkJggg== --Apple-Mail-11--213411055-- --Apple-Mail-10--213411055 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > Costin Raiciu wrote: >> Hi Joe, >> >> The proposed congestion controller gives the aggregate multipath >> connection the throughput a TCP would get on the best (fastest) of >> the >> paths available (to the multipath connection). It does so only by >> looking at loss rates and rtts on the different paths. It does not >> need >> to know whether there is a shared bottleneck or not. > > If it doesn't, then you will create the potential for a single > multipath > group to fight with itself, which seems less than productive. > > Joe > --Apple-Mail-10--213411055-- From c.raiciu@cs.ucl.ac.uk Tue Nov 3 09:14:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED62E3A6960 for ; Tue, 3 Nov 2009 09:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuQMNUicxRK0 for ; Tue, 3 Nov 2009 09:14:35 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 126EA3A691D for ; Tue, 3 Nov 2009 09:14:34 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N5MvK-000Bx1-2i for multipathtcp@ietf.org; Tue, 03 Nov 2009 17:12:02 +0000 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> <4AF05758.4080309@isi.edu> <6E3D84BC-F010-4035-A053-76D99901294F@cs.ucl.ac.uk> <4AF05A0F.6040705@isi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B6DB3BE-8B66-4637-8591-6FDA10920A2E@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Tue, 3 Nov 2009 17:14:30 +0000 To: "multipathtcp@ietf.org Mailing List" X-Mailer: Apple Mail (2.753.1) Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:14:36 -0000 Just adding a few explanations to my previous email (which is a bit compressed). > I don't understand what you mean by subflows fighting each other. > > look at the examples in the picture attached . > > Say for simplicity that the RTT of the multipath subflows is the > same in both cases, and say link 1, link 2 and link 3 have the same > loss rate p (i.e. disregard flows B,C and E). > > The controller will give the **same** throughput to the multipath > connection in the two cases, i.e. what a TCP would get if it saw > loss rate p. > > In this case, there is no throughput benefit for using multipath; I mean, in the case when multipath cannot affect the loss rates at all. > multipath increases throughput when it can affect the loss rates. > In the same picture, if the flows B,C and E have the same > throughput as the multipath subflows, the connection will get: > 1. (link1 + link2)/3 in the first case This assumes link1 and link2 have the same capacity. > 2. link3 / 2 in the second case. > > Hope this makes things clearer. > > Cheers, > Costin > > > >> Costin Raiciu wrote: >>> Hi Joe, >>> >>> The proposed congestion controller gives the aggregate multipath >>> connection the throughput a TCP would get on the best (fastest) >>> of the >>> paths available (to the multipath connection). It does so only by >>> looking at loss rates and rtts on the different paths. It does >>> not need >>> to know whether there is a shared bottleneck or not. >> >> If it doesn't, then you will create the potential for a single >> multipath >> group to fight with itself, which seems less than productive. >> >> Joe >> > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From alan.ford@roke.co.uk Tue Nov 3 10:35:33 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DF128C182 for ; Tue, 3 Nov 2009 10:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW6j1KQ6G4Kc for ; Tue, 3 Nov 2009 10:35:22 -0800 (PST) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id DCB4028C137 for ; Tue, 3 Nov 2009 10:35:20 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nA3JZWag001104; Tue, 3 Nov 2009 19:35:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5CB4.721D1B1D" Date: Tue, 3 Nov 2009 18:35:40 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808C85177@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] High-level design decisions /architecture Thread-Index: Acpb5JtVyCJMgKRdQLqhkxWfqx2wUQAybiqw References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> From: "Ford, Alan" To: , X-roke-co-uk-MailScanner-ID: nA3JZWag001104 X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:35:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5CB4.721D1B1D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil, all, =20 Some comments inline. =20 Thing is, there are quite a large scope of topics ranging from "architecture" to "high-level design decisions". It is quite feasible to have fixed architectural components while high-level design can be flexible. This not necessarily the same as "detailed design"! =20 From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 02 November 2009 17:48 To: multipathtcp@ietf.org Subject: [multipathtcp] High-level design decisions /architecture =20 Hi =20 In order to help the process of reaching consensus on the high-level design decisions /architecture, we have gone through the current set of I-Ds to identify items that seem like they may fall into the category of high-level design decisions - see below. Note: this list is not to meant to imply our support or non-support of these items (except where our charter requires our support!); the purpose is to identify what needs to be discussed. =20 Please shout if there's something we misunderstood or missed. =20 Please let the WG know your opinions on these items - especially if your disagree with any, have a potential alternative, or think something is part of 'detailed design' and not 'high-level design'. =20 Thanks Phil & Yoshifumi =20 =20 Protocol-related =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * IPv4 & IPv6 will have the same high-level design=20 * [Comment: the Charter implies both v4 & v6 are in scope] =20 [Alan: Agreed] =20 * The MPTCP connection is identified, from an apps perspective, by the addresses associated with the original path (even if that subflow /path closes)=20 =20 [Alan: This is still a contentious issue. If the new MPTCP API is in use, this issue - as a concept - does not really exist. There is a connection identifier, there are sets of addresses, etc. This is talking about the legacy case, and what happens if an application later queries a socket (getsockname and getpeername). I can see Bill's and Joe's arguments here of where problems could occur. I think, however, that the problems that may occur with returning the original addresses are less than any other way.] =20 * A SYN/ACK exchange (on a single path) checks that both ends support MPTCP, with automatic fall-back to TCP if not=20 * each MPTCP subflow looks exactly like an ordinary, semantically independent TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are independent on each subflow=20 =20 [Alan: Yes, I think this is an important high-level decision] =20 * control of the MPTCP connection (as opposed to the subflows) is carried in TCP options, eg DATA FIN for closing an MPTCP connection=20 * the protocol involves an MPTCP stack at both ends of the MPTCP connection=20 * [Comment: this is in our charter]=20 * Either end of the MPTCP connection can add or remove paths to/from the MPTCP connection=20 * [Comment / Question: this seemed a bit unclear in the protocol i-d, but is presumably required?]=20 =20 [Alan: Yes, absolutely. Adding paths and signalling new addresses are also potentially separate to permit flexibility with middleboxes/firewalls/etc.] =20 * Subflow end point definition * [Question: Should we allow subflows in a single MPTCP connection to have different ports?]=20 =20 [Alan: Yes. By default I would expect implementations to go for the same ports so as to maximise the chances of getting through firewall/middleboxes, but there is no technical reason why it could not be used between any ports. The draft specifies the mapping that an endpoint must have.] =20 =20 Congestion algorithm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * the goals are: [1] MPTCP is at least as good as TCP would be on the best subflow path; [2] on any path, an MPTCP connection uses less (or the same) capacity as a TCP connection would do; [3] MPTCP moves traffic off more congested paths and onto less congested ones=20 * increases in the congestion windows of the subflows are coupled; for decreases in the congestion windows, each subflow does new reno independently (ie they are not coupled)=20 * slow start, fast re-transmit and fast recovery are the same as RFC5681=20 =20 =20 API =3D=3D=3D * no changes to existing apps are needed to use MPTCP; MPTCP uses the unaltered TCP socket API=20 * There is an optional, extended API=20 * [Question: would both ends need the extended API, with a fall-back if not?]=20 =20 [Alan: No, the extended API is about signalling preferences to, and getting information from, the local implementation. If it did involve anything happening on the wire, this would simply be triggering the operation of existing features.] =20 * [Comment: presumably the actual features of the extended API are outside the initial high-level design decisions]=20 =20 [Alan: Yes, although the use cases that drive the API decisions may also help at a high level.] =20 * congestion control state is shared among application-visible transport instances (eg multiple HTTPs between the same pair of hosts)=20 =20 [Alan: Huh?] =20 * 3 application profiles are mentioned (Bulk data transport, Latency-sensitive transport with overflow, Latency-sensitive transport with hot stand by)=20 * [Question: how are these supported? Is a negotiation mechanism needed?] =20 =20 [Alan: TBD ;-) The sender can control much of this; expressing policy to/from the receiver is one of the key open issues.] =20 =20 =20 Security =3D=3D=3D=3D=3D=3D * exchange a token in the initial SYN for the MPTCP connection, and include the token when subflows /paths are added to the connection=20 * [Question: Is the same token used whether the sender or receiver (of the MPTCP connection) adds the subflow? Is the same technique used for removing subflows? And closing connections, ie DATA FIN?]=20 =20 [Alan: in the current design (very much open to input of course), the sender and the receiver both have independent, locally unique tokens. Aside from the initial handshake, where the local token is used, all future token uses (currently limited to opening new subflows) are the remote token. Removing subflows is just a FIN on the subflow, or signalled via options if the address is lost. Closing connections also does not use tokens. =20 We are clear that this is a very minimal handshake mechanism, simply seeking to be no worse than regular TCP. More secure mechanisms are FFS.] =20 * security mechanisms will not interfere with end-to-end authentication etc and will be compatible with legacy middleboxes=20 =20 =20 Modularity =3D=3D=3D=3D=3D=3D=3D=3D * the architecture has 2 components, multipath scheduler & path manager - meaning that improved /different modules of each can be slotted in=20 =20 [Alan: This seems to be causing some concern with people as to whether this belongs in an "architecture" document. Personally, I see it as part of the "framework" through which the relevant components of any Multipath TCP could be implemented. It is a way of thinking about the functional separation required to allow modularity.] =20 o [Comment: it is unclear from the Architecture i-d how the congestion control & protocol i-ds map to these components; some of the text (strangely?) appears in a section about implementation] =20 [Alan: Will be ironed out in due course - although the congestion control clearly lives in the scheduler, there are also some protocol components there.] =20 o [Question: what are the mechanisms for evolvability? How is it negotiated which new module (for congestion control or path manager) to use?] =20 [Alan: I would have thought that kind of decision is entirely out of scope for a high-level framework, and even for detailed API decisions. This is intended entirely as implementation guidance and was not written with the intent for people to plug-and-play different modules.] =20 o [Question: this would seem to imply we need to define an interface between the modules?] * there is a default path manager module, meaning it is the MUST fall-back option =20 o [Comment: the charter restricts us - the path manager we work on will distinguish paths by multiple addresses] =20 [Alan: Sure, but that doesn't prevent us designing an evolvable framework so that different path managers could be used with much of the rest of the protocol having minimal changes.] =20 ------_=_NextPart_001_01CA5CB4.721D1B1D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Phil, all,

 

Some comments inline.

 

Thing is, there are quite a large scope of topics ranging = from “architecture” to “high-level design decisions”. It is quite feasible to = have fixed architectural components while high-level design can be flexible. This = not necessarily the same as “detailed = design”!

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: 02 November 2009 17:48
To: multipathtcp@ietf.org
Subject: [multipathtcp] High-level design decisions = /architecture

 

Hi

 =

In order to help the process of reaching consensus on the high-level design decisions /architecture, we have gone through the current set of I-Ds to identify items that seem like they may fall into the category of = high-level design decisions – see below. Note: this list is not to meant to = imply our support or non-support of these items (except where our charter = requires our support!); the purpose is to identify what needs to be = discussed.

 =

Please shout if there’s something we misunderstood or = missed.

 =

Please let the WG know your opinions on these items – especially if your disagree with any, have a potential alternative, or think something is = part of ‘detailed design’ and not ‘high-level = design’.

 =

Thanks=

Phil & Yoshifumi

 =

 =

Protocol-rela= ted

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

  • IPv4 & IPv6 will have = the same high-level design
    • [Comment: the Charter = implies both v4 & v6 are in scope]

 

[Alan: Agreed]

 

  • The MPTCP connection is identified, from an apps perspective, by the addresses associated = with the original path (even if that subflow /path closes) =

 

[Alan: This is still a contentious issue. If the new MPTCP = API is in use, this issue – as a concept – does not really exist. = There is a connection identifier, there are sets of addresses, etc. This is = talking about the legacy case, and what happens if an application later queries = a socket (getsockname and getpeername). I can see Bill’s and = Joe’s arguments here of where problems could occur. I think, however, that the problems that may occur with returning the original addresses are less = than any other way.]

 

  • A SYN/ACK exchange (on a = single path) checks that both ends support MPTCP, with automatic fall-back = to TCP if not
  • each MPTCP subflow looks = exactly like an ordinary, semantically independent TCP flow. MPTCP = effectively runs on top. So re-transmission, FINs etc are independent on each = subflow

 

[Alan: Yes, I think this is an important high-level = decision]

 

  • control of the MPTCP = connection (as opposed to the subflows) is carried in TCP options, eg DATA FIN = for closing an MPTCP connection
  • the protocol involves an = MPTCP stack at both ends of the MPTCP connection
    • [Comment: this is in our charter]
  • Either end of the MPTCP connection can add or remove paths to/from the MPTCP connection =
    • [Comment / Question: this = seemed a bit unclear in the protocol i-d, but is presumably = required?]

 

[Alan: Yes, absolutely. Adding paths and signalling new = addresses are also potentially separate to permit flexibility with middleboxes/firewalls/etc.]

 

  • Subflow end point = definition
    • [Question: Should we = allow subflows in a single MPTCP connection to have different = ports?]

 

[Alan: Yes. By default I would expect implementations to go = for the same ports so as to maximise the chances of getting through = firewall/middleboxes, but there is no technical reason why it could not be used between any = ports. The draft specifies the mapping that an endpoint must = have.]

 

 =

Congestion algorithm

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  • the goals are: [1] MPTCP = is at least as good as TCP would be on the best subflow path; [2] on any = path, an MPTCP connection uses less (or the same) capacity as a TCP = connection would do; [3] MPTCP moves traffic off more congested paths and onto = less congested ones
  • increases in the = congestion windows of the subflows are coupled; for decreases in the = congestion windows, each subflow does new reno independently (ie they are not coupled)
  • slow start, fast = re-transmit and fast recovery are the same as RFC5681

 =

 =

API

=3D=3D=3D

  • no changes to existing = apps are needed to use MPTCP; MPTCP uses the unaltered TCP socket API =
  • There is an optional, = extended API
    • [Question: would both = ends need the extended API, with a fall-back if not?] =

 

[Alan: No, the extended API is about signalling preferences = to, and getting information from, the local implementation. If it did involve = anything happening on the wire, this would simply be triggering the operation of existing features.]

 

    • [Comment: presumably the = actual features of the extended API are outside the initial high-level = design decisions]

 

[Alan: Yes, although the use cases that drive the API = decisions may also help at a high level.]

 

  • congestion control state = is shared among application-visible transport instances (eg multiple = HTTPs between the same pair of hosts)

 

[Alan: Huh?]

 

  • 3 application profiles are mentioned (Bulk data transport, Latency-sensitive transport with = overflow, Latency-sensitive transport with hot stand by) =
    • [Question: how are these supported? Is a negotiation mechanism = needed?]         &nbs= p; 

 

[Alan: TBD ;-)  The sender can control much of this; = expressing policy to/from the receiver is one of the key open = issues.]

 

 =

 =

Security

=3D=3D=3D=3D=3D= =3D

  • exchange a token in the = initial SYN for the MPTCP connection, and include the token when subflows = /paths are added to the connection
    • [Question: Is the same = token used whether the sender or receiver (of the MPTCP connection) adds = the subflow? Is the same technique used for removing subflows? And = closing connections, ie DATA FIN?]

 

[Alan: in the current design (very much open to input = of course), the sender and the receiver both have independent, locally = unique tokens. Aside from the initial handshake, where the local token = is used, all future token uses (currently limited to opening new subflows) are = the remote token. Removing subflows is just a FIN on the subflow, or signalled via = options if the address is lost. Closing connections also does not use = tokens.

 

We are clear that this is a very minimal handshake = mechanism, simply seeking to be no worse than regular TCP. More secure mechanisms = are FFS.]

 

  • security mechanisms will = not interfere with end-to-end authentication etc and will be compatible = with legacy middleboxes

 =

 =

Modularity

=3D=3D=3D=3D=3D= =3D=3D=3D

·        = ; the = architecture has 2 components, multipath scheduler & path manager – meaning = that improved /different modules of each can be slotted in =

 

[Alan: This seems to be causing some concern with people as = to whether this belongs in an “architecture” document. = Personally, I see it as part of the “framework” through which the relevant components of any Multipath TCP could be implemented. It is a way = of thinking about the functional separation required to allow = modularity.]

 

o        = [Comment: it = is unclear from the Architecture i-d how the congestion control & = protocol i-ds map to these components; some of the text (strangely?) appears in a section about implementation]

 

[Alan: Will be ironed out in due course – although the congestion control clearly lives in the scheduler, there are also some = protocol components there.]

 

o        = [Question: = what are the mechanisms for evolvability? How is it negotiated which new module = (for congestion control or path manager) to use?]

 

[Alan: I would have thought that kind of decision is = entirely out of scope for a high-level framework, and even for detailed API = decisions. This is intended entirely as implementation guidance and was not written with = the intent for people to plug-and-play different modules.]

 

o        = [Question: = this would seem to imply we need to define an interface between the = modules?]

·        = ; there is a = default path manager module, meaning it is the MUST fall-back option             &= nbsp;           &n= bsp;           &nb= sp;          

o        = [Comment: = the charter restricts us - the path manager we work on will distinguish paths by = multiple addresses]

 

[Alan: Sure, but that doesn’t prevent us designing an evolvable framework so that different path managers could be used with = much of the rest of the protocol having minimal changes.]

 

------_=_NextPart_001_01CA5CB4.721D1B1D-- From alan.ford@roke.co.uk Tue Nov 3 10:37:37 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D85F3A6A4A for ; Tue, 3 Nov 2009 10:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-APMNlTyCqk for ; Tue, 3 Nov 2009 10:37:36 -0800 (PST) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id 93E4E3A6A48 for ; Tue, 3 Nov 2009 10:37:35 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nA3Jbl7l031542; Tue, 3 Nov 2009 19:37:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 3 Nov 2009 18:37:56 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808C85179@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <4AEF781E.4070009@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] High-level design decisions /architecture Thread-Index: AcpcHAjjtWotvElJTYmfoF5NK2atlAAl06BQ References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> From: "Ford, Alan" To: "Joe Touch" , X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:37:37 -0000 SGkgSm9lLCBhbGwsDQoNCj4gPiAgICAgKiBjb250cm9sIG9mIHRoZSBNUFRDUCBjb25uZWN0aW9u IChhcyBvcHBvc2VkIHRvIHRoZSBzdWJmbG93cykgaXMNCj4gPiAgICAgICBjYXJyaWVkIGluIFRD UCBvcHRpb25zLCBlZyBEQVRBIEZJTiBmb3IgY2xvc2luZyBhbiBNUFRDUCBjb25uZWN0aW9uDQo+ IA0KPiBJIGRpc2FncmVlLiBUaGUgb3B0aW9uIHN0cmVhbSBpcyBuZWl0aGVyIHJlbGlhYmxlIG9y IG9yZGVyZWQsIGFuZCBzbw0KPiBpdCdzIGEgYmFkIGlkZWEgdG8gcHV0IHN0YXRlIG1hbmFnZW1l bnQgdGhlcmUuIElmIHlvdSB3YW50IGEgY29udHJvbA0KPiBjaGFubmVsLCBvcGVuIGEgc2VwYXJh dGUgY29ubmVjdGlvbiBJTU8uDQoNClRoZSBjdXJyZW50IHByb3Bvc2FsIGNvbnRhaW5zIHF1aXRl IGEgbG90IHRvIG1lZXQgdGhlIGxpbWl0YXRpb25zIG9mIG9wdGlvbnMuIFNwZWNpZmljYWxseTog RGF0YSBTZXF1ZW5jZSBNYXBwaW5nIGlzIGRvbmUgc28gdGhhdCBhIGRhdGEtbGV2ZWwgc2VxdWVu Y2UgbnVtYmVyIGRvZXMgbm90IGhhdmUgdG8gYXBwZWFyIGV4YWN0bHkgYXQgdGhlIGNvcnJlY3Qg cG9pbnQ7IGFkZHJlc3MgbWFuYWdlbWVudCBoYXMgbm8gcmVxdWlyZW1lbnQgdG8gYmUgcmVsaWFi bGUgb3IgaW4tb3JkZXI7IGFuZCBEQVRBIEZJTiBpcyBhcHBsaWVkIHRvIGEgRklOIG9ubHkuDQoN Cj4gPiAgICAgKiBFaXRoZXIgZW5kIG9mIHRoZSBNUFRDUCBjb25uZWN0aW9uIGNhbiBhZGQgb3Ig cmVtb3ZlIHBhdGhzIHRvL2Zyb20NCj4gPiAgICAgICB0aGUgTVBUQ1AgY29ubmVjdGlvbg0KPiA+ ICAgICAgICAgICBvIFtDb21tZW50IC8gUXVlc3Rpb246IHRoaXMgc2VlbWVkIGEgYml0IHVuY2xl YXIgaW4gdGhlDQo+ID4gICAgICAgICAgICAgcHJvdG9jb2wgaS1kLCBidXQgaXMgcHJlc3VtYWJs eSByZXF1aXJlZD9dDQo+IA0KPiBEZXBlbmRzIG9uIHdoZW4gdGhlIHBhdGhzIGFyZSBjcmVhdGVk Lg0KPiANCj4gSWYgdGhleSBhcmUgY3JlYXRlZCBhdCBTWU4gdGltZSwgdGhlbiBpdCdzIE9LIElN TyB0byBkZXZlbG9wIHN1cHBvcnQNCj4gYXN5bW1ldHJpY2FsbHkuDQo+IA0KPiBJZiB0aGV5IGNh biBiZSBjcmVhdGVkIG9uY2Ugb3BlbiwgQUZBSUNUIFRDUCBpcyBtZW1vcnlsZXNzIHcuci50LiB3 aG8NCj4gb3BlbmVkIHRoZSBjb25uZWN0aW9uLCBzbyBJIGNhbid0IHNlZSB3aHkgZWl0aGVyIHNp ZGUgd291bGQgaGF2ZQ0KPiBwcml2aWxlZ2VkIHJpZ2h0cyAob3IgY291bGQgZXZlbiB0ZWxsKS4N Cg0KWWVzLCBpbmRlZWQgKGZyb20gdGhlIFRDUCBsZXZlbCkuIFBsdXMsIHRoZSBpZGVhIG9mIHdo byBvcGVucyB0aGUgc3ViZmxvdyAoaS5lLiBzZW5kcyB0aGUgU1lOKSBtYXkgbm90IGJlIHRoZSBz YW1lIGVuZHBvaW50IHdobyBoYXMgcmVxdWVzdGVkIHRoaXMgdG8gaGFwcGVuIChzZWUgYWRkcmVz cyBtYW5hZ2VtZW50IHN0dWZmKS4gDQoNCj4gPiAgICAgKiBTdWJmbG93IGVuZCBwb2ludCBkZWZp bml0aW9uDQo+ID4gICAgICAgICAgIG8gW1F1ZXN0aW9uOiBTaG91bGQgd2UgYWxsb3cgc3ViZmxv d3MgaW4gYSBzaW5nbGUgTVBUQ1ANCj4gPiAgICAgICAgICAgICBjb25uZWN0aW9uIHRvIGhhdmUg ZGlmZmVyZW50IHBvcnRzP10NCj4gDQo+IFNlZW1zIGxpa2UgeW91J2QgaGF2ZSB0byAtIG9yIHlv dSBoYXZlIHRvIGNvb3JkaW5hdGUgcG9ydCB1c2Ugb24NCj4gZGlmZmVyZW50IGFkZHJlc3NlcyBh dCBhIHNpbmdsZSBlbmRwb2ludCBjb25zdGFudGx5Lg0KDQpZZXMsIGFuZCB3ZSBoYXZlIGEgZGVt dXhpbmcgdmFsdWUgKHRoZSB0b2tlbikgYW55d2F5LiBIb3dldmVyLCBmb3Igb3B0aW1hbGl0eSBp dCBpcyBwcm9wb3NlZCB0aGF0IHRoZSBzYW1lIHBvcnRzIGFyZSB1c2VkIG9uIHRoZSBzYW1lIChh bmQgbWF5YmUgZGlmZmVyZW50KSBhZGRyZXNzZXMgcGVyIGNvbm5lY3Rpb24uDQoNCj4gPiBDb25n ZXN0aW9uIGFsZ29yaXRobQ0KPiA+DQo+ID4gPT09PT09PT09PT09PT09DQo+ID4NCj4gPiAgICAg KiB0aGUgZ29hbHMgYXJlOiBbMV0gTVBUQ1AgaXMgYXQgbGVhc3QgYXMgZ29vZCBhcyBUQ1Agd291 bGQgYmUgb24NCj4gPiAgICAgICB0aGUgYmVzdCBzdWJmbG93IHBhdGg7IFsyXSBvbiBhbnkgcGF0 aCwgYW4gTVBUQ1AgY29ubmVjdGlvbiB1c2VzDQo+ID4gICAgICAgbGVzcyAob3IgdGhlIHNhbWUp IGNhcGFjaXR5IGFzIGEgVENQIGNvbm5lY3Rpb24gd291bGQgZG87IFszXQ0KPiA+ICAgICAgIE1Q VENQIG1vdmVzIHRyYWZmaWMgb2ZmIG1vcmUgY29uZ2VzdGVkIHBhdGhzIGFuZCBvbnRvIGxlc3MN Cj4gPiAgICAgICBjb25nZXN0ZWQgb25lcw0KPiANCj4gVGhlc2Ugc291bmQgT0ssIHRob3VnaCBp dCBtaWdodCBiZSB1c2VmdWwgdG8gY29uc2lkZXIgdGhhdCBbMV0gYW5kIFsyXQ0KPiBhcmUgcmVx dWlyZW1lbnRzIChJTU8pLCB3aGVyZSBbM10gaXMgYW4gb3B0aW1pemF0aW9uIGdvYWwsIGFuZCB0 aHVzIE9LDQo+IHRvIGJyZWFrLg0KDQpJbnRlcmVzdGluZyBwb2ludCAtIGEgbmFycm93IGRpc3Rp bmN0aW9uIGJ1dCBhIHZhbGlkIG9uZS4gVGhlcmUgaXMgY2VydGFpbiBsaW5rYWdlIGJldHdlZW4g WzJdIGFuZCBbM10sIGhvd2V2ZXIsIGluIHRoYXQgd2hpbGUgaXQgbWF5IGJlIG9rYXkgdG8gYnJl YWsgWzNdIHlvdSBjYW4ndCBkbyBpdCB0byB0aGUgZGV0cmltZW50IG9mIG90aGVyIHVzZXJzIChb Ml0pLg0KDQo+ID4gQVBJDQo+ID4NCj4gPiA9PT0NCj4gPg0KPiA+ICAgICAqIG5vIGNoYW5nZXMg dG8gZXhpc3RpbmcgYXBwcyBhcmUgbmVlZGVkIHRvIHVzZSBNUFRDUDsgTVBUQ1AgdXNlcw0KPiA+ ICAgICAgIHRoZSB1bmFsdGVyZWQgVENQIHNvY2tldCBBUEkNCj4gDQo+IEkgd291bGQgc2F5IHRo aXMgaW4gYSB3YXkgdGhhdCBmbG93cyBpbnRvIHRoZSBuZXh0IGlkZWEgYmVsb3cgYmV0dGVyLA0K PiBlLmcuLCAibm8gY2hhbmdlcyBhcmUgcmVxdWlyZWQgdG8gdXNlIE1QVENQIGluIGl0cyBzaW1w bGVzdCBtb2RlIi4NCg0KQWdyZWVkLg0KDQo+ID4gICAgICogVGhlcmUgaXMgYW4gb3B0aW9uYWws IGV4dGVuZGVkIEFQSQ0KPiA+ICAgICAgICAgICBvIFtRdWVzdGlvbjogd291bGQgYm90aCBlbmRz IG5lZWQgdGhlIGV4dGVuZGVkIEFQSSwgd2l0aCBhDQo+ID4gICAgICAgICAgICAgZmFsbC1iYWNr IGlmIG5vdD9dDQo+IA0KPiBTZWVtcyBsaWtlIG9uZSBlbmQgY291bGQgd2FudCB0aGUgZXh0ZW5k ZWQgQVBJIGZvciBleHBsaWNpdCBjb250cm9sIG9mDQo+IGZsb3dzLCBidXQgdGhlIG90aGVyIGVu ZCBkb2Vzbid0IG5lZWQgdG8gY2FyZS4NCg0KWWVwLg0KDQo+ID4gICAgICAgICAgIG8gW0NvbW1l bnQ6IHByZXN1bWFibHkgdGhlIGFjdHVhbCBmZWF0dXJlcyBvZiB0aGUgZXh0ZW5kZWQgQVBJDQo+ ID4gICAgICAgICAgICAgYXJlIG91dHNpZGUgdGhlIGluaXRpYWwgaGlnaC1sZXZlbCBkZXNpZ24g ZGVjaXNpb25zXQ0KPiA+ICAgICAqIGNvbmdlc3Rpb24gY29udHJvbCBzdGF0ZSBpcyBzaGFyZWQg YW1vbmcgYXBwbGljYXRpb24tdmlzaWJsZQ0KPiA+ICAgICAgIHRyYW5zcG9ydCBpbnN0YW5jZXMg KGVnIG11bHRpcGxlIEhUVFBzIGJldHdlZW4gdGhlIHNhbWUgcGFpciBvZg0KPiA+ICAgICAgIGhv c3RzKQ0KPiANCj4gSU1PIChSRkMyMTQwLCBlLmcuKSwgeWVzIDstKQ0KPiANCj4gPiAgICAgKiAz IGFwcGxpY2F0aW9uIHByb2ZpbGVzIGFyZSBtZW50aW9uZWQgKEJ1bGsgZGF0YSB0cmFuc3BvcnQs DQo+ID4gICAgICAgTGF0ZW5jeS1zZW5zaXRpdmUgdHJhbnNwb3J0IHdpdGggb3ZlcmZsb3csIExh dGVuY3ktc2Vuc2l0aXZlDQo+ID4gICAgICAgdHJhbnNwb3J0IHdpdGggaG90IHN0YW5kIGJ5KQ0K PiA+ICAgICAgICAgICBvIFtRdWVzdGlvbjogaG93IGFyZSB0aGVzZSBzdXBwb3J0ZWQ/IElzIGEg bmVnb3RpYXRpb24NCj4gPiAgICAgICAgICAgICBtZWNoYW5pc20gbmVlZGVkP10NCj4gDQo+IFNl ZW1zIGF0IG9kZHMgd2l0aCB0aGUgY2xhaW1zIGFib3ZlIGZvciBbMV0sWzJdLFszXS4gSS5lLiwg YnVsaw0KPiB0cmFuc3BvcnQgc2VlbXMgY29tcGF0aWJsZSB3aXRoIGFsbCB0aHJlZSwgYnV0IGxh dGVuY3ktc2Vuc2l0aXZlIHNlZW1zDQo+IGxpa2UgaXQgbWlnaHQgbm90IGJlIGNvbXBhdGlibGUg d2l0aCBhbnkgb2YgdGhlc2UuDQoNCkxhdGVuY3ktc2Vuc2l0aXZlIHdvdWxkIHN0aWxsIGJlIGNv bXBhdGlibGUgd2l0aCBbMV0gYW5kIFsyXSBidXQgaXMgbm90IHNvIGNvbmNlcm5lZCB3aXRoIGNv bmdlc3Rpb24gc2hhcmluZy4gSGF2aW5nIHNhaWQgdGhhdCwgaXQgd291bGQgYmUgbGlrZWx5IHRo YXQgdGhlIGxlYXN0IGNvbmdlc3RlZCBwYXRoIGlzIG9wdGltYWwgZm9yIG1vc3QgY2FzZXMgb2Yg bGF0ZW5jeS1zZW5zaXRpdmUgdHJhbnNwb3J0IQ0KDQpSZWdhcmRzLA0KQWxhbg0KDQo= From alan.ford@roke.co.uk Tue Nov 3 10:37:42 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3868D28C181 for ; Tue, 3 Nov 2009 10:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Jfm1PZclD2r for ; Tue, 3 Nov 2009 10:37:41 -0800 (PST) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id 2E30628C15D for ; Tue, 3 Nov 2009 10:37:41 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nA3Jbkxr001344; Tue, 3 Nov 2009 19:37:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2009 18:37:55 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] High-level design decisions /architecture Thread-Index: AcpcA4Teo8ymrZWiR3+pQZ/xmklMTQArusRg References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> From: "Ford, Alan" To: "William Herrin" , X-roke-co-uk-MailScanner-ID: nA3Jbkxr001344 X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:37:42 -0000 Hi Bill, all, > > The MPTCP connection is identified, from an apps perspective, by the > > addresses associated with the original path (even if that subflow /path > > closes) >=20 > I'm concerned about this idea. One of the corner cases where shim6 > falls apart is: once the connection migrates away from the original > addresses, how do the endpoints decide whether a new connection > request for the original addresses means the migrated addresses or the > current holder of the addresses? Think: FTP. This is indeed an issue. However, what is likely to happen here is that the next connection will just be rejected, the application will fail and have to try again from scratch, this time starting with a valid connection. The bigger issue here is what security impacts this may have. I find it hard to see how an attacker could engineer a compromised situation out of this. There may be some end users receiving odd connection attempts due to this, but that case can occur today with DNS caching. > > A SYN/ACK exchange (on a single path) checks that both ends support MPTCP, > > with automatic fall-back to TCP if not >=20 > We have an awful lot of TCP options that are only valid in the > SYN-SYN/ACK exchange and only 40 bytes to put them all. What's wrong > with starting all TCP connections in non-MP mode and allowing the > connection's initiator to request MPTCP starting with any packet that > expects an ACK? We had began with assuming that a connection was either MPTCP or regular TCP from the start, so endpoints would know whether they could make use of Multipath immediately and start more subflows immediately. I'm intrigued with your suggestion, though. I see your point that there may not be any critical reason why this information should be known at the beginning of a session. I can't immediately think of any technical reason why doing it later in a session wouldn't work. But it would need further thought. Regards, Alan From scott.brim@gmail.com Tue Nov 3 10:41:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F1828C195 for ; Tue, 3 Nov 2009 10:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDa6zYvfFgqv for ; Tue, 3 Nov 2009 10:41:39 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 23D5C28C194 for ; Tue, 3 Nov 2009 10:41:39 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so1605167qwb.31 for ; Tue, 03 Nov 2009 10:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=mO2wXGCXJGewOjipoxkeqLIFh1e4tBRzwDjG6dYShMM=; b=jP2CnUvm9IyxFm/pEFj8ldecwiI82NafsqE1hg8lCXQ5k7ttQc2ZbZ3mI+cfrk6TW8 Sbsd7tqR4AlstWxLXJiFt9u5jURaDsxbKTIqvqaVy3iAf2SoIWRXy4GT2uKoB2dzQt8n cqMYLfRBHGPwQQtm5PKsGjMkIyrnvTHUObwwg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=TBilFIaZgQBhddLcahQ030QS3krwJjs06oeSGJQWVh99t+a9BDROAUSzFyd/BSGQgp /KzUXMGqU9/XwLzKELKFUdqYIilomD+UYjl0jAhDLfRRjWJ+aTDhm7xd/sYAZvNZ+XaY G5I+4Sd7KmRGbDGsEEL7LpomKMJvqC4p0x3XQ= Received: by 10.224.69.164 with SMTP id z36mr174916qai.377.1257273720020; Tue, 03 Nov 2009 10:42:00 -0800 (PST) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 23sm199370qyk.3.2009.11.03.10.41.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Nov 2009 10:41:59 -0800 (PST) Message-ID: <4AF07974.9030704@gmail.com> Date: Tue, 03 Nov 2009 13:41:56 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Joe Touch References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> <4AF04C00.10504@gmail.com> <4AF05270.1050501@isi.edu> In-Reply-To: <4AF05270.1050501@isi.edu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:41:40 -0000 Joe Touch allegedly wrote on 11/03/2009 10:55 AM: >> Joe, that's just not necessary except for legacy endpoint stacks. See >> the iPhone and "connectByName". If the API revolves around a connection >> ID, regardless of underlying addresses, then IP addresses can come and >> go as they with as long as the transport layer has some mechanism of >> maintaining session authenticity and continuity. The scenario where a >> new node gets an IP address that an old node was just using is only >> relevant if the connection is maintained using IP addresses ... which it >> isn't. > > This is fine if you're defining a new transport protocol. TCP *defines* > a connection by the socket pair. If that socket pair disappears and you > keep the connection up, I would argue you need to use a different > protocol number because you've seriously changed the semantics. MPTCP "looks like TCP on the wire" for each src/dst pair. That means it uses the same protocol number, but it doesn't mean it must behave exactly like TCP. We already change the response to packet loss. I suspect that you could do the whole TCP state machine for each src/dst pair, but in the new API > NATs may be ubiquitous, but they are NOT part of the 'architecture'. > They violate what little of the architecture is specified (RFCs 1122, > 1123, 1812). Too late, it's the new millennium. Dave Clark said "architect the inevitable" (one of my favorite sayings). >>>> * There is an optional, extended API >>>> o [Question: would both ends need the extended API, with a >>>> fall-back if not?] >>> Seems like one end could want the extended API for explicit control of >>> flows, but the other end doesn't need to care. >> Agree. The API is to access controls for the endpoint's implementation >> of the protocol. How an endpoint implements its APIs is independent of >> the protocol. > > Whoa on two counts. > > First, *IF*, as you say, "NAT is now architecture", then the API affects > nodes inside the network, not just at the endpoints. I don't understand this. Please help. I see no linkage between a transport API in an endpoint and a NAT box in the path. > Second, the API is two things - an abstract specification and an > implementation. Consider TCP, which has OPEN, CLOSE, STATUS, READ, > WRITE. Those are part of the *specification*. There's also the Un*x > "open()" call, which implements part of what OPEN specifies (arguably, > in Un*x, this also includes listen(), connect(), and bind()). > > My claim here is that the API can be asymmetric, i.e., extended on one > side and not the other. That's just claiming that all extensions are > optional on both sides, and not coordinated. Yes, I was trying to agree :-). Scott From marcelo@it.uc3m.es Tue Nov 3 10:44:10 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53A923A6A57 for ; Tue, 3 Nov 2009 10:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qc6twf-LWhs for ; Tue, 3 Nov 2009 10:44:09 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 00F933A6A50 for ; Tue, 3 Nov 2009 10:44:08 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.187]) by smtp03.uc3m.es (Postfix) with ESMTP id 74DD37F30F4; Tue, 3 Nov 2009 19:44:27 +0100 (CET) Message-ID: <4AF079FF.3070000@it.uc3m.es> Date: Tue, 03 Nov 2009 19:44:15 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Joe Touch References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> <4AEFFC63.10202@it.uc3m.es> <4AF0576B.9050505@isi.edu> In-Reply-To: <4AF0576B.9050505@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16988.000 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:44:10 -0000 Joe Touch escribió: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > marcelo bagnulo braun wrote: > >> Joe Touch escribió: >> >>>> Security >>>> >>>> ====== >>>> >>>> * exchange a token in the initial SYN for the MPTCP connection, and >>>> include the token when subflows /paths are added to the connection >>>> o [Question: Is the same token used whether the sender or >>>> receiver (of the MPTCP connection) adds the subflow? Is the >>>> same technique used for removing subflows? And closing >>>> connections, ie DATA FIN?] >>>> >>>> >>> Let's please not call this "security". Call it a flow identifier, but >>> it's trivial for on-path attackers to see, and anything small enough to >>> be appropriate for a SYN is likely to be too small to prevent exhaustion >>> attacks. >>> >>> >>> >>>> * security mechanisms will not interfere with end-to-end >>>> authentication etc >>>> >>> Yes. Specifically IMO there ought to be a TCP-AO mode supported - e.g., >>> using socketpair of the original connection for the pseudoheader used >>> for MAC calculation. >>> >>> >>> >> It would make sense to contrast the protection provided by TCP-AO witht >> he threats identified in the threat analysis and see how many of these >> it solves. >> > > Agreed. mmm, can you think of someone that could be willing to provide the text of such analysis? > Same for the nonce. > > That is already covered in the current threat analysis (see http://tools.ietf.org/html/draft-bagnulo-mptcp-threat-00) i.e. the current threat analysis threats are analyzed for both a MPTCP that does not use any form of security and one based on tokens. Since AO seems standard TCP protection, i think it make sense to extend the analysis to cover that Regards, marcelo > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkrwV2sACgkQE5f5cImnZrt0iwCeKyrt4rYoszR1MwS60Y5IkS0y > FXIAmwUg6K05KwRc26wBPWLxTVM40l9p > =Dgpo > -----END PGP SIGNATURE----- > > From wherrin@gmail.com Tue Nov 3 11:28:12 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9003A68C8 for ; Tue, 3 Nov 2009 11:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKcTVGbZd3ZR for ; Tue, 3 Nov 2009 11:28:11 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 842603A68A0 for ; Tue, 3 Nov 2009 11:28:10 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so728288eya.51 for ; Tue, 03 Nov 2009 11:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=REVz0qrESm0RVXHCcjxxERg4K2ZTHTfffSYHMMN0NcQ=; b=TMhS6TZ694Wje83K2spKeiRRduBRE7k/rOgIKV9+t24JMij4YCVcahPCq8Y4tX95m3 CiqoFESbaf/hKFnfdiIpIB0YIyqcgM5HdSZ/hwnjCNvom+5UFQVnequ2pywK0OvKFu3p 7KfmZvzS4P58x5DQSBoQjGWEbClZMQ5zsObFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=kRFj3emvBW0267ohYpqz8+gICYsBZEbzqJNdgZSQsHI89nmCONnqiHlZvrUuhv7cpK TvFU06RbT5iiXiFKbFJA1dTIIr+3ac5Qr6bC898WzuFrgB2Ri/LWAlAbT0/IuovAeDId 7j9i84QierSgTIxpZNxuO7gLTPpy1aDC9Zsk4= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.90.65 with SMTP id d43mr164255wef.41.1257276506712; Tue, 03 Nov 2009 11:28:26 -0800 (PST) In-Reply-To: <4AF04585.2050700@gmail.com> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AF04585.2050700@gmail.com> Date: Tue, 3 Nov 2009 15:28:26 -0400 X-Google-Sender-Auth: 96ed2722ff7af73f Message-ID: <3c3e3fca0911031128j4ae1b0a1vcc73f370ebb7d773@mail.gmail.com> From: William Herrin To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 19:28:12 -0000 On Tue, Nov 3, 2009 at 11:00 AM, Scott Brim wrote: > William Herrin allegedly wrote on 11/02/2009 4:28 PM: >>> each MPTCP subflow looks exactly like an ordinary, semantically independent >>> TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are >>> independent on each subflow >> >> I'm almost sold on the idea of subflows. Can you give me a run down on >> the pros and cons, particularly the cons? > > My biggest con is if your destination is multiply connected behind two > non-synchronized intrusion prevention devices. Hi Scott, I thought that was one of the pros of subflows? Since each subflow is its own 2-way TCP connection between two specific addresses they can interact with middleboxes independently without requiring the middleboxes to talk to each other? Or am I missing something? On Tue, Nov 3, 2009 at 11:55 AM, Joe Touch wrote: > Scott Brim wrote: >> Joe, that's just not necessary except for legacy endpoint stacks. See >> the iPhone and "connectByName". If the API revolves around a connection >> ID, regardless of underlying addresses, then IP addresses can come and >> go as they with as long as the transport layer has some mechanism of >> maintaining session authenticity and continuity. > > This is fine if you're defining a new transport protocol. TCP *defines* > a connection by the socket pair. If that socket pair disappears and you > keep the connection up, I would argue you need to use a different > protocol number because you've seriously changed the semantics. Hi Joe, I'll stake out a middle ground on this one. On the one hand, this entire exercise is academic if we don't keep the connection up when the original address pair fails. The high-level purpose of something like MPTCP is to break TCP's dependence on IP address stability. So, you're right: we've seriously changed the semantics of the TCP connection. On the other hand, the vast majority of TCP applications won't care about the change in semantics. If it's possible to improve these apps' capability without requiring the developers to touch them again, that's a plus that's hard to argue against. If you accept the preceding two points, it leaves an open question: what do we do about the apps which *do* depend on the non-MP semantics? My druthers here are: first and foremost be honest, and second: do what I say; don't try to guess what I mean. Where the old API can't accurately present what's going on, it should offer a "no information" response, not an approximate response. On Tue, Nov 3, 2009 at 3:54 AM, Yoshifumi Nishida wrote: > From: William Herrin >>>> The MPTCP connection is identified, from an apps perspective, by the >>>> addresses associated with the original path (even if that subflow /path >>>> closes) > > I'm concerned about this idea. > > If the answer is C, protocols like FTP which initiate multiple TCP > > connections to the same IP address fail once an endpoint gives up its > > original address. That'll also impact web browsers which employ dns > > pinning. > > In case of ftp, the choice would be something like this? > > 1: we don't support this case. ftp will fail. > 2: ftp client/server performs getsockname() before port/pasv > to check its own active IP address. (But, we need to > define getsockname() should return active IP address instead > of original IP) > 3: Develop new ftp for MPTCP (using new API etc..) > > I personally prefer 1.. then might do 3 later.. Hi Yoshifumi, I tend to think that has to be the result as well. But if so then we should avoid offering faulty information via the APIs. That is, don't identify the connection by it's original IP address pair. If an old-api application cares what the address pair is but has been incompatibly instructed to use MPTCP, help it fail quickly rather than giving it a stochastic success rate. This means that explicitly binding the local address should implicitly turn MPTCP off. It also means calls like getpeername and getsockname should return an error or zeroed values when MPTCP is enabled so that we explicitly notify the application that we can't provide accurate information. > In case of dns pinning, I don't see any issues. DNS pinning means that the browser will indefinitely refuse to try a different IP address for new TCP connections to a server that it's running javascript for. This means that although the individual connections will succeed on the changed addresses, the web session overall will still fail. Not TCP's problem strictly speaking, but if we want MPTCP to be useful at a practical level we should consider how the dozen most common application categories (like browsers using HTTP and mail servers using SMTP) will interact with it. On Tue, Nov 3, 2009 at 2:37 PM, Ford, Alan wrote: >> What's wrong >> with starting all TCP connections in non-MP mode and allowing the >> connection's initiator to request MPTCP starting with any packet that >> expects an ACK? > > I'm intrigued with your suggestion, though. I see your point that there > may not be any critical reason why this information should be known at > the beginning of a session. I can't immediately think of any technical > reason why doing it later in a session wouldn't work. But it would need > further thought. Hi Alan, My druthers would be for an API and/or system tunable delay before MPTCP starts up so that very short lived TCP connections don't suffer any new overhead. The only downside that jumps out at me is that if a connection is eligible for MPTCP we can't report to the application that the connection definitely isn't MPTCP. >> each MPTCP subflow looks exactly like an ordinary, semantically independent >> TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are >> independent on each subflow > > [Alan: Yes, I think this is an important high-level decision] Whoops, missed this one on the first read through. Retransmit is a problem. If retransmit is strictly independent then the unexpected collapse of any subflow kills the entire connection. That reduces overall TCP reliability to the product of each path's reliability. Even if we don't withdraw a segment from a subflow once it has been assigned, we need to be able to send another copy in a different subflow should the first subflow stall. Whole can of worms waiting for us there. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From touch@ISI.EDU Tue Nov 3 11:34:31 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6DC3A681A for ; Tue, 3 Nov 2009 11:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbW0h3OCgq8Y for ; Tue, 3 Nov 2009 11:34:30 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 73D8C3A67F0 for ; Tue, 3 Nov 2009 11:34:30 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3JYS5D000077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 11:34:31 -0800 (PST) Message-ID: <4AF085C4.5070601@isi.edu> Date: Tue, 03 Nov 2009 11:34:28 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Ford, Alan" References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> <2181C5F19DD0254692452BFF3EAF1D6808C85179@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808C85179@rsys005a.comm.ad.roke.co.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 19:34:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ford, Alan wrote: ... >>> * 3 application profiles are mentioned (Bulk data transport, >>> Latency-sensitive transport with overflow, Latency-sensitive >>> transport with hot stand by) >>> o [Question: how are these supported? Is a negotiation >>> mechanism needed?] >> Seems at odds with the claims above for [1],[2],[3]. I.e., bulk >> transport seems compatible with all three, but latency-sensitive seems >> like it might not be compatible with any of these. > > Latency-sensitive would still be compatible with [1] and [2] but is > not so concerned with congestion sharing. Having said that, it would > be likely that the least congested path is optimal for most cases of > latency-sensitive transport! That depends on whether you're dominated by propagation, queuing, or capacity. If you have long message, the last two are more important. If you have short messages, the first two are. Congestion affects only queuing, and can be swamped by capacity or propagation. I.e., it's not a simple decision. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwhcQACgkQE5f5cImnZruV2wCgqNGr1KIiwsp53sdRoIuB//Dl LEcAoIJSqlZ5xxM4kOKKVghHwpWhkglO =1ICg -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Nov 3 11:47:50 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB023A6908 for ; Tue, 3 Nov 2009 11:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5u2CmXeSpig for ; Tue, 3 Nov 2009 11:47:49 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id AE65A3A67DD for ; Tue, 3 Nov 2009 11:47:49 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3JlocT003598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 11:47:53 -0800 (PST) Message-ID: <4AF088E3.5040907@isi.edu> Date: Tue, 03 Nov 2009 11:47:47 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Scott Brim References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> <4AF04C00.10504@gmail.com> <4AF05270.1050501@isi.edu> <4AF07974.9030704@gmail.com> In-Reply-To: <4AF07974.9030704@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 19:47:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Brim wrote: > Joe Touch allegedly wrote on 11/03/2009 10:55 AM: >>> Joe, that's just not necessary except for legacy endpoint stacks. See >>> the iPhone and "connectByName". If the API revolves around a connection >>> ID, regardless of underlying addresses, then IP addresses can come and >>> go as they with as long as the transport layer has some mechanism of >>> maintaining session authenticity and continuity. The scenario where a >>> new node gets an IP address that an old node was just using is only >>> relevant if the connection is maintained using IP addresses ... which it >>> isn't. >> This is fine if you're defining a new transport protocol. TCP *defines* >> a connection by the socket pair. If that socket pair disappears and you >> keep the connection up, I would argue you need to use a different >> protocol number because you've seriously changed the semantics. > > MPTCP "looks like TCP on the wire" for each src/dst pair. That means it > uses the same protocol number, but it doesn't mean it must behave > exactly like TCP. We already change the response to packet > loss. I suspect that you could do the whole TCP state machine for each > src/dst pair, but in the new API A protocol is all three of: packets on the wire state at the endpoints rules for transitions between the state and packets Some changes to these argue for keeping the same protocol number, others do not. Merely keeping the wire packets the same isn't sufficient to argue that it's the same protocol, IMO. >> NATs may be ubiquitous, but they are NOT part of the 'architecture'. >> They violate what little of the architecture is specified (RFCs 1122, >> 1123, 1812). > > Too late, it's the new millennium. Dave Clark said "architect the > inevitable" (one of my favorite sayings). Then we ought to all go home. My point is that we can try to play with some cleanly defined subset of NATs, but expecting everything to be NAT-compatible is nonsensical. >>>>> * There is an optional, extended API >>>>> o [Question: would both ends need the extended API, with a >>>>> fall-back if not?] >>>> Seems like one end could want the extended API for explicit control of >>>> flows, but the other end doesn't need to care. >>> Agree. The API is to access controls for the endpoint's implementation >>> of the protocol. How an endpoint implements its APIs is independent of >>> the protocol. >> Whoa on two counts. >> >> First, *IF*, as you say, "NAT is now architecture", then the API affects >> nodes inside the network, not just at the endpoints. > > I don't understand this. Please help. I see no linkage between a > transport API in an endpoint and a NAT box in the path. Well, you said we had to live with NATs. NATs think that: a) all connections are initiated from behind a NAT, never into a NAT from the public side (excepting DMZ) b) they can modify options at will c) they can see the transport header at all (so if NATs are part of the architecture, IPsec isn't) If the transport API uses a nonce to identify connections, then the NAT needs to know about the nonce, e.g., to know whether the packets are from one connection or another (since others claim we can reuse IP addresses and the original connection doesn't need to go down). Otherwise, a FIN from one connection could tear down an association to another. But you said that NATs are part of the architecture, and they don't understand nonces, so how can you even proceed? (I'm suggesting that LIMITED NAT support is OK, but declaring full NAT support on all connections is good way to kill this and every other transport) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwiOMACgkQE5f5cImnZrt+gQCg43L8NaYwWZtT159YXIorCJc5 zskAoLcHYJMxxF+PNFzrfXnKoMW+EzVH =8pgs -----END PGP SIGNATURE----- From nishida@sfc.wide.ad.jp Tue Nov 3 12:39:38 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E35E3A6A1F for ; Tue, 3 Nov 2009 12:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.262 X-Spam-Level: * X-Spam-Status: No, score=1.262 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyPqcRAF+gUB for ; Tue, 3 Nov 2009 12:39:37 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 65B533A67D3 for ; Tue, 3 Nov 2009 12:39:37 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id B08BB4C0AA; Wed, 4 Nov 2009 05:39:53 +0900 (JST) Date: Wed, 04 Nov 2009 05:39:53 +0900 (JST) Message-Id: <20091104.053953.70139435.nishida@sfc.wide.ad.jp> To: alan.ford@roke.co.uk From: Yoshifumi Nishida In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808C85179@rsys005a.comm.ad.roke.co.uk> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> <2181C5F19DD0254692452BFF3EAF1D6808C85179@rsys005a.comm.ad.roke.co.uk> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 20:39:38 -0000 From: "Ford, Alan" Subject: Re: [multipathtcp] High-level design decisions /architecture Date: Tue, 3 Nov 2009 18:37:56 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808C85179@rsys005a.comm.ad.roke.co.uk> > > > o [Question: Should we allow subflows in a single MPTCP > > > connection to have different ports?] > > > > Seems like you'd have to - or you have to coordinate port use on > > different addresses at a single endpoint constantly. > > Yes, and we have a demuxing value (the token) anyway. However, for optimality it is proposed that the same ports are used on the same (and maybe different) addresses per connection. Then, we might need to update Add Address option in the draft to propagate port number. and the term Address ID might be a bit confusing. If we think about the possibility that application can get peer's secondary IP address outside of MPTCP (e.g. from DNS) and wants to try it, it might be convenient to use one single port for all subflows? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From touch@ISI.EDU Tue Nov 3 13:21:14 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF41C28C0EB for ; Tue, 3 Nov 2009 13:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYGzzWvz9V6w for ; Tue, 3 Nov 2009 13:21:14 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2337E3A692C for ; Tue, 3 Nov 2009 13:21:14 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3LKgvg025968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 13:20:50 -0800 (PST) Message-ID: <4AF09EA5.9030308@isi.edu> Date: Tue, 03 Nov 2009 13:20:37 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Ford, Alan" References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:21:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ford, Alan wrote: ... >> We have an awful lot of TCP options that are only valid in the >> SYN-SYN/ACK exchange and only 40 bytes to put them all. What's wrong >> with starting all TCP connections in non-MP mode and allowing the >> connection's initiator to request MPTCP starting with any packet that >> expects an ACK? > > We had began with assuming that a connection was either MPTCP or regular > TCP from the start, so endpoints would know whether they could make use > of Multipath immediately and start more subflows immediately. > > I'm intrigued with your suggestion, though. I see your point that there > may not be any critical reason why this information should be known at > the beginning of a session. I can't immediately think of any technical > reason why doing it later in a session wouldn't work. But it would need > further thought. TCP negotiates all options during the SYN - that's the only 'handshake' there is. TCP does not define option negotiation after connection establishment. I.e., you can decide to start the separate connections later, but you need to negotiate support for the option during the SYN. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwnqUACgkQE5f5cImnZrsMHwCfaAi0aGjFmXZQBBMVyVMBdkKQ x80An0ndjmVQj3mHdro0HTNiQAAV06ft =prfH -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Nov 3 13:22:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B043A67B5 for ; Tue, 3 Nov 2009 13:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+CLhyuQFdVd for ; Tue, 3 Nov 2009 13:22:59 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E3EC43A67D3 for ; Tue, 3 Nov 2009 13:22:56 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3LMt6C026272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 13:23:01 -0800 (PST) Message-ID: <4AF09F2E.9030906@isi.edu> Date: Tue, 03 Nov 2009 13:22:54 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Costin Raiciu References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> <4AF05758.4080309@isi.edu> <6E3D84BC-F010-4035-A053-76D99901294F@cs.ucl.ac.uk> <4AF05A0F.6040705@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org Mailing List" Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:23:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Costin Raiciu wrote: > I don't understand what you mean by subflows fighting each other. I was thinking of D1 fighting D2. If their probes are coordinated and desych'd, I understand that they won't fight, though. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwny4ACgkQE5f5cImnZrttmgCfaoe+ebR3HTRPLfdzyWdR/y1m XCkAoKezvOSWGrATAr7ZdsbM3F+Nt9fs =ytuE -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Nov 3 13:26:50 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3A13A68D8 for ; Tue, 3 Nov 2009 13:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QerrCgW3RJK for ; Tue, 3 Nov 2009 13:26:49 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CDD443A67D3 for ; Tue, 3 Nov 2009 13:26:49 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3LQl6e027212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 13:26:50 -0800 (PST) Message-ID: <4AF0A016.8030602@isi.edu> Date: Tue, 03 Nov 2009 13:26:46 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Handley References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> <4AF05758.4080309@isi.edu> <6E3D84BC-F010-4035-A053-76D99901294F@cs.ucl.ac.uk> <4AF05A0F.6040705@isi.edu> <84a612dd0911030843u22f0aa19u6384886afa2342d8@mail.gmail.com> In-Reply-To: <84a612dd0911030843u22f0aa19u6384886afa2342d8@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:26:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Handley wrote: > 2009/11/3 Joe Touch : >> Costin Raiciu wrote: >>> Hi Joe, >>> >>> The proposed congestion controller gives the aggregate multipath >>> connection the throughput a TCP would get on the best (fastest) of the >>> paths available (to the multipath connection). It does so only by >>> looking at loss rates and rtts on the different paths. It does not need >>> to know whether there is a shared bottleneck or not. >> If it doesn't, then you will create the potential for a single multipath >> group to fight with itself, which seems less than productive. > > Well, so long as the total window increase per RTT of all the subflows > in a connection is no more than a single vanilla TCP would get, then > you don't fight with yourself any more than one TCP would ("fighting" > in this context is pretty much equivalent to how much unacked traffic > per RTT a flow can inject - the ack-clocked traffic already had its > space last RTT, so isn't "fighting" for extra space). Fighting could occur if the subflows send packets at the same time, even if the aggregate is the same as a single TCP would have sent. A single TCP never sends two packets out at once (it serializes them), but separate TCPs could easily do this (even if the OS serializes them, they could go out simultaneously from different NICs). Keeping in mind how TCPs like to sync, this sounds like an area to keep an eye on. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwoBUACgkQE5f5cImnZruozQCggmyOhsWNSxiX+kUOvJCRSyDD cJYAnigSjqBrnI8rDcDMy8lbtYadMJxW =4YMs -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Nov 3 13:41:10 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8A23A67B5 for ; Tue, 3 Nov 2009 13:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWwh8Pf0S-Nm for ; Tue, 3 Nov 2009 13:41:09 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9C5CB3A6767 for ; Tue, 3 Nov 2009 13:41:09 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3Lf7EA000587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 13:41:09 -0800 (PST) Message-ID: <4AF0A372.1030802@isi.edu> Date: Tue, 03 Nov 2009 13:41:06 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> <4AE87562.6010804@it.uc3m.es> In-Reply-To: <4AE87562.6010804@it.uc3m.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:41:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 marcelo bagnulo braun wrote: > Interesting... the charter doesn't have IPv4 nor IPv6 in it. > I assumed that we were chartered to work on both, don't we? I thought all new protocols were *required* to address at least IPv6. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwo3IACgkQE5f5cImnZrs4IQCeITK3LoRNr20Fgf4B6mCROsUR kYAAoPsvR6VzRZ6kx+CuJScR6QbO/tPO =/SA3 -----END PGP SIGNATURE----- From mark.j.handley@gmail.com Tue Nov 3 13:45:31 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B3A3A67B5 for ; Tue, 3 Nov 2009 13:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqGLfnEntNDH for ; Tue, 3 Nov 2009 13:45:30 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 725173A6767 for ; Tue, 3 Nov 2009 13:45:30 -0800 (PST) Received: by bwz23 with SMTP id 23so8141640bwz.29 for ; Tue, 03 Nov 2009 13:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=XTnMcQTk+Ngh9IZsoWA08UrNoTRZYOwTSBG/raFfbCI=; b=bxjpWvLdrMIEUPsKe4JJKkCfdBDwSsP8fi6uonGnAj7unT0iD+cd/af/dp7wrz1vrH YmScI5EsUftLQ3WkYA4gxdpuKj4+RR8X81KbEL6tO9ONyxc0WjVnb6q56uv+Z3ti9fL/ fWFLoZeWCKvfu+cuYV344WB891XWAavQHoqao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=pAd17KZJ7a3Od3OgyXVvZ+OEFQdskeg8Jl4SreYQmjWe6+o7Ygtoo1ARJWdtnxrTwf RWiAfvv6m0VOVnVgp7UODIDXjklaM5Q5MIiNpXa4cXn3XKzkPfS95P/xm3X2e10E+PG6 rskS1OsyArCUK5A/dr7NEbj5x8f2Cd4Ot84N8= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.21.15 with SMTP id h15mr85686fab.15.1257284748154; Tue, 03 Nov 2009 13:45:48 -0800 (PST) In-Reply-To: <4AF0A016.8030602@isi.edu> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> <4AF05758.4080309@isi.edu> <6E3D84BC-F010-4035-A053-76D99901294F@cs.ucl.ac.uk> <4AF05A0F.6040705@isi.edu> <84a612dd0911030843u22f0aa19u6384886afa2342d8@mail.gmail.com> <4AF0A016.8030602@isi.edu> From: Mark Handley Date: Tue, 3 Nov 2009 21:45:28 +0000 X-Google-Sender-Auth: 1ce28c92294a5d28 Message-ID: <84a612dd0911031345s18785fcdl610888a324210583@mail.gmail.com> To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:45:31 -0000 2009/11/3 Joe Touch : > Fighting could occur if the subflows send packets at the same time, even > if the aggregate is the same as a single TCP would have sent. A single > TCP never sends two packets out at once (it serializes them), but > separate TCPs could easily do this (even if the OS serializes them, they > could go out simultaneously from different NICs). > > Keeping in mind how TCPs like to sync, this sounds like an area to keep > an eye on. Good point. I'd hope that buffers at the queue feeding the common bottleneck would cope with this, but it's possible it makes the behaviour of the aggregate at the bottleneck more bursty. We've not seen any evidence for this, but it's not something we've explicily looked for. Regular TCP is pretty busty though, sending a lot of back-to-back packets unless explicit spacing is done, so I doubt MP-TCP would be any worse in most topologies. Still, definitely another thing to look out for for in our experiments. - Mark From mark.j.handley@gmail.com Tue Nov 3 13:50:11 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93AC83A692B for ; Tue, 3 Nov 2009 13:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OddodM3QI4bX for ; Tue, 3 Nov 2009 13:50:10 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 8B3283A6808 for ; Tue, 3 Nov 2009 13:50:10 -0800 (PST) Received: by bwz23 with SMTP id 23so8146685bwz.29 for ; Tue, 03 Nov 2009 13:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=BWACQPLE/zz+n/CdS2ThnuKTJgGNmaq2XA7Ae/cKl8A=; b=YtVvt+7MPqdz+i5Dz64iWQSw/UVlVbvaubK2Q9r/nk78UH+25LBIvrf3RILAaXM8qy qOrUfHN3B0c6FNkSFWwyINMTMYGpc8GhZjgFCz+jMwMbYxdiYR/vWopTzGn4OjFSsqML c4d3YEwBZ5hqEQGXnETbcyIA7D+mOoRvNptXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=eEd9g8RQ7IjZ3EL6R04mtob/6ixYp21v5J1kV14I9g3rGqCJKK7OHaeMNRQAIw3MCD DRQDFwtTSTM7d6lPYDuT1sDsz+pMjkrbgxN0jZVV6jx6qSw0eJyS/NB9IzMLzXrCHemp ihrybl2jt93XAxOsE7ytYUhBjHUNJjyuToM70= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.27.194 with SMTP id j2mr80491fac.76.1257285028125; Tue, 03 Nov 2009 13:50:28 -0800 (PST) In-Reply-To: <4AF0A372.1030802@isi.edu> References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> <4AE87562.6010804@it.uc3m.es> <4AF0A372.1030802@isi.edu> From: Mark Handley Date: Tue, 3 Nov 2009 21:50:08 +0000 X-Google-Sender-Auth: 6fd8c4faf27ad02d Message-ID: <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:50:11 -0000 2009/11/3 Joe Touch : > marcelo bagnulo braun wrote: >> Interesting... the charter doesn't have IPv4 nor IPv6 in it. >> I assumed that we were chartered to work on both, don't we? > > I thought all new protocols were *required* to address at least IPv6. We definitely intend MP-TCP to work for both v4 and v6. More debatable is whether we want to permit mixed v4/v6 connections (some v4 subflows, some v6, in the same connection). I'm unconvinced. - Mark From scott.brim@gmail.com Tue Nov 3 13:56:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458C43A6A2B for ; Tue, 3 Nov 2009 13:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeNc6k8Ido2w for ; Tue, 3 Nov 2009 13:56:34 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 68F153A6831 for ; Tue, 3 Nov 2009 13:56:34 -0800 (PST) Received: by qyk41 with SMTP id 41so3236856qyk.29 for ; Tue, 03 Nov 2009 13:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Crb1jkoiZRLQzvlz9TepGovOK09Esh8g16o6TumWIlM=; b=uW467ACeNcUWbM+DfXkANWZZxoGRpNooFI9MIxEipP0WA3Izb86GAb49yPVIDcnFOr saCq0nOI8Lky6G99TMavbt6PADZwuBs6sWS4nn66rJVfuOe1SH7Zzq3Hl2HmjMjYqhhj HT9WlnjthWBJA4x2ME1N/jb79KOUQWngmUUr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=aNg1/2a6O5AWqhMDopquJB6mK8J5ozx3su0R5lsc6a8bFruksHb7/7VKQtFzK0ixDd DaITXsS6njQoE+DDH1ChYnfNOpkYOQVFAv4TWUrjNWEuYfOdxog4/zTONV64qTH4gqbV R2kU9vP/TeRy04t73f3G/b6YTgfl67x8znftQ= Received: by 10.224.70.133 with SMTP id d5mr307227qaj.211.1257285411998; Tue, 03 Nov 2009 13:56:51 -0800 (PST) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 22sm290767qyk.2.2009.11.03.13.56.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Nov 2009 13:56:51 -0800 (PST) Message-ID: <4AF0A720.9050701@gmail.com> Date: Tue, 03 Nov 2009 16:56:48 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Mark Handley References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> <4AE87562.6010804@it.uc3m.es> <4AF0A372.1030802@isi.edu> <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> In-Reply-To: <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:56:35 -0000 Mark Handley allegedly wrote on 11/03/2009 4:50 PM: > 2009/11/3 Joe Touch : >> marcelo bagnulo braun wrote: >>> Interesting... the charter doesn't have IPv4 nor IPv6 in it. >>> I assumed that we were chartered to work on both, don't we? >> I thought all new protocols were *required* to address at least IPv6. > > We definitely intend MP-TCP to work for both v4 and v6. More > debatable is whether we want to permit mixed v4/v6 connections (some > v4 subflows, some v6, in the same connection). I'm unconvinced. That would be fun to do in the API. From alan.ford@roke.co.uk Tue Nov 3 14:03:47 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8376328B56A for ; Tue, 3 Nov 2009 14:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chEnMW-mDcBD for ; Tue, 3 Nov 2009 14:03:46 -0800 (PST) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id A0ECE3A6831 for ; Tue, 3 Nov 2009 14:03:45 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nA3N3p8L018595; Tue, 3 Nov 2009 23:03:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2009 22:03:56 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808C8517F@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <3c3e3fca0911031128j4ae1b0a1vcc73f370ebb7d773@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] High-level design decisions /architecture Thread-Index: Acpcu+OTMGXXzzykQ3m97i5oNo3VEQAE+pow References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net><3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com><4AF04585.2050700@gmail.com> <3c3e3fca0911031128j4ae1b0a1vcc73f370ebb7d773@mail.gmail.com> From: "Ford, Alan" To: "William Herrin" , X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:03:47 -0000 Hi Bill, all, > On Tue, Nov 3, 2009 at 11:00 AM, Scott Brim wrote: > > My biggest con is if your destination is multiply connected behind two > > non-synchronized intrusion prevention devices. >=20 > Hi Scott, >=20 > I thought that was one of the pros of subflows? Since each subflow is > its own 2-way TCP connection between two specific addresses they can > interact with middleboxes independently without requiring the > middleboxes to talk to each other? >=20 > Or am I missing something? I think Scott's concern is with an IDS that may look at traffic which does not behave maliciously until it is spread across multiple subflows, thus requiring the IDS to do some correlation between (what it sees as) multiple traffic flows. But I'm sure Scott can be more specific... > On Tue, Nov 3, 2009 at 11:55 AM, Joe Touch wrote: > > Scott Brim wrote: > >> Joe, that's just not necessary except for legacy endpoint stacks. See > >> the iPhone and "connectByName". If the API revolves around a connection > >> ID, regardless of underlying addresses, then IP addresses can come and > >> go as they with as long as the transport layer has some mechanism of > >> maintaining session authenticity and continuity. > > > > This is fine if you're defining a new transport protocol. TCP *defines* > > a connection by the socket pair. If that socket pair disappears and you > > keep the connection up, I would argue you need to use a different > > protocol number because you've seriously changed the semantics. >=20 > Hi Joe, >=20 > I'll stake out a middle ground on this one. >=20 > On the one hand, this entire exercise is academic if we don't keep the > connection up when the original address pair fails. The high-level > purpose of something like MPTCP is to break TCP's dependence on IP > address stability. So, you're right: we've seriously changed the > semantics of the TCP connection. >=20 > On the other hand, the vast majority of TCP applications won't care > about the change in semantics. If it's possible to improve these apps' > capability without requiring the developers to touch them again, > that's a plus that's hard to argue against. I'd definitely agree with those two points. > If you accept the preceding two points, it leaves an open question: > what do we do about the apps which *do* depend on the non-MP > semantics? My druthers here are: first and foremost be honest, and > second: do what I say; don't try to guess what I mean. >=20 > Where the old API can't accurately present what's going on, it should > offer a "no information" response, not an approximate response. [snip] > I tend to think that has to be the result as well. But if so then we > should avoid offering faulty information via the APIs. That is, don't > identify the connection by it's original IP address pair. If an > old-api application cares what the address pair is but has been > incompatibly instructed to use MPTCP, help it fail quickly rather than > giving it a stochastic success rate. >=20 > This means that explicitly binding the local address should implicitly > turn MPTCP off. It also means calls like getpeername and getsockname > should return an error or zeroed values when MPTCP is enabled so that > we explicitly notify the application that we can't provide accurate > information. I agree with the principle behind all of that. However, I do have a concern that recommending APIs return a null value in such a case may itself be overloading an error signal to an application. I would hope that applications should be able to cope with such a return value, but it is unlikely that all will. It may be the lesser of all evils, however. > On Tue, Nov 3, 2009 at 2:37 PM, Ford, Alan wrote: > >> What's wrong > >> with starting all TCP connections in non-MP mode and allowing the > >> connection's initiator to request MPTCP starting with any packet that > >> expects an ACK? > > > > I'm intrigued with your suggestion, though. I see your point that there > > may not be any critical reason why this information should be known at > > the beginning of a session. I can't immediately think of any technical > > reason why doing it later in a session wouldn't work. But it would need > > further thought. >=20 > Hi Alan, >=20 > My druthers would be for an API and/or system tunable delay before > MPTCP starts up so that very short lived TCP connections don't suffer > any new overhead. That's a very good point, actually. One of my long-standing concerns has been how to best cope with applications that only need short-lived sessions, and don't have the extended API to express it. Another alternative could be a system-wide threshold for traffic before kicking in multipath. > The only downside that jumps out at me is that if a connection is > eligible for MPTCP we can't report to the application that the > connection definitely isn't MPTCP. Yes. And it also takes the initial decision to use MPTCP away from the initiating endpoint (not necessarily a bad idea, just something that changes what one may expect a transport protocol's behaviour to be). > >> each MPTCP subflow looks exactly like an ordinary, semantically > independent > >> TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are > >> independent on each subflow > > > > [Alan: Yes, I think this is an important high-level decision] >=20 > Whoops, missed this one on the first read through. >=20 > Retransmit is a problem. If retransmit is strictly independent then > the unexpected collapse of any subflow kills the entire connection. > That reduces overall TCP reliability to the product of each path's > reliability. Ah, I may have read that point wrong. What we have in the design as it stands is that, once a segment of data is transmitted on a subflow, that segment of subflow sequence space must only be used for that data. That does not, however, preclude also sending the same data on another subflow. The data-level sequence numbering will permit correct reassembly at the receiver, and this will ensure reliability and survivability over failure. > Even if we don't withdraw a segment from a subflow once it has been > assigned, we need to be able to send another copy in a different > subflow should the first subflow stall. Whole can of worms waiting for > us there. Ah, well, that's kinda what I was describing above. What does your can of worms contain? Regards, Alan From alan.ford@roke.co.uk Tue Nov 3 14:12:08 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E343A6808 for ; Tue, 3 Nov 2009 14:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KylaE++PBxEM for ; Tue, 3 Nov 2009 14:12:07 -0800 (PST) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id 1DFE73A67A2 for ; Tue, 3 Nov 2009 14:12:06 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nA3NCKrO018056; Tue, 3 Nov 2009 23:12:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {41E8E662-536D-4808-BBE6-F621A9324B3E} Content-class: urn:content-classes:message x-cr-hashedpuzzle: JAg= Wqo= CaLC DQSm ELTv F47Z GjOp G5yN IDag Ig62 I1/C JztU Nqs9 Qqvv RhGN R4hE; 2; bQB1AGwAdABpAHAAYQB0AGgAdABjAHAAQABpAGUAdABmAC4AbwByAGcAOwBuAGkAcwBoAGkAZABhAEAAcwBmAGMALgB3AGkAZABlAC4AYQBkAC4AagBwAA==; Sosha1_v1; 7; {41E8E662-536D-4808-BBE6-F621A9324B3E}; YQBsAGEAbgAuAGYAbwByAGQAQAByAG8AawBlAC4AYwBvAC4AdQBrAA==; Tue, 03 Nov 2009 22:12:22 GMT; UgBFADoAIABbAG0AdQBsAHQAaQBwAGEAdABoAHQAYwBwAF0AIABIAGkAZwBoAC0AbABlAHYAZQBsACAAZABlAHMAaQBnAG4AIABkAGUAYwBpAHMAaQBvAG4AcwAgAC8AYQByAGMAaABpAHQAZQBjAHQAdQByAGUA Date: Tue, 3 Nov 2009 22:12:22 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808C85180@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <20091104.053953.70139435.nishida@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] High-level design decisions /architecture Thread-Index: AcpcxdxBorSDW6+rRgeKNVSXBScL5AAC7HRw References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net><4AEF781E.4070009@isi.edu><2181C5F19DD0254692452BFF3EAF1D6808C85179@rsys005a.comm.ad.roke.co.uk> <20091104.053953.70139435.nishida@sfc.wide.ad.jp> From: "Ford, Alan" To: "Yoshifumi Nishida" X-roke-co-uk-MailScanner-ID: nA3NCKrO018056 X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:12:08 -0000 Hi Yoshifumi, all,=20 > > > > o [Question: Should we allow subflows in a single MPTCP > > > > connection to have different ports?] > > > > > > Seems like you'd have to - or you have to coordinate port use on > > > different addresses at a single endpoint constantly. > > > > Yes, and we have a demuxing value (the token) anyway. However, for > optimality it is proposed that the same ports are used on the same (and maybe > different) addresses per connection. >=20 > Then, we might need to update Add Address option in the draft to propagate > port number. > and the term Address ID might be a bit confusing. I don't see that we do. The general principle is that an endpoint should use the ports that are currently in use at the other endpoint on its new connections, to maximise getting through firewalls and middleboxes, and also to support any port-based QoS traffic engineering, etc. That doesn't preclude an endpoint from trying other port numbers with the same token, but the chances of that working would seem slim. I'm not entirely sure whether we want to explicitly permit or explicitly forbid that, yet. Unless, there is some other use for signalling alternative port numbers to use. The only case I can think of may be for tricking load balancers with the same address to route on alternative paths, but that seems tenuous at best. > If we think about the possibility that application can get peer's secondary > IP address > outside of MPTCP (e.g. from DNS) and wants to try it, it might be convenient > to > use one single port for all subflows? The idea of using additional addresses from DNS etc is an interesting one. I'm reluctant to suggest this in the protocol - it would seem to open a number of potential security issues. One thing that adds a very elementary level of security in the current design is that signalling of new subflows occurs both over the existing connection and separately. This is not ideal yet and needs refinement. Such a solution would not be possible at all with the out-of-band knowledge exchange. Besides, an endpoint that knows it has multiple addresses should signal that immediately if it wants them to be used. (And if it doesn't want its other endpoint to be used, this gives it the flexibility not to signal it). Regards, Alan From marcelo@it.uc3m.es Tue Nov 3 23:50:36 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3024E3A6877 for ; Tue, 3 Nov 2009 23:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F3+SGvG3pM0 for ; Tue, 3 Nov 2009 23:50:35 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5C3F13A6977 for ; Tue, 3 Nov 2009 23:50:35 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.187]) by smtp01.uc3m.es (Postfix) with ESMTP id 9B352BA5B2B; Wed, 4 Nov 2009 08:50:53 +0100 (CET) Message-ID: <4AF1324F.4010902@it.uc3m.es> Date: Wed, 04 Nov 2009 08:50:39 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Mark Handley References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> <4AE87562.6010804@it.uc3m.es> <4AF0A372.1030802@isi.edu> <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> In-Reply-To: <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16988.003 Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 07:50:36 -0000 Mark Handley escribió: > 2009/11/3 Joe Touch : > >> marcelo bagnulo braun wrote: >> >>> Interesting... the charter doesn't have IPv4 nor IPv6 in it. >>> I assumed that we were chartered to work on both, don't we? >>> >> I thought all new protocols were *required* to address at least IPv6. >> > > We definitely intend MP-TCP to work for both v4 and v6. More > debatable is whether we want to permit mixed v4/v6 connections (some > v4 subflows, some v6, in the same connection). I'm unconvinced. > Do you expect any special difficulty on supporting this? I mean, this would be useful for dual stack hosts. If there is no special difficulty, i would go for that. Regards, marcelo > - Mark > > From scott.brim@gmail.com Wed Nov 4 02:43:29 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1373A687D for ; Wed, 4 Nov 2009 02:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w38DnNnZusHF for ; Wed, 4 Nov 2009 02:43:28 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id CDC0D3A684D for ; Wed, 4 Nov 2009 02:43:27 -0800 (PST) Received: by qyk41 with SMTP id 41so3412377qyk.29 for ; Wed, 04 Nov 2009 02:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=4Wm9uwZLyfbv0ukRs2UgefRRgmrTiT2Ox48uqb699AM=; b=lL0UoQ6CUIwmq+5kgs76DpgU8Z34ELxLmzzMlpDw6DCwEuP8h2vzBqrgPN4QOrgXrU QDx1vPZ7rVFERC9jTLarOgC0DAdqZPpvzbTWoH4wvt2AyaUMBqJ6LgvB0zVFRTP1fNCv 2hOe+lwqOUn8rzzTWbe2HDSdiYrhKf7CcRUvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=BovGco3RCG5DsE9JmMVQC8RA6UvY1g8FzItiH2xA0SBlXLAI62HCoWc5XmP339daUt iWLg+mwcCwmJkH6jqA2s1g9hmwZMhw0aUUz0EfJi2ZqxWSyGFr7RJYTfZ29p0K/qyWar b+2A269NQtFUAph0XEuU8APTz9CFLgcX3Nyr8= Received: by 10.224.96.88 with SMTP id g24mr635335qan.361.1257331426460; Wed, 04 Nov 2009 02:43:46 -0800 (PST) Received: from sbrim-mbp.local (rrcs-24-213-141-35.nys.biz.rr.com [24.213.141.35]) by mx.google.com with ESMTPS id 21sm644533qyk.12.2009.11.04.02.43.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 02:43:45 -0800 (PST) Message-ID: <4AF15ADF.7010809@gmail.com> Date: Wed, 04 Nov 2009 05:43:43 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> <4AE87562.6010804@it.uc3m.es> <4AF0A372.1030802@isi.edu> <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> <4AF1324F.4010902@it.uc3m.es> In-Reply-To: <4AF1324F.4010902@it.uc3m.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 10:43:29 -0000 marcelo bagnulo braun allegedly wrote on 11/04/2009 2:50 AM: > Mark Handley escribió: >> 2009/11/3 Joe Touch : >> >>> marcelo bagnulo braun wrote: >>> >>>> Interesting... the charter doesn't have IPv4 nor IPv6 in it. >>>> I assumed that we were chartered to work on both, don't we? >>>> >>> I thought all new protocols were *required* to address at least IPv6. >>> >> >> We definitely intend MP-TCP to work for both v4 and v6. More >> debatable is whether we want to permit mixed v4/v6 connections (some >> v4 subflows, some v6, in the same connection). I'm unconvinced. >> > Do you expect any special difficulty on supporting this? > I mean, this would be useful for dual stack hosts. > If there is no special difficulty, i would go for that. IMHO the issue is in the API. From nishida@sfc.wide.ad.jp Wed Nov 4 02:57:18 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415CA3A696A for ; Wed, 4 Nov 2009 02:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLkbutc-83aH for ; Wed, 4 Nov 2009 02:57:17 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 5965B3A677D for ; Wed, 4 Nov 2009 02:57:17 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 777724C0CB; Wed, 4 Nov 2009 19:57:34 +0900 (JST) Date: Wed, 04 Nov 2009 19:57:34 +0900 (JST) Message-Id: <20091104.195734.88191535.nishida@sfc.wide.ad.jp> To: alan.ford@roke.co.uk From: Yoshifumi Nishida In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808C85177@rsys005a.comm.ad.roke.co.uk> <2181C5F19DD0254692452BFF3EAF1D6808C85180@rsys005a.comm.ad.roke.co.uk> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <2181C5F19DD0254692452BFF3EAF1D6808C85177@rsys005a.comm.ad.roke.co.uk> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 10:57:18 -0000 Hello Alan, Thanks for your comments. From: "Ford, Alan" Subject: RE: [multipathtcp] High-level design decisions /architecture Date: Tue, 3 Nov 2009 22:12:22 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808C85180@rsys005a.comm.ad.roke.co.uk> > > Then, we might need to update Add Address option in the draft to > propagate > > port number. > > and the term Address ID might be a bit confusing. > > I don't see that we do. The general principle is that an endpoint should > use the ports that are currently in use at the other endpoint on its new > connections, to maximise getting through firewalls and middleboxes, and > also to support any port-based QoS traffic engineering, etc. That > doesn't preclude an endpoint from trying other port numbers with the > same token, but the chances of that working would seem slim. I'm not > entirely sure whether we want to explicitly permit or explicitly forbid > that, yet. OK. Thanks for the clarification. If using different port is very limited use I guess it's not a major thing. From: "Ford, Alan" Subject: Re: [multipathtcp] High-level design decisions /architecture Date: Tue, 3 Nov 2009 18:35:40 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808C85177@rsys005a.comm.ad.roke.co.uk> > * 3 application profiles are mentioned (Bulk data transport, > Latency-sensitive transport with overflow, Latency-sensitive transport > with hot stand by) > > * [Question: how are these supported? Is a negotiation > mechanism needed?] > > [Alan: TBD ;-) The sender can control much of this; expressing policy > to/from the receiver is one of the key open issues.] Hmm.. Suppose if you have a PC with two NICs and want to use one NIC only for back-up. When you want to download something from a server, how do you specify the above requirment? All I can think is signaling mechanism.. Can we leave this as an open issues? > o [Question: what are the mechanisms for evolvability? How is it > negotiated which new module (for congestion control or path manager) to > use?] > > [Alan: I would have thought that kind of decision is entirely out of > scope for a high-level framework, and even for detailed API decisions. > This is intended entirely as implementation guidance and was not written > with the intent for people to plug-and-play different modules.] I somehow would like to know whether we're going to have one default CC algorithm or support multiple algorithms. For example, DCCP has several CC algorithms based on some profiles. In case of MPTCP, one CC is enough? How about non-reno type CC like CUBIC? Maybe the answer is we could have multiple algorithms, but how to specify is an implementation matter? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From c.raiciu@cs.ucl.ac.uk Wed Nov 4 03:15:48 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855C33A687D for ; Wed, 4 Nov 2009 03:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb0x6pIwzyC7 for ; Wed, 4 Nov 2009 03:15:47 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 9DAF03A67CC for ; Wed, 4 Nov 2009 03:15:47 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N5dnN-000C6I-VG; Wed, 04 Nov 2009 11:12:57 +0000 In-Reply-To: <20091104.195734.88191535.nishida@sfc.wide.ad.jp> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <2181C5F19DD0254692452BFF3EAF1D6808C85177@rsys005a.comm.ad.roke.co.uk> <20091104.195734.88191535.nishida@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B0898A2-0F7E-4128-B789-AC54A5D64B56@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Wed, 4 Nov 2009 11:15:49 +0000 To: Yoshifumi Nishida X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 11:15:48 -0000 Hi, >> I don't see that we do. The general principle is that an endpoint >> should >> use the ports that are currently in use at the other endpoint on >> its new >> connections, to maximise getting through firewalls and >> middleboxes, and >> also to support any port-based QoS traffic engineering, etc. That >> doesn't preclude an endpoint from trying other port numbers with the >> same token, but the chances of that working would seem slim. I'm not >> entirely sure whether we want to explicitly permit or explicitly >> forbid >> that, yet. > > OK. Thanks for the clarification. If using different port is very > limited use > I guess it's not a major thing. I agree with Alan. There is no point in sending port numbers for advertised addresses, since on subsequent subflow handshakes - which must contain the JOIN option - local demuxing is not done based on port, but based on the token in the JOIN option. > Hmm.. Suppose if you have a PC with two NICs and want to use one > NIC only for back-up. > When you want to download something from a server, how do you > specify the above requirment? > All I can think is signaling mechanism.. Can we leave this as an > open issues? This is an open issue indeed. If the endpoint is sending, it can control how much data to put on each subflow. When it's receiving, our current thinking is to use ECN (or worse, packet drops) to reduce the bandwidth on a given subflow. Costin From Michael.Tuexen@lurchi.franken.de Wed Nov 4 03:43:18 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108283A69AB for ; Wed, 4 Nov 2009 03:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUMxWTyIq35j for ; Wed, 4 Nov 2009 03:43:17 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id EA7333A63C9 for ; Wed, 4 Nov 2009 03:43:16 -0800 (PST) Received: from [IPv6:2002:508f:ecef::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:ecef:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 2AA5B1C0B4611; Wed, 4 Nov 2009 12:43:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4AF1324F.4010902@it.uc3m.es> Date: Wed, 4 Nov 2009 12:43:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D594AA3-70FC-4EA6-BCF4-E21002354415@lurchi.franken.de> References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> <4AE87562.6010804@it.uc3m.es> <4AF0A372.1030802@isi.edu> <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> <4AF1324F.4010902@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1076) Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 11:43:18 -0000 On Nov 4, 2009, at 8:50 AM, marcelo bagnulo braun wrote: > Mark Handley escribi=F3: >> 2009/11/3 Joe Touch : >> >>> marcelo bagnulo braun wrote: >>> >>>> Interesting... the charter doesn't have IPv4 nor IPv6 in it. >>>> I assumed that we were chartered to work on both, don't we? >>>> >>> I thought all new protocols were *required* to address at least =20 >>> IPv6. >>> >> >> We definitely intend MP-TCP to work for both v4 and v6. More >> debatable is whether we want to permit mixed v4/v6 connections (some >> v4 subflows, some v6, in the same connection). I'm unconvinced. >> > Do you expect any special difficulty on supporting this? At least in SCTP there is no problem in supporting it... > I mean, this would be useful for dual stack hosts. > If there is no special difficulty, i would go for that. > > Regards, marcelo > > >> - Mark >> >> > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From c.raiciu@cs.ucl.ac.uk Wed Nov 4 04:13:52 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E743A68DA for ; Wed, 4 Nov 2009 04:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6ZOGQ5OKxNC for ; Wed, 4 Nov 2009 04:13:52 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 199673A6966 for ; Wed, 4 Nov 2009 04:13:51 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N5ehc-000C7P-6K for multipathtcp@ietf.org; Wed, 04 Nov 2009 12:11:04 +0000 Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "multipathtcp@ietf.org Mailing List" From: Costin Raiciu Date: Wed, 4 Nov 2009 12:13:57 +0000 X-Mailer: Apple Mail (2.753.1) Subject: [multipathtcp] Implementers meeting in Hiroshima X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 12:13:53 -0000 Hi, We plan to have an mptcp implementers meeting in Hiroshima, with the purpose to coordinate efforts and share knowledge on implementing mptcp. A few people have expressed interest in helping implementing MPTCP. If you still want to help, this is a good time to start. Please reply stating preferences for days and times. Anything except monday afternoon works for me. I am currently aware of three implementations of mptcp in: - userland (based on an older Linux kernel, ported to userland) - by me. It implements a subset of the spec, and works on v4. - kernel 2.6, by Sebastien Barre, that works over ipv6 and uses shim6 as a way to provide multiple paths. Soon this is will changed to support v4 and address exchange through options, as defined in the protocol draft. - kernel 2.6 by Michio Honda. As far as I know this is incomplete, and doesn't run at all. Any others? The second implementation (kernel 2.6) has been coded using the userland experience, so it is more polished, and could be used as a good starting point for a reference implementation. I will come back with date and time proposals once enough people reply. Thanks, Costin From marcelo@it.uc3m.es Wed Nov 4 04:35:07 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2AF3A684D for ; Wed, 4 Nov 2009 04:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGG25+53C6cJ for ; Wed, 4 Nov 2009 04:35:06 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2F5AC3A635F for ; Wed, 4 Nov 2009 04:35:06 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.255]) by smtp01.uc3m.es (Postfix) with ESMTP id D0AFBB4D5A4; Wed, 4 Nov 2009 13:35:25 +0100 (CET) Message-ID: <4AF1750D.5020307@it.uc3m.es> Date: Wed, 04 Nov 2009 13:35:25 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Scott Brim References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> <4AE87562.6010804@it.uc3m.es> <4AF0A372.1030802@isi.edu> <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> <4AF1324F.4010902@it.uc3m.es> <4AF15ADF.7010809@gmail.com> In-Reply-To: <4AF15ADF.7010809@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16988.003 Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 12:35:07 -0000 Scott Brim escribió: > marcelo bagnulo braun allegedly wrote on 11/04/2009 2:50 AM: > >> Mark Handley escribió: >> >>> 2009/11/3 Joe Touch : >>> >>> >>>> marcelo bagnulo braun wrote: >>>> >>>> >>>>> Interesting... the charter doesn't have IPv4 nor IPv6 in it. >>>>> I assumed that we were chartered to work on both, don't we? >>>>> >>>>> >>>> I thought all new protocols were *required* to address at least IPv6. >>>> >>>> >>> We definitely intend MP-TCP to work for both v4 and v6. More >>> debatable is whether we want to permit mixed v4/v6 connections (some >>> v4 subflows, some v6, in the same connection). I'm unconvinced. >>> >>> >> Do you expect any special difficulty on supporting this? >> I mean, this would be useful for dual stack hosts. >> If there is no special difficulty, i would go for that. >> > > IMHO the issue is in the API. > > ok, i am very very far from being an API expert with that in mind I understand that we have 2 cases: the current API (i.e. no MPTCP aware), there should be no problem, the usage of "locator" of another address family should remain transparent to the application, correct? The MPTCP extended API. In this case i understnad we should distinguish whether the connection was open as an IPv6 connection or as an IPv4 connection. If it was open as an IPv6 connection, i think there is no problem, since IPv4 addresses can be represented as IPv4-mapped addresses, so the API allows to handle both IPv4 and IPv6 addresses in the same way (i.e. as IPv6 addresses). some degree of care should be taken not to form incompatible address pairs with one IPv4 and one IPv6 address. If it was opened as an IPv4 connection, then i thin more thought is needed. Regards, marcelo From sebastien.barre@uclouvain.be Wed Nov 4 07:35:34 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833DA3A67FD for ; Wed, 4 Nov 2009 07:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbnSanP3uici for ; Wed, 4 Nov 2009 07:35:33 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 3F4B33A6358 for ; Wed, 4 Nov 2009 07:35:33 -0800 (PST) Received: from [130.104.228.69] (marguerite.dhcp.info.ucl.ac.be [130.104.228.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sbarre@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id A383CF25F1; Wed, 4 Nov 2009 16:35:45 +0100 (CET) Message-ID: <4AF19F45.70705@uclouvain.be> Date: Wed, 04 Nov 2009 16:35:33 +0100 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "multipathtcp@ietf.org Mailing List" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=130.104.228.69; helo= Received-SPF: Pass (sender authenticated); receiver=; client-ip=130.104.228.69; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: A383CF25F1.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: sebastien.barre@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [multipathtcp] Implementers meeting in Hiroshima X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 15:35:34 -0000 Hi, Regarding the second implementation, I will setup a trac platform for that project, so that people can easily contribute, and I will make a first release so that people can easily install for playing. I will send another mail as soon as the trac repository is set up, probably by the end of next week. The code is currently using the git scm software, and the git tree will be connected to the trac platform. Unfortunately I will not be able to attend that meeting, but Costin knows well about this implementation. regards, Sébastien. Costin Raiciu a écrit : > Hi, > > We plan to have an mptcp implementers meeting in Hiroshima, with the > purpose to coordinate efforts and share knowledge on implementing > mptcp. A few people have expressed interest in helping implementing > MPTCP. If you still want to help, this is a good time to start. Please > reply stating preferences for days and times. Anything except monday > afternoon works for me. > > I am currently aware of three implementations of mptcp in: > - userland (based on an older Linux kernel, ported to userland) - by > me. It implements a subset of the spec, and works on v4. > - kernel 2.6, by Sebastien Barre, that works over ipv6 and uses shim6 > as a way to provide multiple paths. Soon this is will changed to > support v4 and address exchange through options, as defined in the > protocol draft. > - kernel 2.6 by Michio Honda. As far as I know this is incomplete, and > doesn't run at all. > > Any others? > > The second implementation (kernel 2.6) has been coded using the > userland experience, so it is more polished, and could be used as a > good starting point for a reference implementation. > > I will come back with date and time proposals once enough people reply. > > Thanks, > Costin > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium http://inl.info.ucl.ac.be/sbarre From mglt.ietf@gmail.com Wed Nov 4 08:13:28 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C044A3A69C8 for ; Wed, 4 Nov 2009 08:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-Mcum4-hXEv for ; Wed, 4 Nov 2009 08:13:27 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 628013A68F7 for ; Wed, 4 Nov 2009 08:13:27 -0800 (PST) Received: by ywh13 with SMTP id 13so7625479ywh.29 for ; Wed, 04 Nov 2009 08:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=crrPMgI/4P/63+Zawz6QYalxsm0yyy3Qcx+eqLCOl7U=; b=FhxBhUiPDiCs4E59eT9b8FfHPaf+gUjGuLEz8qybkLDbqpBq5joU+wyHKgyXVYRqbc 8qY3pwdRHw+Q0JxKjLXvAXMvmyiqRb+TDE/lL05JB6DR1oWaCeFl7eTCsRYa9UiGm9bC EM0H9AYlgBlWrUuEicv2h8nLwx9S0CkbCZiCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wh3L7lEOa2wPsNis0JFkbr6Ldc38WDa2iTBHidovrJ34L7+D7oo6IVv/0rHM5SU3EM Ehg5GvV1shG8ZRz8iDEC+FQeEgKWYy1znzgFqCCWiFSnrLjYDAPmI6gwPm7nCTvsK2zu xRtgxicOgpBcfFZcEnSHLF9aU1WBASs5HgP5M= MIME-Version: 1.0 Received: by 10.103.125.38 with SMTP id c38mr623140mun.119.1257351225666; Wed, 04 Nov 2009 08:13:45 -0800 (PST) In-Reply-To: <4AF19F45.70705@uclouvain.be> References: <4AF19F45.70705@uclouvain.be> Date: Wed, 4 Nov 2009 17:13:45 +0100 Message-ID: <51eafbcb0911040813k4995d938v2add8d49dd12199a@mail.gmail.com> From: Daniel Migault To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= Content-Type: multipart/alternative; boundary=0016e65aef4829ec7504778de5c9 Cc: "multipathtcp@ietf.org Mailing List" Subject: Re: [multipathtcp] Implementers meeting in Hiroshima X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 16:13:28 -0000 --0016e65aef4829ec7504778de5c9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would be interested to attempt this meeting since we are working on IPsec and multihoming issues. --i.e. interactions with IKEv2. Wednesday afternoon after dnsop would be nice for me. Regards, Daniel 2009/11/4 S=E9bastien Barr=E9 > Hi, > > Regarding the second implementation, I will setup a trac platform for tha= t > project, so that people can easily contribute, and I will make a first > release so that people can easily install for playing. > I will send another mail as soon as the trac repository is set up, probab= ly > by the end of next week. The code is currently using the git scm software= , > and the git tree will be connected to the trac platform. Unfortunately I > will not be able to attend that meeting, but Costin knows well about this > implementation. > > regards, > > S=E9bastien. > > Costin Raiciu a =E9crit : > > Hi, >> >> We plan to have an mptcp implementers meeting in Hiroshima, with the >> purpose to coordinate efforts and share knowledge on implementing mptcp.= A >> few people have expressed interest in helping implementing MPTCP. If you >> still want to help, this is a good time to start. Please reply stating >> preferences for days and times. Anything except monday afternoon works f= or >> me. >> >> I am currently aware of three implementations of mptcp in: >> - userland (based on an older Linux kernel, ported to userland) - by me. >> It implements a subset of the spec, and works on v4. >> - kernel 2.6, by Sebastien Barre, that works over ipv6 and uses shim6 as= a >> way to provide multiple paths. Soon this is will changed to support v4 a= nd >> address exchange through options, as defined in the protocol draft. >> - kernel 2.6 by Michio Honda. As far as I know this is incomplete, and >> doesn't run at all. >> >> Any others? >> >> The second implementation (kernel 2.6) has been coded using the userland >> experience, so it is more polished, and could be used as a good starting >> point for a reference implementation. >> >> I will come back with date and time proposals once enough people reply. >> >> Thanks, >> Costin >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> > > -- > S=E9bastien Barr=E9 > Researcher, > CSE department, UCLouvain, Belgium > http://inl.info.ucl.ac.be/sbarre > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016e65aef4829ec7504778de5c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would be interested to attempt this meeting since we are working on IPsec= and multihoming issues. --i.e. interactions with IKEv2.

Wednesday a= fternoon after dnsop would be nice for me.

Regards,

Daniel
2009/11/4 S=E9bastien Barr=E9 = <sebastien.barre@uclouva= in.be>
Hi,

Regarding the second implementation, I will setup a trac platform for that = project, so that people can easily contribute, and I will make a first rele= ase so that people can easily install for playing.
I will send another mail as soon as the trac repository is set up, probably= by the end of next week. The code is currently using the git scm software,= and the git tree will be connected to the trac platform. Unfortunately I w= ill not be able to attend that meeting, but Costin knows well about this im= plementation.

regards,

S=E9bastien.

Costin Raiciu a =E9crit :

Hi,

We plan to have an mptcp implementers meeting in Hiroshima, with the purpos= e to coordinate efforts and share knowledge on implementing mptcp. A few pe= ople have expressed interest in helping implementing MPTCP. If you still wa= nt to help, this is a good time to start. Please reply stating preferences = for days and times. Anything except monday afternoon works for me.

I am currently aware of three implementations of mptcp in:
- userland (based on an older Linux kernel, ported to userland) - by me. It= implements a subset of the spec, and works on v4.
- kernel 2.6, by Sebastien Barre, that works over ipv6 and uses shim6 as a = way to provide multiple paths. Soon this is will changed to support v4 and = address exchange through options, as defined in the protocol draft.
- kernel 2.6 by Michio Honda. As far as I know this is incomplete, and does= n't run at all.

Any others?

The second implementation (kernel 2.6) has been coded using the userland ex= perience, so it is more polished, and could be used as a good starting poin= t for a reference implementation.

I will come back with date and time proposals once enough people reply.

Thanks,
Costin
_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp

--
S=E9bastien Barr=E9
Researcher,
CSE department, UCLouvain, Belgium
http://inl.i= nfo.ucl.ac.be/sbarre


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



--
Daniel Miga= ult
Orange Labs -- Security
+33 6 70 72 69 58
--0016e65aef4829ec7504778de5c9-- From philip.eardley@bt.com Wed Nov 4 08:42:08 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B31F28C0F6 for ; Wed, 4 Nov 2009 08:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMEQUWJIukvH for ; Wed, 4 Nov 2009 08:42:05 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 7834528C0E1 for ; Wed, 4 Nov 2009 08:42:05 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:42:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5D6D.BC44DFA6" Date: Wed, 4 Nov 2009 16:42:02 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363A75@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Volunteers for note-takers for WG meeting Thread-Index: AcpdbbuYe/9WRT+mREqoffNTVj5N1g== From: To: , X-OriginalArrivalTime: 04 Nov 2009 16:42:26.0933 (UTC) FILETIME=[CAD62250:01CA5D6D] Subject: [multipathtcp] Volunteers for note-takers for WG meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 16:42:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5D6D.BC44DFA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please let Yoshifumi & I know if you could kindly volunteer to take some notes during the WG meeting - we need at least one & preferably two kind people. A jabber volunteer would also be nice.=20 =20 Thanks! =20 ------_=_NextPart_001_01CA5D6D.BC44DFA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please let Yoshifumi & I know if you could kindly = volunteer to take some notes during the WG meeting – we need at least one = & preferably two kind people. A jabber volunteer would also be nice. =

 

Thanks!

 

=00 ------_=_NextPart_001_01CA5D6D.BC44DFA6-- From philip.eardley@bt.com Wed Nov 4 09:01:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC97728C0DE for ; Wed, 4 Nov 2009 09:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWqaU46d6K94 for ; Wed, 4 Nov 2009 09:01:34 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 7D2763A657C for ; Wed, 4 Nov 2009 09:01:33 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 17:01:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 17:00:54 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363A78@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4AEF32BB.7020103@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] High-level design decisions /architecture Thread-Index: Acpb8qCBwu80Q2GMTny0tYGiXkMvagBfO95A From: To: X-OriginalArrivalTime: 04 Nov 2009 17:01:55.0025 (UTC) FILETIME=[8312D410:01CA5D70] Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:01:35 -0000 >From the Security discussion it seems: - the WG needs to describe /analyse threats as soon as possible. Do = people think that = http://www.ietf.org/id/draft-bagnulo-mptcp-threat-00.txt is a reasonable = starting point for this? - until the threat analysis doc has progressed a bit, it is too early to = agree on the security mechanism. We will have to wait & see whether we = can decide this in Feb/March. phil > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: 02 November 2009 19:28 > To: Eardley,PL,Philip,DEE1 R > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] High-level design decisions /architecture >=20 > philip.eardley@bt.com escribi=F3: > > > > Security > > > > =3D=3D=3D=3D=3D=3D > > > > * exchange a token in the initial SYN for the MPTCP connection, > > and include the token when subflows /paths are added to the > > connection > > o [Question: Is the same token used whether the sender or > > receiver (of the MPTCP connection) adds the subflow? Is > > the same technique used for removing subflows? And = closing > > connections, ie DATA FIN?] > > >=20 > I have been thinking about alternatives mechanisms that without > requiring heavy crypto would remove the threats from passive on path > attackers that can laucnhh attacks to the token based security (and > require the attacker to actively change the traffic in order to launch > the attack). I think this could be worth considering since the work > required by the > I haven't been able to write an ID about that just yet, but i was = hoping > to do something in the few next weeks. >=20 > Regards, marcelo >=20 >=20 >=20 > > o > > > > > > > > > > * security mechanisms will not interfere with end-to-end > > authentication etc and will be compatible with legacy = middleboxes > > > > Modularity > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > =B7 the architecture has 2 components, multipath scheduler & path > > manager - meaning that improved /different modules of each can be > > slotted in > > > > o [Comment: it is unclear from the Architecture i-d how the = congestion > > control & protocol i-ds map to these components; some of the text > > (strangely?) appears in a section about implementation] > > > > o [Question: what are the mechanisms for evolvability? How is it > > negotiated which new module (for congestion control or path manager) > > to use?] > > > > o [Question: this would seem to imply we need to define an interface > > between the modules?] > > > > =B7 there is a default path manager module, meaning it is the MUST > > fall-back option > > > > o [Comment: the charter restricts us - the path manager we work on > > will distinguish paths by multiple addresses] > > > > = ------------------------------------------------------------------------ > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > From remi.despres@free.fr Wed Nov 4 09:44:38 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBB83A6832 for ; Wed, 4 Nov 2009 09:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRyv07BXHC1X for ; Wed, 4 Nov 2009 09:44:37 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 4C0403A67E5 for ; Wed, 4 Nov 2009 09:44:35 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9DCA6E082A0; Wed, 4 Nov 2009 18:44:48 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 75455E080DE; Wed, 4 Nov 2009 18:44:45 +0100 (CET) In-Reply-To: <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> <4AE87562.6010804@it.uc3m.es> <4AF0A372.1030802@isi.edu> <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Wed, 4 Nov 2009 18:44:37 +0100 To: Mark Handley X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:44:38 -0000 Le 3 nov. 09 =E0 22:50, Mark Handley a =E9crit : > We definitely intend MP-TCP to work for both v4 and v6. Sure, as TCP is above IP, MPTCP will naturally work on both. But isn't the real question whether the protocol will support NAT =20 traversals? If yes, it would be a pity to make the IPv6 solution more complex =20 than needed just to support NAT traversals. Can't we expect that before MPTCP is agreed on and deployed, the vast =20= majority of multihomed hosts will have IPv6? RD From lars.eggert@nokia.com Wed Nov 4 11:03:17 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BFD13A69FB for ; Wed, 4 Nov 2009 11:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc2q7Yaou2-L for ; Wed, 4 Nov 2009 11:03:16 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 006313A69FA for ; Wed, 4 Nov 2009 11:03:15 -0800 (PST) Received: from [10.180.171.12] ([192.100.104.170]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA4J3K6o047981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Nov 2009 21:03:22 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-42--118683946; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <3B0898A2-0F7E-4128-B789-AC54A5D64B56@cs.ucl.ac.uk> Date: Wed, 4 Nov 2009 11:03:10 -0800 Message-Id: <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <2181C5F19DD0254692452BFF3EAF1D6808C85177@rsys005a.comm.ad.roke.co.uk> <20091104.195734.88191535.nishida@sfc.wide.ad.jp> <3B0898A2-0F7E-4128-B789-AC54A5D64B56@cs.ucl.ac.uk> To: Costin Raiciu X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Wed, 04 Nov 2009 21:03:25 +0200 (EET) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:03:17 -0000 --Apple-Mail-42--118683946 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 2009-11-4, at 3:15, Costin Raiciu wrote: > This is an open issue indeed. If the endpoint is sending, it can > control how much data to put on each subflow. When it's receiving, > our current thinking is to use ECN (or worse, packet drops) to reduce > the bandwidth on a given subflow. With per-subflow receive windows, you can use receive window tuning, too. Lars --Apple-Mail-42--118683946 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwNDE5MDMxMFowIwYJKoZIhvcNAQkEMRYEFOr0DovJm+x/5tSNlHHno5sE+yR3MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCfM4ZJZUKgabAK1yWQDyvti6C+gfXRochBhwbfi7YO4YBinMEIDOprwEoSKDz2dx8KQ/7f 03pqINo1oNDJuaRnmJPT7vyEzH12JnDkfr3Bg3GZmsLzp2GCSfpqfaEs0UGFPwcCGUBBaOlMGqB4 0ngSOPq7J3XeHGp8d+WgGPtaNXw+TBtZEwsLFGxEsLkCaeoXPYHINnE4mkex6VyaBggp87j0FRlB MYksvNWl25CH6qsjkrVgaLySlTDyXew/UbATpmt9wTNYEOfa4rJpWaxblbJVX/FC4slXj/H7kFex +fKdlPfDZaF9HNwB8bJrNUzjGR31m9uKPZhiCvop8Bz5AAAAAAAA --Apple-Mail-42--118683946-- From wherrin@gmail.com Wed Nov 4 12:10:32 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C203A67F0 for ; Wed, 4 Nov 2009 12:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJiStiIABsei for ; Wed, 4 Nov 2009 12:10:30 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 6C8123A67AD for ; Wed, 4 Nov 2009 12:10:30 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so978326eya.51 for ; Wed, 04 Nov 2009 12:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=9vpjZK5m1v5i3/R5MZCnYtC4Go0A9xKhi/OqxRIUzZQ=; b=v/gOVf3MfSCS1E8zOmAAk4gSNSHHXu412wWNwnJekSZcWNyZ/m8cP10/uLvdofdRvz Km1QLuqG8PB3hFuKipS2rZbLuDAtxRUwML7tqb8x7AZBzF2c+8FmrMSPeFvbRKcqnxe2 va74IB9/P8RLDiBmZ/HPwAnk/v6+Mz2GgJhnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=PeKGr49DHRpZxD5P4oIotjBbaT94J56dc+ZuPKFmzN+bn2NxYHn0eS1iUzUVUFGwDL QqIM0NRrESdx/zW8QsfMerQCkyQ8D5iL+L5p3w2PSY6JY2AM4jpxzL21Sam56fsHPU4+ cJbn7qqUo4YszZxSLpzXNO1oo7WPLFOluT690= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.87.131 with SMTP id y3mr677020wee.9.1257365448966; Wed, 04 Nov 2009 12:10:48 -0800 (PST) In-Reply-To: <4AF1750D.5020307@it.uc3m.es> References: <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> <4AE87562.6010804@it.uc3m.es> <4AF0A372.1030802@isi.edu> <84a612dd0911031350q669f850by4fd09711daeb6aa8@mail.gmail.com> <4AF1324F.4010902@it.uc3m.es> <4AF15ADF.7010809@gmail.com> <4AF1750D.5020307@it.uc3m.es> Date: Wed, 4 Nov 2009 16:10:48 -0400 X-Google-Sender-Auth: 6dda756d0727af73 Message-ID: <3c3e3fca0911041210h3f744d05x4aabeac2ac05948c@mail.gmail.com> From: William Herrin To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:10:32 -0000 On Wed, Nov 4, 2009 at 8:35 AM, marcelo bagnulo braun wrote: > Scott Brim escribi=F3: >>> Mark Handley escribi=F3: >>> >>>> We definitely intend MP-TCP to work for both v4 and v6. =A0More >>>> debatable is whether we want to permit mixed v4/v6 connections (some >>>> v4 subflows, some v6, in the same connection). =A0I'm unconvinced. >> >> IMHO the issue is in the API. > > The MPTCP extended API. In this case i understnad we should distinguish > whether the connection was open as an IPv6 connection or as an IPv4 > connection. > If it was open as an IPv6 connection, i think there is no problem, since > IPv4 addresses can be represented as IPv4-mapped addresses, so the API > allows to handle both IPv4 and IPv6 addresses in the same way (i.e. as IP= v6 > addresses). some degree of care should be taken not to form incompatible > address pairs with one IPv4 and one IPv6 address. > If it was opened as an IPv4 connection, then i thin more thought is neede= d. Hi Marcelo, We could just set up the extended API to be protocol agnostic from the start, yes? We don't routinely tell it which protocol to use; it tells us which protocols it has used. Which at some point in the distant future may be IPv12 and we'd like the then-legacy apps to still behave in a reasonable fashion. Main difference would be passing textual representations through the API instead of protocol-specific structures. On Wed, Nov 4, 2009 at 1:44 PM, R=E9mi Despr=E9s wro= te: > But isn't the real question whether the protocol will support NAT > traversals? > > If yes, it would be a pity to make the IPv6 solution more complex than > needed just to support NAT traversals. Hi R=E9mi , If subflows are basically TCP streams joined to the larger TCP stream then we can't expect the connection's acceptor to make new connections to the initiator. That'll blow up with any firewall, not just NAT. That was a hard lesson with active-mode FTP too. I would hope we don't have to learn it again. If we assume that only the initiator will start new subflows then client-side NAT (the initiator's end) only really raises an authentication-by-source-address issue. Which is pretty weak authentication to begin with so I'd hate to see it derail compatibility with client-side NAT. That only leaves server-side NAT. Unless someone identifies a really elegant solution for handling legacy server-side NAT, my view is: detect and fail. Include the destination address in a TCP option when you first initiate the connection and if the server sees a different address than you do (because it passed through a NAT that wasn't MPTCP-compatible enough to change the option too) then MPTCP is disabled for that connection. As for folks who want to run MPTCP in a server-side NAT environment, that's the NAT box's problem and the system administrator's configuration problem, not ours. > Can't we expect that before MPTCP is agreed on and deployed, the vast > majority of multihomed hosts will have IPv6? No. Making any prediction about IPv6 deployment beyond "slow" would be unwise. That most especially includes predictions about whether any significant portion of IPv6 users will employ NAT. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Wed Nov 4 12:18:58 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B443A690F for ; Wed, 4 Nov 2009 12:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwn4jFAXPi5Q for ; Wed, 4 Nov 2009 12:18:57 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id B2BA13A68E5 for ; Wed, 4 Nov 2009 12:18:56 -0800 (PST) Received: by ewy3 with SMTP id 3so3524135ewy.37 for ; Wed, 04 Nov 2009 12:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=zx0Ci4QWHu2uhws0ylcH/U75dECQ2L+cAYWBsmvT5d0=; b=Un2nhpMydlUEBCENMFJZgomZmQEl1VZqoyIvTWaLA1qDdkoUFRzSnHZ3UUh2bpFOi4 3CXNUSDwfdLi3KZcRueKwOur7XmHm0rHk9tpmTseyoTFntSQYjaiBLpzRbQyh/fXEhna WsTBgSmCO5Th0AB3C5Lcju5EQSScyIjlNS11Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=kayntHHcYcAzNdz9D5T6sQyB6NSI0AY3LaPFbcAhHiQQCREqMBLiM2bM48e6bnvpKn 0cD0yA0vqmux5NDEebm3X3Fyzw6vzjurHS9Pr8AsYmQmkulU/DI5RnMBoPPXzWXl00Lj gyL4F1Ep+fbS/yE4Ahtr8LNOHDIaVKZ9sJRxo= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.88.195 with SMTP id a45mr666562wef.63.1257365952338; Wed, 04 Nov 2009 12:19:12 -0800 (PST) In-Reply-To: <4AF09EA5.9030308@isi.edu> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> <4AF09EA5.9030308@isi.edu> Date: Wed, 4 Nov 2009 15:19:11 -0500 X-Google-Sender-Auth: bed4b5e9bd3839b9 Message-ID: <3c3e3fca0911041219o5ddea192h297afa82882992e3@mail.gmail.com> From: William Herrin To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:18:58 -0000 On Tue, Nov 3, 2009 at 5:20 PM, Joe Touch wrote: > TCP negotiates all options during the SYN - that's the only 'handshake' > there is. TCP does not define option negotiation after connection > establishment. > > I.e., you can decide to start the separate connections later, but you > need to negotiate support for the option during the SYN. Hi Joe, I assume that's a convention rather than a hard protocol requirement. Something previous folks working in the space have deemed a "wise idea" rather than a "all these things will break if we don't" kind of thing, yes? Is there a good discussion on this somewhere so I can read up on the rationale that brought it into being? On Tue, Nov 3, 2009 at 6:03 PM, Ford, Alan wrote: > I think Scott's concern is with an IDS that may look at traffic which > does not behave maliciously until it is spread across multiple subflows, > thus requiring the IDS to do some correlation between (what it sees as) > multiple traffic flows. But I'm sure Scott can be more specific... Oh, I see. Like splitting the HTTP request into multiple subflows so that the IDS can't see the request, yes? Smells like a system configuration issue to me: if you want the IDS to do deep packet inspection, you have to arrange for all possible flows to and from the protected system to go past the same IDS and if your protected systems are configured to support MP then then the IDS must be able to recognize MP as well. I'll entertain suggestions why it's actually worse than that, but at the moment I don't see how that's a con versus MPTCP that breaks up traffic some other way than subflows. > I do have a > concern that recommending APIs return a null value in such a case may > itself be overloading an error signal to an application. I would hope > that applications should be able to cope with such a return value, but > it is unlikely that all will. I figure that if we accept the proposal that we should support applications using the legacy API at all then the best we can do for the ones who need to know the local and/or remote address and port information is to provide values which: A. Are unlikely to induce a security problem, and B. Will tend to pull up information about multipath TCP and legacy apps if the user plugs the unexpected values into a google search. My thought on this is that we should identify some IP address which is routable as a destination in as few deployed IP stacks as possible. We can register it with IANA as meaning "multipath TCP in operation but legacy API in use." >> The only downside that jumps out at me is that if a connection is >> eligible for MPTCP we can't report to the application that the >> connection definitely isn't MPTCP. > > Yes. And it also takes the initial decision to use MPTCP away from the > initiating endpoint (not necessarily a bad idea, just something that > changes what one may expect a transport protocol's behaviour to be). Allowing either side to start MPTCP creates some complexity since: 1. The sides' attempts to start MPTCP could overlap requiring one of them to yield to the other. 2. Regardless of who starts MPTCP, only the connection's initiator can start up new subflows without running afoul of the firewall. >> Retransmit is a problem. If retransmit is strictly independent then >> the unexpected collapse of any subflow kills the entire connection. >> That reduces overall TCP reliability to the product of each path's >> reliability. > > What we have in the design as it stands is that, once a segment of data > is transmitted on a subflow, that segment of subflow sequence space must > only be used for that data. That does not, however, preclude also > sending the same data on another subflow. The data-level sequence > numbering will permit correct reassembly at the receiver, and this will > ensure reliability and survivability over failure. > > Ah, well, that's kinda what I was describing above. What does your can > of worms contain? Closed windows. When the one or more subflows stall, the buffers in the other flows will fill while the receiver waits for one of them to contain the next packet in the sequence. How do you make sure there's always enough buffer left in the other subflows to retransmit packets from the stalled flow? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nishida@sfc.wide.ad.jp Wed Nov 4 12:19:42 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91B228C133 for ; Wed, 4 Nov 2009 12:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.16 X-Spam-Level: * X-Spam-Status: No, score=1.16 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm5CkVK4qK-d for ; Wed, 4 Nov 2009 12:19:42 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id E030328C11D for ; Wed, 4 Nov 2009 12:19:41 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id DEC704C0BE; Thu, 5 Nov 2009 05:19:58 +0900 (JST) Date: Thu, 05 Nov 2009 05:19:58 +0900 (JST) Message-Id: <20091105.051958.02289937.nishida@sfc.wide.ad.jp> To: lars.eggert@nokia.com From: Yoshifumi Nishida In-Reply-To: <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com> References: <20091104.195734.88191535.nishida@sfc.wide.ad.jp> <3B0898A2-0F7E-4128-B789-AC54A5D64B56@cs.ucl.ac.uk> <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:19:42 -0000 From: Lars Eggert Subject: Re: [multipathtcp] High-level design decisions /architecture Date: Wed, 4 Nov 2009 11:03:10 -0800 Message-ID: <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com> > On 2009-11-4, at 3:15, Costin Raiciu wrote: > > This is an open issue indeed. If the endpoint is sending, it can > > control how much data to put on each subflow. When it's receiving, > > our current thinking is to use ECN (or worse, packet drops) to reduce > > the bandwidth on a given subflow. > > With per-subflow receive windows, you can use receive window tuning, > too. Well, that's an idea. Yes, I agree. I tend to agree that this can be a open issue now. But, I still have a naive question... Compared to having a tweaky algorithm at receiver side, doing simple negotiation during SYN exchange would be that difficult? (and probably we will also need to use 1 bit in Add Address option to specify primary path or etc, but it's still simple.) If we think about a small gudget like iphone, I guess simple receiving algorithm might be preferable. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From scott.brim@gmail.com Wed Nov 4 20:05:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28B43A684A for ; Wed, 4 Nov 2009 20:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGpgatYgsRww for ; Wed, 4 Nov 2009 20:05:35 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 1B42C3A67E6 for ; Wed, 4 Nov 2009 20:05:35 -0800 (PST) Received: by gxk28 with SMTP id 28so1617170gxk.9 for ; Wed, 04 Nov 2009 20:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=y4nDHA6g4J7ethkdMOkjJjk2uCcniZN2K3VC2SW5zP4=; b=IJmCTC7N8TGHpIWjxao12BhA0GQ92uqGAD33a8wlVWjycqtoOyWfM6AwJ5/EIUPYgg 7uQgTxlnJdFYJQZ6qxte/+QMjSnZWaBBQab05gG0DFSH1GAISnP7YGtrBStZD1K1YSNY IrMdONyKtNIZsWIw0ZvIBLSapDsgzFD8EEE14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=a/F5unmelOE3ZMMBN3FbSlYB2gnSVujxIrIhoQ6i+AIN7TtTHMz8j8Uy+7X49zBHIO 8260Zei4Z5A/+vL4+rwvVEYQpLHgIL9UNbBPhTLFsCPQBoZFGYi5DbwLzkVnpnZAiQV8 +RN4aiy43r7RIFgqX07Vx8B9u06KbP8d9+bxw= Received: by 10.150.24.2 with SMTP id 2mr4235377ybx.172.1257393952190; Wed, 04 Nov 2009 20:05:52 -0800 (PST) Received: from 12-187-221-19.att-inc.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 9sm630047ywe.26.2009.11.04.20.05.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 20:05:50 -0800 (PST) Message-ID: <4AF24F1B.1010506@gmail.com> Date: Wed, 04 Nov 2009 20:05:47 -0800 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Yoshifumi Nishida References: <20091104.195734.88191535.nishida@sfc.wide.ad.jp> <3B0898A2-0F7E-4128-B789-AC54A5D64B56@cs.ucl.ac.uk> <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com> <20091105.051958.02289937.nishida@sfc.wide.ad.jp> In-Reply-To: <20091105.051958.02289937.nishida@sfc.wide.ad.jp> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 04:05:36 -0000 Yoshifumi Nishida allegedly wrote on 11/04/2009 12:19 PM: > > With per-subflow receive windows, you can use receive window tuning, > > too. > > Well, that's an idea. Yes, I agree. > I tend to agree that this can be a open issue now. But, I still have a naive question... > > Compared to having a tweaky algorithm at receiver side, doing simple > negotiation during SYN exchange would be that difficult? (and probably we will > also need to use 1 bit in Add Address option to specify primary path or etc, > but it's still simple.) > If we think about a small gudget like iphone, I guess simple receiving > algorithm might be preferable. The problem with putting this in signaling is that you lose richness of what you can do. You need to have a few standard meanings for the bits (or bit values) available to you, and so on. Also, the particular effect sought here is throttling traffic, which is exactly what receive windows are good for. If there is a need for anything else, maybe signaling would be more appropriate. Scott From scott.brim@gmail.com Wed Nov 4 20:08:46 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF0C3A67E6 for ; Wed, 4 Nov 2009 20:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE+BeJwzlxnC for ; Wed, 4 Nov 2009 20:08:45 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 768B63A67A3 for ; Wed, 4 Nov 2009 20:08:45 -0800 (PST) Received: by ywh13 with SMTP id 13so8231353ywh.29 for ; Wed, 04 Nov 2009 20:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=IV1AMGo/BRg/yShHdY8GEGfeTRI7sjtD684LnZ4svlo=; b=iBbHzlRdVON7VlFvb77luP+HcI9JiBLeBaC8wwppccfKP78dNZ3AHIrppFzN68gew2 3Lbt8LZOHOPDwp2VfhFVya3a99SjCDNEnviavC0OVshikQU341iJzdRZzGzbOAa1csXL 7EETn+y8eLOXpQDCImzEx3KM/vURNcMCZ1c3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=KZ9h/V5phz6zI3UE3St6wlSyDdgshNSbskpjdv7vh5QTewIfNbVAL86K2+qQMyNXJe eu64rtO0v9j4N/XDN6fKmWVwrOVOAbqF5b9MuM37GW+/B628mVXPId8gzJmnUdo2iJxy XlaYnPG1zTPTLm8pauAD59NhGlkPRSHEbEnhI= Received: by 10.150.90.17 with SMTP id n17mr4330780ybb.71.1257394143470; Wed, 04 Nov 2009 20:09:03 -0800 (PST) Received: from 12-187-221-19.att-inc.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 6sm632934ywc.9.2009.11.04.20.09.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 20:09:02 -0800 (PST) Message-ID: <4AF24FDB.6000601@gmail.com> Date: Wed, 04 Nov 2009 20:08:59 -0800 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: John Leslie References: <2181C5F19DD0254692452BFF3EAF1D6808B826E2@rsys005a.comm.ad.roke.co.uk> <20091027221853.GO78898@verdi> In-Reply-To: <20091027221853.GO78898@verdi> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] FW: New Version Notification for draft-ford-mptcp-multiaddressed-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 04:08:46 -0000 John Leslie allegedly wrote on 10/27/2009 3:18 PM: > Ford, Alan wrote: >> We now have a new version of the MPTCP protocol draft available, which >> will be presented in Hiroshima. >> >> http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt > > Very nicely done! > > I stumbled over the term "TCP Session" in section 1.3. I'm not sure > whether there might be a better name for that concept, but in any case > I'd recommend a "glossary" entry for whatever term is used. Agree. In some contexts a "session" can involve multiple, possibly only loosely coordinated, transport "connections" between different applications.. From c.raiciu@cs.ucl.ac.uk Thu Nov 5 05:20:18 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ACBF28C0D6 for ; Thu, 5 Nov 2009 05:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKdzMUoX-exM for ; Thu, 5 Nov 2009 05:20:17 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 8EF923A6824 for ; Thu, 5 Nov 2009 05:20:17 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N62Ct-000CKl-V0; Thu, 05 Nov 2009 13:16:55 +0000 In-Reply-To: <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <2181C5F19DD0254692452BFF3EAF1D6808C85177@rsys005a.comm.ad.roke.co.uk> <20091104.195734.88191535.nishida@sfc.wide.ad.jp> <3B0898A2-0F7E-4128-B789-AC54A5D64B56@cs.ucl.ac.uk> <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E0E2C9F-28F7-4A09-8105-D095BDBBA71B@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Thu, 5 Nov 2009 13:20:21 +0000 To: Lars Eggert X-Mailer: Apple Mail (2.753.1) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 13:20:18 -0000 Hm. The problem with per subflow receive window is ensuring you don't create deadlocks. Sebastien Barre already found a case where a deadlock can appear, and I imagine there are many more. I do agree it's a neat way to control policy, but I am afraid it may introduce more problems than it solves. Costin On 4 Nov 2009, at 19:03, Lars Eggert wrote: > On 2009-11-4, at 3:15, Costin Raiciu wrote: >> This is an open issue indeed. If the endpoint is sending, it can >> control how much data to put on each subflow. When it's receiving, >> our current thinking is to use ECN (or worse, packet drops) to reduce >> the bandwidth on a given subflow. > > With per-subflow receive windows, you can use receive window > tuning, too. > > Lars From mglt.ietf@gmail.com Thu Nov 5 06:48:39 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D1C3A6ACA; Thu, 5 Nov 2009 06:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30WEcuWXjdsx; Thu, 5 Nov 2009 06:48:38 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by core3.amsl.com (Postfix) with ESMTP id E1DFE3A6AB7; Thu, 5 Nov 2009 06:48:37 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so19545gvc.15 for ; Thu, 05 Nov 2009 06:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UosYlT4cHZFLu8YCDFkE/F3I0RvHsKXU2hoMJVh1X24=; b=pngIvEJ9EKW2WCeqnPdbP9qyOxhyHLI1a74vJHv/UFfgbm6Z4SRZX2QoFS7Cts/lHD /fB21F5foWL0iXsoyhmMCTyX2dEIylbAevSBklGb6xJ9zszuqMPicOs/eztZ1ZD8iEOQ q1XBPBP6cNalDEWtag8wTQhxthF7Xtp4kDtoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j65pGnmFugRE44wPvn8be8OVe08ldZqqtH1UBzko/l/WI9GzTcz+BeN8n4ucFiPTM8 NqcMY3SDq2nzNbsj6TBfeXZKCiVdppF/eYWb2fYW9t/C8f6KQtFe9S2v6w2O7SroOO0O EcFveLk0O+v+Z2lokiKxGLyj8L/c/Z76K22UY= MIME-Version: 1.0 Received: by 10.102.197.14 with SMTP id u14mr1179348muf.39.1257432536138; Thu, 05 Nov 2009 06:48:56 -0800 (PST) In-Reply-To: References: <51eafbcb0910210129x60cf00eek4ee53df746e515a8@mail.gmail.com> Date: Thu, 5 Nov 2009 15:48:56 +0100 Message-ID: <51eafbcb0911050648u61f05eaamd6b94e608109e392@mail.gmail.com> From: Daniel Migault To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: multipart/alternative; boundary=0016364d274ba544800477a0d390 Cc: ipsec@ietf.org, multipathtcp@ietf.org, mif@ietf.org Subject: Re: [multipathtcp] IPsec multihoming and mobility X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 14:48:39 -0000 --0016364d274ba544800477a0d390 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael, Thanks for your comment, I appreciate your feed back. Sections of the requirements draft on SCTP, SHIM6 should be filled, and I will mention RFC3554 in the SCTP section. In both drafts we consider only IKEv2, so I don't think RFC3554 is really relevant. I am not an expert on IKEv1, but it looks that features introduce= d by RFC3554 are not longer necessary since with IKEv2 since IKEv2 provides the ability to negotiate multiple Traffic Selector, and TS are not associated to the ID Payload anymore. On the other hand IKEv2 or IKEv1 and RFC3554 does not enable to modify the Traffic Selectors of the Security Association. And this is one of the thing we address in the drafts. Regards, Daniel On Wed, Oct 21, 2009 at 3:44 PM, Michael T=FCxen < Michael.Tuexen@lurchi.franken.de> wrote: > Hi Daniel, > > have you looked at > http://www.ietf.org/rfc/rfc3554.txt > > Best regards > Michael > > > On Oct 21, 2009, at 10:29 AM, Daniel Migault wrote: > > Hi folks, >> >> We are currently working on IPsec issues and multihoming. Here are our >> starting work with a presentation of scenarios and requirements we addre= ss, >> as well as the design of an extension to MOBIKE. >> >> Scenarios and Requirements : >> http://tools.ietf.org/html/draft-mglt-ipsec-mm-requirements-00 >> >> Protocol Design : >> http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00 >> >> We are currently working implementing it, and looking on how other >> multihoming protocol can benefit from it. >> >> Feed backs and comments are really appreciated. >> >> Regards, >> >> Daniel >> >> >> -- >> Daniel Migault >> Orange Labs -- Security >> +33 6 70 72 69 58 >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> > > --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016364d274ba544800477a0d390 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,

Thanks for your comment, I appreciate your feed back. <= br>
Sections of the requirements draft on SCTP, SHIM6 should be filled, = and I will mention RFC3554 in the SCTP section.

In both drafts we c= onsider only IKEv2, so I don't think RFC3554 is really relevant. I am n= ot an expert on IKEv1, but it looks that features introduced by RFC3554 are= not longer necessary since with IKEv2 since IKEv2 provides the ability to = negotiate multiple Traffic Selector, and TS are not associated to the ID Pa= yload anymore.

On the other hand IKEv2 or IKEv1 and RFC3554 does not=A0 enable to modi= fy the Traffic Selectors of the Security Association. And this is one of th= e thing we address in the drafts.

Regards,

Daniel

On Wed, Oct 21, 2009 at 3:44 PM, Michael T=FCxen= <= Michael.Tuexen@lurchi.franken.de> wrote:
Hi Daniel,

have you looked at
http://ww= w.ietf.org/rfc/rfc3554.txt

Best regards
Michael


On Oct 21, 2009, at 10:29 AM, Daniel Migault wrote:

=
Hi folks,

We are currently working on IPsec issues and multihoming. Here are our star= ting work with a presentation of scenarios and requirements we address, as = well as the design of an extension to MOBIKE.

Scenarios and Requirements :
http://tools.ietf.org/html/draft-mglt-ipsec-mm-requiremen= ts-00

Protocol Design :
http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00<= br>
We are currently working implementing it, and looking on how other multihom= ing protocol can benefit from it.

Feed backs =A0and comments are really appreciated.

Regards,

Daniel


--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp




--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--0016364d274ba544800477a0d390-- From nishida@sfc.wide.ad.jp Thu Nov 5 16:59:09 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFB93A6A22 for ; Thu, 5 Nov 2009 16:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.128 X-Spam-Level: * X-Spam-Status: No, score=1.128 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFpcBR0Xy9Rr for ; Thu, 5 Nov 2009 16:59:09 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 367343A6A21 for ; Thu, 5 Nov 2009 16:59:09 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6DB124C0D8; Fri, 6 Nov 2009 09:59:27 +0900 (JST) Date: Fri, 06 Nov 2009 09:59:27 +0900 (JST) Message-Id: <20091106.095927.180401631.nishida@sfc.wide.ad.jp> To: scott.brim@gmail.com From: Yoshifumi Nishida In-Reply-To: <4AF24F1B.1010506@gmail.com> References: <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com> <20091105.051958.02289937.nishida@sfc.wide.ad.jp> <4AF24F1B.1010506@gmail.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 00:59:10 -0000 Hello, From: Scott Brim Subject: Re: [multipathtcp] High-level design decisions /architecture Date: Wed, 04 Nov 2009 20:05:47 -0800 Message-ID: <4AF24F1B.1010506@gmail.com> > Yoshifumi Nishida allegedly wrote on 11/04/2009 12:19 PM: > > > With per-subflow receive windows, you can use receive window tuning, > > > too. > > > > Well, that's an idea. Yes, I agree. > > I tend to agree that this can be a open issue now. But, I still have a naive question... > > > > Compared to having a tweaky algorithm at receiver side, doing simple > > negotiation during SYN exchange would be that difficult? (and probably we will > > also need to use 1 bit in Add Address option to specify primary path or etc, > > but it's still simple.) > > If we think about a small gudget like iphone, I guess simple receiving > > algorithm might be preferable. > > The problem with putting this in signaling is that you lose richness of > what you can do. You need to have a few standard meanings for the bits > (or bit values) available to you, and so on. Also, the particular > effect sought here is throttling traffic, which is exactly what receive > windows are good for. If there is a need for anything else, maybe > signaling would be more appropriate. Hmm. I understand your point.. but I have two opinions about this. 1: If a receiver has very sophisticated control algorithms (ACK streching or window size tweaking, etc), it can just refuse negotiation and control data transfer by itself. But, this does not prevent from having negotiation mechanism. It still will be useful for simple receivers. 2: To do better control, I guess receiver will need to know sender's transfer algorithm. Otherwise, things might get worse. This will mean we need to have a signaling mechanism anyhow. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From micchie@sfc.wide.ad.jp Fri Nov 6 00:11:16 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108103A6B8A for ; Fri, 6 Nov 2009 00:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.905 X-Spam-Level: X-Spam-Status: No, score=0.905 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-qWMRQNzYsa for ; Fri, 6 Nov 2009 00:11:14 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 7D8AD3A6A1F for ; Fri, 6 Nov 2009 00:11:14 -0800 (PST) Received: from net72-dhcp1556.sfc.keio.ac.jp (net72-dhcp1556.sfc.keio.ac.jp [133.27.78.30]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D2A194C09A for ; Fri, 6 Nov 2009 17:11:32 +0900 (JST) From: Michio Honda Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-1-15018486 Date: Fri, 6 Nov 2009 17:11:32 +0900 In-Reply-To: <51eafbcb0911040813k4995d938v2add8d49dd12199a@mail.gmail.com> To: "multipathtcp@ietf.org Mailing List" References: <4AF19F45.70705@uclouvain.be> <51eafbcb0911040813k4995d938v2add8d49dd12199a@mail.gmail.com> Message-Id: <1AEC9376-EBED-4D12-8F3B-EBA90D948F99@sfc.wide.ad.jp> X-Mailer: Apple Mail (2.1076) Subject: Re: [multipathtcp] Implementers meeting in Hiroshima X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 08:11:16 -0000 --Apple-Mail-1-15018486 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Hi, Wednesday afternoon is also fine for me. Best regards -Michio On Nov 5, 2009, at 1:13 , Daniel Migault wrote: > I would be interested to attempt this meeting since we are working =20 > on IPsec and multihoming issues. --i.e. interactions with IKEv2. > > Wednesday afternoon after dnsop would be nice for me. > > Regards, > > Daniel > 2009/11/4 S=E9bastien Barr=E9 > Hi, > > Regarding the second implementation, I will setup a trac platform =20 > for that project, so that people can easily contribute, and I will =20 > make a first release so that people can easily install for playing. > I will send another mail as soon as the trac repository is set up, =20 > probably by the end of next week. The code is currently using the =20 > git scm software, and the git tree will be connected to the trac =20 > platform. Unfortunately I will not be able to attend that meeting, =20 > but Costin knows well about this implementation. > > regards, > > S=E9bastien. > > Costin Raiciu a =E9crit : > > Hi, > > We plan to have an mptcp implementers meeting in Hiroshima, with the =20= > purpose to coordinate efforts and share knowledge on implementing =20 > mptcp. A few people have expressed interest in helping implementing =20= > MPTCP. If you still want to help, this is a good time to start. =20 > Please reply stating preferences for days and times. Anything except =20= > monday afternoon works for me. > > I am currently aware of three implementations of mptcp in: > - userland (based on an older Linux kernel, ported to userland) - by =20= > me. It implements a subset of the spec, and works on v4. > - kernel 2.6, by Sebastien Barre, that works over ipv6 and uses =20 > shim6 as a way to provide multiple paths. Soon this is will changed =20= > to support v4 and address exchange through options, as defined in =20 > the protocol draft. > - kernel 2.6 by Michio Honda. As far as I know this is incomplete, =20 > and doesn't run at all. > > Any others? > > The second implementation (kernel 2.6) has been coded using the =20 > userland experience, so it is more polished, and could be used as a =20= > good starting point for a reference implementation. > > I will come back with date and time proposals once enough people =20 > reply. > > Thanks, > Costin > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --=20 > S=E9bastien Barr=E9 > Researcher, > CSE department, UCLouvain, Belgium > http://inl.info.ucl.ac.be/sbarre > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > > > --=20 > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail-1-15018486 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I would be = interested to attempt this meeting since we are working on IPsec and = multihoming issues. --i.e. interactions with IKEv2.

Wednesday = afternoon after dnsop would be nice for = me.

Regards,

Daniel
2009/11/4 S=E9bastien Barr=E9 <sebastien.barre@uclouvain.be<= /a>>
Hi,

Regarding the second implementation, I will setup a trac platform for = that project, so that people can easily contribute, and I will make a = first release so that people can easily install for playing.
I will send another mail as soon as the trac repository is set up, = probably by the end of next week. The code is currently using the git = scm software, and the git tree will be connected to the trac platform. = Unfortunately I will not be able to attend that meeting, but Costin = knows well about this implementation.

regards,

S=E9bastien.

Costin Raiciu a =E9crit :

Hi,

We plan to have an mptcp implementers meeting in Hiroshima, with the = purpose to coordinate efforts and share knowledge on implementing mptcp. = A few people have expressed interest in helping implementing MPTCP. If = you still want to help, this is a good time to start. Please reply = stating preferences for days and times. Anything except monday afternoon = works for me.

I am currently aware of three implementations of mptcp in:
- userland (based on an older Linux kernel, ported to userland) - by me. = It implements a subset of the spec, and works on v4.
- kernel 2.6, by Sebastien Barre, that works over ipv6 and uses shim6 as = a way to provide multiple paths. Soon this is will changed to support v4 = and address exchange through options, as defined in the protocol = draft.
- kernel 2.6 by Michio Honda. As far as I know this is incomplete, and = doesn't run at all.

Any others?

The second implementation (kernel 2.6) has been coded using the userland = experience, so it is more polished, and could be used as a good starting = point for a reference implementation.

I will come back with date and time proposals once enough people = reply.

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

--
S=E9bastien Barr=E9
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre


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



--
Daniel = Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
multipathtcp mailing = list
multipathtcp@ietf.org
https:/= /www.ietf.org/mailman/listinfo/multipathtcp

= --Apple-Mail-1-15018486-- From scott.brim@gmail.com Fri Nov 6 04:03:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F343A6A77 for ; Fri, 6 Nov 2009 04:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YPtCr1HZM9S for ; Fri, 6 Nov 2009 04:03:34 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id E53DF3A6A7A for ; Fri, 6 Nov 2009 04:03:33 -0800 (PST) Received: by ywh13 with SMTP id 13so982229ywh.29 for ; Fri, 06 Nov 2009 04:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=eLelVJsyNBqolJS3mdeFjJyCLpkKIcYpgP2h4xQaYMQ=; b=Aox7ugdEbhFjS4hjI4c14NV7f5vaotuGdq3wFJywOyMBaosFTTmhhBknMqQ0SLxC4f X51Mt5t+TQB5mf+Z02hyvIB6vHSJ13G6hRPtTA28ZDWxoIlKRhVvt8RAtx78xatxa5GM IbwPweqdbd7lgXTgFee3AUsBVvazXmBUg9vxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=strBPwWRzS2WA+fNfuix28ciwaW5ApFZuXzTeAqOXl8+INAr7VwXrShAwfCvg9miwN OfRt7knMcxL1OeL6dl9eOlqCxA4LvH0x14S6iY9BofjICPj/wN8LHyKEzZNnQBwwH7cn zIGGET02983jXD7FUpxA4LsTOVv9X1wB1dJhA= Received: by 10.150.3.13 with SMTP id 13mr4187295ybc.40.1257509032803; Fri, 06 Nov 2009 04:03:52 -0800 (PST) Received: from sbrim-mbp.local (64-104-46-217.cisco.com [64.104.46.217]) by mx.google.com with ESMTPS id 23sm319ywh.33.2009.11.06.04.03.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Nov 2009 04:03:50 -0800 (PST) Message-ID: <4AF38B0F.4070106@gmail.com> Date: Fri, 06 Nov 2009 11:33:51 +0900 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Ford, Alan" References: <2181C5F19DD0254692452BFF3EAF1D6808B826E2@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808B826E2@rsys005a.comm.ad.roke.co.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] FW: New Version Notification for draft-ford-mptcp-multiaddressed-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 12:03:35 -0000 Ford, Alan allegedly wrote on 10/27/2009 10:03 AM: > Hi all, Hi Alan and all. Please forgive my lateness. I'm a control plane kind of person, not a congestion management person, so most of these comments are about the protocol itself. > > We now have a new version of the MPTCP protocol draft available, > which will be presented in Hiroshima. > > Questions and discussion very much welcome beforehand too! > o Do we want a connection identifier in every packet? E.g. would > make implementation of IDS much easier? I think so. What are the arguments against it? It deterministically avoids the kind of cases that Joe was concerned about. > 4.1 Session Initiation Why is there a "multipath capable" option exchange at all? The question is implicit in a "join" option. If the receiver does not understand the "join", it is not multipath-capable, and you fall back. > If these packets are unacknowledged, it is up to local policy to > decide how to respond. It is expected that a sender will eventually > fall back to single-path TCP (i.e. without the Multipath Capable > Option), in order to work around middleboxes that may drop packets work _through_ them, rather :-) > If an endpoint is known to be multiaddressed (e.g. through multiple > addresses returned in a DNS lookup), alternative destination > addresses SHOULD be tried first, before falling back to regular TCP. You might want to note this is no different from some TCP behaviors today, if a connection cannot be established to the first address attempted. > The "Join" option includes an "Address ID". This is an identifier, > locally unique to the sender of this option, and with only per- > connection relevance, which identifies the source address of this > packet. This serves two purposes. Firstly, if an address becomes > unexpectedly unavailable on the sender, it can signal this to the > receiver via a remove address option (Section 4.3.2) without needing > to know what the source address actually is (thus allowing the use of > NATs). This is good but ... > Secondly, it allows correlation between new connection > attempts and address signalling (Section 4.3.1), to prevent duplicate > subflow initiation. ... I have some problems with address "exchange". See below. > TBD: Instead of an Address ID, are there any cases where a Subflow ID > (i.e. unique to the subflow) would be useful instead? For example, > two addresses which become NATted to the same address? "Remove" is important but there are corner cases under all options I can think of. I'm in favor of just documenting possible rare unintended disruptions, and then just specifying "remove". For example, I could see a scenario where A and B are communicating, and A is using address 1.1.1.1 which is NATted to 3.3.3.3 by the time a packet reaches B. A loses 1.1.1.1 and switches to 2.2.2.2, but an upstream network helpfully NATs to the the same external address, 3.3.3.3, to be helpful to A. So if A loses 1.1.1.1 and sends a "remove" for its ID, unintended disruption will occur. > 4.3.1. Adding Addresses re "Add Address", I wouldn't bother. A source cannot know what its addresses will look like to a destination, and NATs are here to stay. A NAT on a particular path cannot know what a NAT on a different path will do. Under no conditions should an address for one path be carried as payload on another path. It's important to get layer violations out of the control plane. Instead of promoting a mechanism that _might_ work occasionally (and might open security holes??), let's focus on making the data plane mechanisms work really well. Thanks ... Scott From john@jlc.net Fri Nov 6 06:04:10 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB313A698C for ; Fri, 6 Nov 2009 06:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWuk2VKbPJiO for ; Fri, 6 Nov 2009 06:04:09 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id B37823A6863 for ; Fri, 6 Nov 2009 06:04:09 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3A4F333C8E; Fri, 6 Nov 2009 09:04:28 -0500 (EST) Date: Fri, 6 Nov 2009 09:04:28 -0500 From: John Leslie To: Scott Brim Message-ID: <20091106140428.GH53843@verdi> References: <2181C5F19DD0254692452BFF3EAF1D6808B826E2@rsys005a.comm.ad.roke.co.uk> <4AF38B0F.4070106@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF38B0F.4070106@gmail.com> User-Agent: Mutt/1.4.1i Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] FW: New Version Notification for draft-ford-mptcp-multiaddressed-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:04:10 -0000 Scott Brim wrote: > > I'm a control plane kind of person, not a congestion management person, > so most of these comments are about the protocol itself. Good to have someone thinking that far ahead! >> Questions and discussion very much welcome beforehand too! > >> o Do we want a connection identifier in every packet? E.g. would >> make implementation of IDS much easier? > > I think so. What are the arguments against it? It deterministically > avoids the kind of cases that Joe was concerned about. 'Twould seem to me to complicate the analysis of MPTCP packets that "look like TCP packets" to existing middleboxes. I have no objection to it -- it just feels like something which deserves to be enabled/disabled with a negotiated option. > > 4.1 Session Initiation > > Why is there a "multipath capable" option exchange at all? The question > is implicit in a "join" option. If the receiver does not understand the > "join", it is not multipath-capable, and you fall back. From the history of TCP options, it's considered "safe" to use new option in a SYN, but unsafe to introduce them later without having negotiated that both ends know what they are (during the SYN exchange). Note that although JOIN is on a SYN (and thus "safe"), it's intended to signal a subflow which may "create" a combination of subflows which look like a single TCP session to the application. The new subflow could fail for quite a few different reasons: I'd prefer to disambiguate the case where the other end doesn't talk MPCTP. (There's no actual reason we _need_ two different option numbers, of course...) >> TBD: Instead of an Address ID, are there any cases where a Subflow ID >> (i.e. unique to the subflow) would be useful instead? For example, >> two addresses which become NATted to the same address? > > "Remove" is important but there are corner cases under all options I can > think of. I'm in favor of just documenting possible rare unintended > disruptions, and then just specifying "remove". For example, I could > see a scenario where A and B are communicating, and A is using address > 1.1.1.1 which is NATted to 3.3.3.3 by the time a packet reaches B. A > loses 1.1.1.1 and switches to 2.2.2.2, but an upstream network helpfully > NATs to the the same external address, 3.3.3.3, to be helpful to A. So > if A loses 1.1.1.1 and sends a "remove" for its ID, unintended > disruption will occur. It may be caffeine deficiency, but I don't follow why the "Address ID" isn't sufficient to disambiguate this case. > > 4.3.1. Adding Addresses > > re "Add Address", I wouldn't bother. A source cannot know what its > addresses will look like to a destination, and NATs are here to stay. A > NAT on a particular path cannot know what a NAT on a different path will > do. Under no conditions should an address for one path be carried as > payload on another path. It's important to get layer violations out of > the control plane. Instead of promoting a mechanism that _might_ work > occasionally (and might open security holes??), let's focus on making > the data plane mechanisms work really well. I'm a bit nervous about "Add Address", in that a middlebox might "helpfully" transform the IPvN address. This feels like a special case of JOIN where we don't actually want to establish a subflow (perhaps out of a desire to avoid extra state information or a suspicion that the MPTCP flow won't last long enough. We do have a "chicken/egg" problem though: a pair of JOINs to introduce new addresses might both fail, whereas a JOIN between the pair of new addresses would succeed. Conversely, it looks too easy to forge source-IP on an "Add Address" and introduce a security risk. I do believe we need a mechanism to announce a new address; I'm not sure we wouldn't be better off doing it as a special-case of JOIN... -- John Leslie From alan.ford@roke.co.uk Fri Nov 6 06:34:24 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF003A69CD for ; Fri, 6 Nov 2009 06:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyJR7MMXl+Hc for ; Fri, 6 Nov 2009 06:34:23 -0800 (PST) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id 53E133A69AF for ; Fri, 6 Nov 2009 06:34:22 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nA6FYXt6024629; Fri, 6 Nov 2009 15:34:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Nov 2009 14:34:44 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808C85816@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <4AF38B0F.4070106@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] FW: New Version Notification for draft-ford-mptcp-multiaddressed-02 Thread-Index: Acpe2jTizxdDKiYzRdaMo3FOMIT0aAACAIdw References: <2181C5F19DD0254692452BFF3EAF1D6808B826E2@rsys005a.comm.ad.roke.co.uk> <4AF38B0F.4070106@gmail.com> From: "Ford, Alan" To: "Scott Brim" X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] FW: New Version Notification for draft-ford-mptcp-multiaddressed-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:34:24 -0000 Hi Scott, > Ford, Alan allegedly wrote on 10/27/2009 10:03 AM: > > We now have a new version of the MPTCP protocol draft available, > > which will be presented in Hiroshima. > > > > Questions and discussion very much welcome beforehand too! >=20 > > o Do we want a connection identifier in every packet? E.g. would > > make implementation of IDS much easier? >=20 > I think so. What are the arguments against it? It deterministically > avoids the kind of cases that Joe was concerned about. Well the key argument against it would be the overhead it would create, and also any issues with option space limits. How would such an identifier really benefit these systems, in practice? In a way that could not be achieved by caching connection id/5-tuple mappings on initialisation? > > 4.1 Session Initiation >=20 > Why is there a "multipath capable" option exchange at all? The question > is implicit in a "join" option. If the receiver does not understand the > "join", it is not multipath-capable, and you fall back. "Multipath Capable" is maybe a poor name for it. In reality, it is a "MPTCP Connection Initialization" option. It is, in effect, the source's definition of the MPTCP analogue of the source port. Remote hosts can then connect towards that. Without this, the initiator would not be able to pick a token that was unique to both the sender and the receiver. > > If these packets are unacknowledged, it is up to local policy to > > decide how to respond. It is expected that a sender will eventually > > fall back to single-path TCP (i.e. without the Multipath Capable > > Option), in order to work around middleboxes that may drop packets >=20 > work _through_ them, rather :-) >=20 > > If an endpoint is known to be multiaddressed (e.g. through multiple > > addresses returned in a DNS lookup), alternative destination > > addresses SHOULD be tried first, before falling back to regular TCP. >=20 > You might want to note this is no different from some TCP behaviors > today, if a connection cannot be established to the first address attempted. Good point. > > The "Join" option includes an "Address ID". This is an identifier, > > locally unique to the sender of this option, and with only per- > > connection relevance, which identifies the source address of this > > packet. This serves two purposes. Firstly, if an address becomes > > unexpectedly unavailable on the sender, it can signal this to the > > receiver via a remove address option (Section 4.3.2) without needing > > to know what the source address actually is (thus allowing the use of > > NATs). >=20 > This is good but ... >=20 > > Secondly, it allows correlation between new connection > > attempts and address signalling (Section 4.3.1), to prevent duplicate > > subflow initiation. >=20 > ... I have some problems with address "exchange". See below. >=20 > > TBD: Instead of an Address ID, are there any cases where a Subflow ID > > (i.e. unique to the subflow) would be useful instead? For example, > > two addresses which become NATted to the same address? >=20 > "Remove" is important but there are corner cases under all options I can > think of. I'm in favor of just documenting possible rare unintended > disruptions, and then just specifying "remove". For example, I could > see a scenario where A and B are communicating, and A is using address > 1.1.1.1 which is NATted to 3.3.3.3 by the time a packet reaches B. A > loses 1.1.1.1 and switches to 2.2.2.2, but an upstream network helpfully > NATs to the the same external address, 3.3.3.3, to be helpful to A. So > if A loses 1.1.1.1 and sends a "remove" for its ID, unintended > disruption will occur. Hmm, true, although it should open a new subflow from 2.2.2.2 and this should be able to reliably take over with no great interruption to the user. > > 4.3.1. Adding Addresses >=20 > re "Add Address", I wouldn't bother. A source cannot know what its > addresses will look like to a destination, and NATs are here to stay. A > NAT on a particular path cannot know what a NAT on a different path will > do. Under no conditions should an address for one path be carried as > payload on another path. It's important to get layer violations out of > the control plane. Instead of promoting a mechanism that _might_ work > occasionally (and might open security holes??), let's focus on making > the data plane mechanisms work really well. Hmm. There are at least two strong use cases for signalling addresses, which cannot be achieved through an implicit join. 1. Firewalls/NATs in the way. Consider: Host A Host B ---------- ------------------------ Address A1 Address B1 Address B2 ---------- ---------- ---------- | | | | (initial setup) | | |--------------------->| | |<---------------------| | | | | | ###<--------------------------| | | | | (signal address) | | |<---------------------| | | | | | (additional subflow setup) | |----------------------------------->| |<-----------------------------------| | | Here, the multihomed endpoint cannot connect back to host A due to a firewall in the way (marked as ###), so instead the explicitly signalled address is used, and Host A can connect out to it to create the second subflow. 2. IPv6 and IPv4 - in this case, where there is an existing IPv4 subflow, it is not possible for one endpoint to implicitly use another of its addresses to the same endpoint, since both ends need to know about IPv6 addresses. So a second subflow should be initiated by an endpoint signalling its IPv6 address to the other endpoint, who is then able to use its IPv6 address in an implicit connection. (This kind of scenario may also apply to other cases). There is also the undecided security element, where signalling on an existing subflow is less open to exploits than entirely new TCP sessions. Regards, Alan From remi.despres@free.fr Fri Nov 6 06:51:10 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2443A69BE for ; Fri, 6 Nov 2009 06:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os+mOeRGDdTk for ; Fri, 6 Nov 2009 06:51:09 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 810243A67D6 for ; Fri, 6 Nov 2009 06:51:07 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6CCEFE080E2; Fri, 6 Nov 2009 15:51:26 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 3E726E08130; Fri, 6 Nov 2009 15:51:24 +0100 (CET) In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808C85816@rsys005a.comm.ad.roke.co.uk> References: <2181C5F19DD0254692452BFF3EAF1D6808B826E2@rsys005a.comm.ad.roke.co.uk> <4AF38B0F.4070106@gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808C85816@rsys005a.comm.ad.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <464ADE7C-BE52-48DA-94DC-B1BA38099963@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Fri, 6 Nov 2009 15:51:15 +0100 To: "Ford, Alan" X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org, Scott Brim Subject: Re: [multipathtcp] FW: New Version Notification for draft-ford-mptcp-multiaddressed-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:51:10 -0000 Le 6 nov. 09 =E0 15:34, Ford, Alan a =E9crit : >> Ford, Alan allegedly wrote on 10/27/2009 10:03 AM: >>> o Do we want a connection identifier in every packet? E.g. >>> would make implementation of IDS much easier? >> >> I think so. What are the arguments against it? It deterministically >> avoids the kind of cases that Joe was concerned about. > > Well the key argument against it would be the overhead it would =20 > create, > and also any issues with option space limits. To deal with the option space limit, a possible approach, which I =20 personally recommend, consists in using a TCP option only in the =20 initial SYN ACK exchange. Once it is established that both ends support MPTCP, a MPTCP service =20 field in in the TCP payload can be used. RD From mark.j.handley@gmail.com Fri Nov 6 19:40:45 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5D73A6A0C for ; Fri, 6 Nov 2009 19:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UICdRyCdgXGt for ; Fri, 6 Nov 2009 19:40:43 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 4AB4E3A6835 for ; Fri, 6 Nov 2009 19:40:43 -0800 (PST) Received: by fxm7 with SMTP id 7so448439fxm.29 for ; Fri, 06 Nov 2009 19:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=4vkVWSAc7iCcauIL7G6OIfHu+G+fhURMDKneoP5cAAk=; b=ewHWcQoB84j2CcpYC2+pvi2+DnvVh3Frf47dd1fQxo8WacPIA/yJgWJwpezO8X65+g XlXPo07PGdFGyQ5g2sw3O3YMzK3bZoJvxL7GxOoR1mysosEhlxPMi9uafYqVCZCxb27m JWbaSZ4WFkZOJYhu8IiRgaM6FB64D+M3pN6LI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=roU2Xva/eeEWruoVABbs4DkMFYOqsKUiNz57FSp6xU4eUNSAiMVp4FL01CJfI/4eFj hXw4RZNCT5xoJ/noI+lx/+2K79ihFDnAPRpivGKaNf0cgsG0SJ4fw8zoR7QWqvtSjvbO diJbLVDUZ5pePnVIG3m2lmi+h36V1c417SOFE= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.98.19 with SMTP id o19mr712795fan.82.1257565264092; Fri, 06 Nov 2009 19:41:04 -0800 (PST) From: Mark Handley Date: Sat, 7 Nov 2009 03:40:44 +0000 X-Google-Sender-Auth: 53000a8b12e6d645 Message-ID: <84a612dd0911061940x1f45e1dcja57ac22666ac2546@mail.gmail.com> To: Multipath TCP Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] Multipath TCP web page X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 03:40:45 -0000 It's getting hard to keep track of all the work on MP-TCP (especially as the drafts are all individual submissions at the moment), so I've put together a web page that gathers everything together in one place: http://nrg.cs.ucl.ac.uk/mptcp/ We'll gather simulator and implementation code together here soon as well. Let me know what's missing and I'll add it. See you in Hiroshima! Mark From lars.eggert@nokia.com Fri Nov 6 21:23:22 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35FE28C1C6 for ; Fri, 6 Nov 2009 21:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cegswth8AYgn for ; Fri, 6 Nov 2009 21:23:21 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 5C8D328C1C7 for ; Fri, 6 Nov 2009 21:23:21 -0800 (PST) Received: from [IPv6:2001:dfb::24:225:ff:fe45:eccf] ([IPv6:2001:dfb:0:24:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA75NRdH037094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Nov 2009 07:23:31 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-67-91326032; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <84a612dd0911061940x1f45e1dcja57ac22666ac2546@mail.gmail.com> Date: Sat, 7 Nov 2009 14:23:20 +0900 Message-Id: <4A82105F-69EE-4BA0-9D01-B549BB82D2FD@nokia.com> References: <84a612dd0911061940x1f45e1dcja57ac22666ac2546@mail.gmail.com> To: Mark Handley X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Sat, 07 Nov 2009 07:23:33 +0200 (EET) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] Multipath TCP web page X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 05:23:22 -0000 --Apple-Mail-67-91326032 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes IMO it would have been preferable to just update the existing TSV wiki for MPTCP at http://trac.tools.ietf.org/area/tsv/trac/wiki/MultipathTcp (It already has some of the info) On 2009-11-7, at 12:40, Mark Handley wrote: > It's getting hard to keep track of all the work on MP-TCP (especially > as the drafts are all individual submissions at the moment), so I've > put together a web page that gathers everything together in one place: > http://nrg.cs.ucl.ac.uk/mptcp/ > We'll gather simulator and implementation code together here soon as > well. Let me know what's missing and I'll add it. > > See you in Hiroshima! > > Mark > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail-67-91326032 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwNzA1MjMyMFowIwYJKoZIhvcNAQkEMRYEFKBAXrylx5WrjMp0+Oqc0Z/lWRvyMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBhrgxCujDwsFDrMIsD07nu2Zr9F+az3zge2c/zqkOMkUTgCXfCBWjVANRSqo6899SMKJuc qlhbmm4EwdRhpulZJ3sN057LyxyXUXDzbpvm1dENA3fvQkkkynDG16mOCUG+R5hjkHMCNbseE9c5 lkfDC+odYAkohucAiB+ft6qaCs0Csz6ktsxewxhr0rRMjrVq4l9kQPl5CJMtYmfFgcUCzkbpqd+M GUJ0AT/jmss/cfQ4aXa/Cc73umM/HvikmIWX277Mg6uX9N9j7Sa7paaVw2+yMGYLTmGE0PPLNYRY QdLXszm60cR5Cvx4NI3Pehk0Q2rKvdyYv/bLExIwfpp/AAAAAAAA --Apple-Mail-67-91326032-- From nishida@sfc.wide.ad.jp Sat Nov 7 04:59:02 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8733A6A67 for ; Sat, 7 Nov 2009 04:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.103 X-Spam-Level: * X-Spam-Status: No, score=1.103 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbCwvSzX-k0y for ; Sat, 7 Nov 2009 04:59:01 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 385393A6A65 for ; Sat, 7 Nov 2009 04:59:01 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id B799A4C5F9; Sat, 7 Nov 2009 21:59:21 +0900 (JST) Date: Sat, 07 Nov 2009 21:59:21 +0900 (JST) Message-Id: <20091107.215921.246582402.nishida@sfc.wide.ad.jp> To: lars.eggert@nokia.com From: Yoshifumi Nishida In-Reply-To: <4A82105F-69EE-4BA0-9D01-B549BB82D2FD@nokia.com> References: <84a612dd0911061940x1f45e1dcja57ac22666ac2546@mail.gmail.com> <4A82105F-69EE-4BA0-9D01-B549BB82D2FD@nokia.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath TCP web page X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 12:59:02 -0000 How about this one? http://trac.tools.ietf.org/wg/mptcp/trac/wiki Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Lars Eggert Subject: Re: [multipathtcp] Multipath TCP web page Date: Sat, 7 Nov 2009 14:23:20 +0900 Message-ID: <4A82105F-69EE-4BA0-9D01-B549BB82D2FD@nokia.com> > IMO it would have been preferable to just update the existing TSV wiki > for MPTCP at > http://trac.tools.ietf.org/area/tsv/trac/wiki/MultipathTcp > > (It already has some of the info) > > On 2009-11-7, at 12:40, Mark Handley wrote: > > > It's getting hard to keep track of all the work on MP-TCP (especially > > as the drafts are all individual submissions at the moment), so I've > > put together a web page that gathers everything together in one place: > > http://nrg.cs.ucl.ac.uk/mptcp/ > > We'll gather simulator and implementation code together here soon as > > well. Let me know what's missing and I'll add it. > > > > See you in Hiroshima! > > > > Mark > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > From lars.eggert@nokia.com Sat Nov 7 05:17:48 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880193A69BB for ; Sat, 7 Nov 2009 05:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T62U3gbBSV9V for ; Sat, 7 Nov 2009 05:17:47 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 697A63A68AD for ; Sat, 7 Nov 2009 05:17:47 -0800 (PST) Received: from [IPv6:2001:dfb::112:225:4bff:febb:9cc6] ([IPv6:2001:dfb:0:112:225:4bff:febb:9cc6]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA7DHpEr064935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Nov 2009 15:17:55 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-73-119790837; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <20091107.215921.246582402.nishida@sfc.wide.ad.jp> Date: Sat, 7 Nov 2009 22:17:44 +0900 Message-Id: References: <84a612dd0911061940x1f45e1dcja57ac22666ac2546@mail.gmail.com> <4A82105F-69EE-4BA0-9D01-B549BB82D2FD@nokia.com> <20091107.215921.246582402.nishida@sfc.wide.ad.jp> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Sat, 07 Nov 2009 15:17:57 +0200 (EET) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath TCP web page X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 13:17:48 -0000 --Apple-Mail-73-119790837 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes That's also fine. Even better, probably. (I forgot about that one, because it only started existing once you were chartered as a WG.) Lars On 2009-11-7, at 21:59, Yoshifumi Nishida wrote: > > How about this one? > http://trac.tools.ietf.org/wg/mptcp/trac/wiki > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > From: Lars Eggert > Subject: Re: [multipathtcp] Multipath TCP web page > Date: Sat, 7 Nov 2009 14:23:20 +0900 > Message-ID: <4A82105F-69EE-4BA0-9D01-B549BB82D2FD@nokia.com> > >> IMO it would have been preferable to just update the existing TSV >> wiki >> for MPTCP at >> http://trac.tools.ietf.org/area/tsv/trac/wiki/MultipathTcp >> >> (It already has some of the info) >> >> On 2009-11-7, at 12:40, Mark Handley wrote: >> >>> It's getting hard to keep track of all the work on MP-TCP >>> (especially >>> as the drafts are all individual submissions at the moment), so I've >>> put together a web page that gathers everything together in one >>> place: >>> http://nrg.cs.ucl.ac.uk/mptcp/ >>> We'll gather simulator and implementation code together here soon as >>> well. Let me know what's missing and I'll add it. >>> >>> See you in Hiroshima! >>> >>> Mark >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >> --Apple-Mail-73-119790837 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwNzEzMTc0NVowIwYJKoZIhvcNAQkEMRYEFLor/JWrhA/CvMLcR2AIxOgFMZZPMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCAn3nr45uY0OIBR/EtdIiu0O5XZVFvacemqkKRn02fJgQ19O2NLSXWwEnOQp0sL0bJyFMk OwESEoQFh4F4YyImnkDbDHmLpBUvrXK1hDTD9U9nFvwRMvAdWmuyzecjQex/fK1nmxwGMCj3M1h7 Gl8KHPb07vBYLlcEFb/A8yOpOV1pNcxxLiBXfF8nDRBRLX0llbBzM5MQhUh9Fgmtz9aYdugO1zi8 2AOwTVziIzjrslFjPL140iQ+Ro1dh+tJlSRTh+w8dnByO8wLyvyvcI0+z/7Bs0oQlvD1Ne8TkhyI mJIJ9VBbS+Tnbk4fNSeWNoUTcvGaIUhvCFrsxSCHTFBOAAAAAAAA --Apple-Mail-73-119790837-- From nishida@sfc.wide.ad.jp Sun Nov 8 20:37:15 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0579D28C144 for ; Sun, 8 Nov 2009 20:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.083 X-Spam-Level: * X-Spam-Status: No, score=1.083 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIWLUEPWI2-i for ; Sun, 8 Nov 2009 20:37:14 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 329CE3A67CF for ; Sun, 8 Nov 2009 20:37:14 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 75D364C0CC for ; Mon, 9 Nov 2009 13:37:36 +0900 (JST) Date: Mon, 09 Nov 2009 13:37:36 +0900 (JST) Message-Id: <20091109.133736.241921586.nishida@sfc.wide.ad.jp> To: multipathtcp@ietf.org From: Yoshifumi Nishida In-Reply-To: References: X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multipathtcp] Implementers meeting in Hiroshima X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:37:15 -0000 Hi, The implementers meeting is planned to be held around 15:00 Wed. If you're intrested in joining, please send a message to this ML or notify costin or michio. They're going to go a cafe near the ANA hotel. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Costin Raiciu Subject: [multipathtcp] Implementers meeting in Hiroshima Date: Wed, 4 Nov 2009 12:13:57 +0000 Message-ID: > Hi, > > We plan to have an mptcp implementers meeting in Hiroshima, with the > purpose to coordinate efforts and share knowledge on implementing > mptcp. A few people have expressed interest in helping implementing > MPTCP. If you still want to help, this is a good time to start. Please > reply stating preferences for days and times. Anything except monday > afternoon works for me. > > I am currently aware of three implementations of mptcp in: > - userland (based on an older Linux kernel, ported to userland) - by > - me. It implements a subset of the spec, and works on v4. > - kernel 2.6, by Sebastien Barre, that works over ipv6 and uses shim6 as > - a way to provide multiple paths. Soon this is will changed to support > - v4 and address exchange through options, as defined in the protocol > - draft. > - kernel 2.6 by Michio Honda. As far as I know this is incomplete, and > - doesn't run at all. > > Any others? > > The second implementation (kernel 2.6) has been coded using the > userland experience, so it is more polished, and could be used as a > good starting point for a reference implementation. > > I will come back with date and time proposals once enough people > reply. > > Thanks, > Costin > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nishida@sfc.wide.ad.jp Sun Nov 8 23:58:24 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFEA28C129 for ; Sun, 8 Nov 2009 23:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.067 X-Spam-Level: * X-Spam-Status: No, score=1.067 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijqF-NQelCZN for ; Sun, 8 Nov 2009 23:58:23 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id B756C3A695C for ; Sun, 8 Nov 2009 23:58:23 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id EE9A54C0A9; Mon, 9 Nov 2009 16:58:45 +0900 (JST) Date: Mon, 09 Nov 2009 16:58:45 +0900 (JST) Message-Id: <20091109.165845.233410795.nishida@sfc.wide.ad.jp> To: multipathtcp@ietf.org From: Yoshifumi Nishida In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363A75@E03MVB1-UKBR.domain1.systemhost.net> References: <4A916DBC72536E419A0BD955EDECEDEC06363A75@E03MVB1-UKBR.domain1.systemhost.net> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multipathtcp] Volunteers for note-takers for WG meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:58:24 -0000 Hello, If you could volunteer for log taking and jabber, we will be grateful very much. Thanks for your cooperation. -- Phil and Yoshifumi From: Subject: Volunteers for note-takers for WG meeting Date: Wed, 4 Nov 2009 16:42:02 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363A75@E03MVB1-UKBR.domain1.systemhost.net> > Please let Yoshifumi & I know if you could kindly volunteer to take some > notes during the WG meeting - we need at least one & preferably two kind > people. A jabber volunteer would also be nice. > > > > Thanks! > > > From pasi.sarolahti@iki.fi Mon Nov 9 02:48:57 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E923428C1E9 for ; Mon, 9 Nov 2009 02:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QcrHCPjmuMN for ; Mon, 9 Nov 2009 02:48:57 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 1893E28C18F for ; Mon, 9 Nov 2009 02:48:57 -0800 (PST) Received: from host-24-222.meeting.ietf.org (host-24-222.meeting.ietf.org [133.93.24.222]) by argo.otaverkko.fi (Postfix) with ESMTP id A3A7725ED1C for ; Mon, 9 Nov 2009 12:49:21 +0200 (EET) Message-Id: From: Pasi Sarolahti To: multipathtcp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 19:49:16 +0900 X-Mailer: Apple Mail (2.936) Subject: [multipathtcp] API: which address to use X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:48:58 -0000 Hi, This problem was just discussed in the meeting. Could one possible solution to the getsockname semantics problem be to use a separate address family for multipath connections? It could be similarly structured to the traditional AF, but from the different AF the app would know the semantics are different. Separate AF also explicitly tells that multipath TCP is enabled. This would not be fully backwards compatible with legacy apps, though, which I guess was one of the design goals. - Pasi From wherrin@gmail.com Mon Nov 9 05:42:12 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9443A68B5 for ; Mon, 9 Nov 2009 05:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yi5l2ZMh1kT for ; Mon, 9 Nov 2009 05:42:11 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 987133A6814 for ; Mon, 9 Nov 2009 05:42:11 -0800 (PST) Received: by ewy3 with SMTP id 3so3103659ewy.37 for ; Mon, 09 Nov 2009 05:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=r3lU+igAfDE4ZZFPCKkSPHoI5FgTiqpbvg02+/OInsw=; b=hMokd1EWdTk8SBy8SRwsyq5eBJVAZb0dwIkxJ6b7wlNap61H7Aj2lGKAk2L23OMevB ALJkUOSfw3CCS9GyVzvtmSGzlGAtloeRgxDf/ck1IXKIC4YaSX2pbHkvFRUIyXCboZek bFhbp208xf/4VGSm8ZyMYGHQGUqOqOZ3GzuPA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=SJaU/8vtzVVzw/eKy0n8l6C2ztT8Kfz/BklHRevx/ts4hS+WHbIGg4xK0A7bjIpAjV UFWxX/jD/9DlyhhnKG2g4gA8fjYApQyRGgWbu1DYJ3DzloNSY29t02kMsz8XfZTXGi+O oh8vL8GCnq3mS2rc+/PvG3KDdDYKiYcJF+t0U= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.90.131 with SMTP id e3mr819363wef.69.1257774152392; Mon, 09 Nov 2009 05:42:32 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Nov 2009 08:42:32 -0500 X-Google-Sender-Auth: 63e8ed76f0e7ab37 Message-ID: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> From: William Herrin To: Pasi Sarolahti Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] API: which address to use X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:42:12 -0000 On Mon, Nov 9, 2009 at 5:49 AM, Pasi Sarolahti wrote: > This problem was just discussed in the meeting. Could one possible solution > to the getsockname semantics problem be to use a separate address family for > multipath connections? It could be similarly structured to the traditional > AF, but from the different AF the app would know the semantics are > different. Hi Pasi, Not really, no. Backwards compatibility is an issue, as you mentioned. So is a desire to be able to use both IPv4 and IPv6 paths in a single multipath TCP connection. If it's a legacy app then it's expecting getsockname to return the same address family that it used to initiate the socket. If you provide something else you could open a path for buffer overflows or other mischief. For applications which are aware of Multipath TCP, the underlying address is quite literally the wrong question. The connection has candidate addresses, active subflows and some form of shared identifier but it doesn't have "a" local address. Getsockname and getpeername should fail with EMULTIPATH. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Mon Nov 9 06:15:24 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C313828C11E for ; Mon, 9 Nov 2009 06:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql4NPlboqjYN for ; Mon, 9 Nov 2009 06:15:24 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id BDCB13A67E5 for ; Mon, 9 Nov 2009 06:15:23 -0800 (PST) Received: by ewy3 with SMTP id 3so3137232ewy.37 for ; Mon, 09 Nov 2009 06:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=DSdTXAPoNrryZh7ckko8+EofxvwCcWxaiI3sm7PM7L8=; b=H/wNaUlewgyoBFsJitN4cdUQTk65iaM/5Q71UaC2mUX2cjSSG8zAXFSE9FOyIftVld O9n2YMXjuFrzy6ZfRtV7Yq9YQ31MT12gwY/dWPadx3LCHqJXuMHBtlzIKPkwltQHNKAj BtMwzEqXgSjHSqiLi47hAGf9OmhuPBhFsS4rU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=oSBh3fdgiknEOvqmF3jZGgGHe6kH0PNVuIFuAmdoCuhrW0pNSSPxvsVs2LQWODeSE3 H8bvHBdJv/Tz6fm5UhSxd9uqjGwpZTe9Kq7m4Y2BTdkJH0H7EgI6Od2lqjKwZ+DYNnbk 3w38P8szvLY7FRfvasqW8tdK9DUFnNdIwZBUE= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.91.6 with SMTP id g6mr2518402wef.212.1257776146045; Mon, 09 Nov 2009 06:15:46 -0800 (PST) In-Reply-To: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> Date: Mon, 9 Nov 2009 09:15:46 -0500 X-Google-Sender-Auth: 38395e8913c7a91e Message-ID: <3c3e3fca0911090615g7a2dedb6x8a6a1ddf2aea2dd8@mail.gmail.com> From: William Herrin To: Pasi Sarolahti Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] API: which address to use X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:15:24 -0000 On Mon, Nov 9, 2009 at 8:42 AM, William Herrin wrote: > On Mon, Nov 9, 2009 at 5:49 AM, Pasi Sarolahti wrote: >> This problem was just discussed in the meeting. Could one possible solution >> to the getsockname semantics problem be to use a separate address family for >> multipath connections? It could be similarly structured to the traditional >> AF, but from the different AF the app would know the semantics are >> different. > > Not really, no. I'm going to back up the train on that one. I stand by what I said about getsockname, however specifying a PF_INETMP in the original socket call would be more appropriate than PF_INET or PF_INET6 if we intend multipath to be protocol family agnostic. It would also be a reasonable way for the app to signal to the stack whether it expects the use of multipath. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Mon Nov 9 07:29:15 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89EA3A69A1 for ; Mon, 9 Nov 2009 07:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bifZt5aHuMv for ; Mon, 9 Nov 2009 07:29:14 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 7E94F3A692E for ; Mon, 9 Nov 2009 07:29:14 -0800 (PST) Received: by ewy3 with SMTP id 3so3215703ewy.37 for ; Mon, 09 Nov 2009 07:29:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=l75p4hwDEXIOyr/sO9v7q+VZBHTJgpFR7RY8/20xktc=; b=pdj5k1zIfofri903PUfhJwtnTzQxqiMroTXeLncP9oj5JkutNKkNWam7sdaVH7C8zH EWSFLHZMf8BYBWtVdYrvgf+8NUNrfo9w0FLCHgoMaiSx4gzvcorQtAF6tleU6K0ItOPL 8R3Yte9dA62Cd4z+LBEy7ptVO7jB5upOEGPAw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=HpoWP86d0t+ZHKgIa+ziFWHx/Rdf4HKgccsm4evRk0OUMpP1hfskfCPjgDYwsYhZtB ytinVW+mB0CKI2Mxe8SK9S88G2V/GQSLilUTN8FHKDTzxuHF63ECfV3+BEyRLqGqzxZ0 FYWXJbjh6sWiAwspUqOv/lD7CEGtIYxOE5exM= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.89.8 with SMTP id b8mr996393wef.180.1257780575864; Mon, 09 Nov 2009 07:29:35 -0800 (PST) Date: Mon, 9 Nov 2009 10:29:35 -0500 X-Google-Sender-Auth: 1d554b8fbb8617a8 Message-ID: <3c3e3fca0911090729x6cc32fcds4e656bc677a4856c@mail.gmail.com> From: William Herrin To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] thoughts on compatibility mode X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:29:15 -0000 Hi folks, Some thoughts on compatibility mode and the API for legacy apps that aren't aware of multipath TCP: Should probably pick a default behavior but punt the final decision to the operator. He's the one in a position to know for sure whether multipath will work OK for a particular system or application. Should probably have a system default and allow it to be overridden by an environment variable that the API checks during a socket() call. MULTIPATHTCP=DISABLED MULTIPATHTCP=ENABLED MULTIPATHTCP=COMPATIBILE MULTIPATHTCP=COMPATIBILETRY MULTIPATHTCP=COMPATIBILELIE DISABLED - multipath TCP will not be used, even by applications which are built to the new API. ENABLED - multipath TCP will be used by the apps which are built to the new API. Legacy apps will not attempt multipath TCP. COMPATIBLE - all PF_INET and PF_INET6 TCP sockets (legacy apps) are also eligible to use multipath TCP, although binding a specific local address will implicitly disable it. The API uses the multipath semantics, so getsockname() and getpeername() return EMULTIPATH and accept() does not return an IP address in the sockaddr structure. COMPATIBILETRY - all PF_INET and PF_INET6 TCP sockets are eligible. accept(), getsockname() and getpeername() will return the address of the oldest active subflow whose semantics are compatible with the socket's declared address domain. If there are no such subflows, COMPATIBILETRY will act like COMPATIBILELIE. COMPATIBILELIE - all PF_INET and PF_INET6 TCP sockets are eligible. accept(), getsockname() and getpeername() will return a non-routeable IANA-assigned address whose meaning is defined as "you asked a question multipath TCP can't reliably answer." Then when folks query google for why "255.255.255.1" shows up in their logs, they'll get a bunch of documents about multipath TCP and legacy servers. Regardless of the environment variable setting, apps built to the new API will use the new API semantics. Comments? Criticisms? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lars.eggert@nokia.com Mon Nov 9 16:43:04 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B16D3A6908; Mon, 9 Nov 2009 16:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGKTUIsxkbxA; Mon, 9 Nov 2009 16:43:03 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 396243A68B3; Mon, 9 Nov 2009 16:43:03 -0800 (PST) Received: from host-24-27.meeting.ietf.org (host-24-27.meeting.ietf.org [133.93.24.27]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nAA0hHjv098744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Nov 2009 02:43:21 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-9-333722617; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4AF8945F.2010105@ismailov.eu> Date: Tue, 10 Nov 2009 09:43:16 +0900 Message-Id: References: <4AF8945F.2010105@ismailov.eu> To: Yuri Ismailov X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 10 Nov 2009 02:43:23 +0200 (EET) Cc: "multipathtcp@ietf.org Mailing List" , mif@ietf.org Subject: Re: [multipathtcp] [mif] The point about multiple listening sockets at the client side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:43:04 -0000 --Apple-Mail-9-333722617 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I think you made this comment at the mike in MPTCP, so you probably want = to follow up on this on the MPTCP list. Lars On 2009-11-10, at 7:14, Yuri Ismailov wrote: > Hi all, > I've got a request to make this point on the list. It might be just = the > lack of my understanding and there is no any issue about that. > The simple scenario below: > A client with let's say 3 interfaces connects to a server through one = of > them for http download. > Server decides to use all three interfaces at the client side. > My question was if the client should open listening sockets for > accepting server initiated connections over other interfaces? >=20 > Regards > Yuri >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail-9-333722617 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTExMDAwNDMxN1owIwYJKoZIhvcNAQkEMRYEFLky8gsHNRUkBX2tfCWbRoQ44TVuMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCGtQV13fH+NFfUs4ggeV5JXfl9ON+19+Lgig1j8Gn6nmkjyjjfXOhXmRj9HFp2TL5BcI2N RAOOytooqMv1XySxep7wcYOuauFEy3pjGI5assTxQiuFy+L1IoHlHFJWFFWo7UP6bPQlDKPb9jfu qvB0pcwzoyvGbTZNkkZFXmuku33FG3SNs5PSwdQmZOJ2KD6Khmxc9lw4kVFBnvzoTn/bAQ8RiVCa FCXDdSyA/MrfucuZIsfeJjfvkI/kVj94WeX6kH4IOTvua55Tdkgv6yCeu6h2zVdqKD85s4mA2gJu QtPE1ZlaDz8IwH82joLuvjgmPCEqepgvXCXxLFSv332CAAAAAAAA --Apple-Mail-9-333722617-- From touch@ISI.EDU Mon Nov 9 16:43:34 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A3E3A69A4 for ; Mon, 9 Nov 2009 16:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDqaQ0rzKLqm for ; Mon, 9 Nov 2009 16:43:33 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 3FF8B3A6999 for ; Mon, 9 Nov 2009 16:43:33 -0800 (PST) Received: from [133.93.24.140] (host-24-140.meeting.ietf.org [133.93.24.140]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nAA0gsW6019677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Nov 2009 16:42:56 -0800 (PST) Message-ID: <4AF8B70E.90908@isi.edu> Date: Mon, 09 Nov 2009 16:42:54 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: William Herrin References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> <4AF09EA5.9030308@isi.edu> <3c3e3fca0911041219o5ddea192h297afa82882992e3@mail.gmail.com> In-Reply-To: <3c3e3fca0911041219o5ddea192h297afa82882992e3@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nAA0gsW6019677 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:43:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Bill, Sorry; this appears to have found a dusty corner of my mailbox. Here's a late reply... William Herrin wrote: > On Tue, Nov 3, 2009 at 5:20 PM, Joe Touch wrote: >> TCP negotiates all options during the SYN - that's the only 'handshake' >> there is. TCP does not define option negotiation after connection >> establishment. >> >> I.e., you can decide to start the separate connections later, but you >> need to negotiate support for the option during the SYN. > > Hi Joe, > > I assume that's a convention rather than a hard protocol requirement. > Something previous folks working in the space have deemed a "wise > idea" rather than a "all these things will break if we don't" kind of > thing, yes? It's an artifact of how TCP works. > Is there a good discussion on this somewhere so I can read up on the > rationale that brought it into being? Since it's an artifact, I don't think there is. The issue is that unknown options are ignored (as per RFC1122). The only time when you can find out if an option is supported in a way that you know will preceded all other segments is to put it in the SYN. If you put it in a later segment, you don't know when the segment will be received. Here's the problem, when A sends to B (assuming the connection is already open): A sends segment #223 with option X presuming this is the first segment A sends with option X Does A stop sending segments beyond 223 until option X is ACK'd? This violates window processing. If A sends segment 224 with option X, and B receives segment 224 before 223, it MUST ignore option X. So you can't put in a new option that has a required effect or is confirmed; there's no way to 'stop the stream' until the endpoints sync. The only times the endpoints sync is during the SYN. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkr4tw4ACgkQE5f5cImnZrtwUQCePEad3ORuBWIHvD4BX60FbwIC k2QAnAm1YF4AQj0C627K0T58UMmH/Po+ =w476 -----END PGP SIGNATURE----- From yuri@ismailov.eu Mon Nov 9 16:49:17 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5451028C28C for ; Mon, 9 Nov 2009 16:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1Mwbrtusf1C for ; Mon, 9 Nov 2009 16:49:16 -0800 (PST) Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.12]) by core3.amsl.com (Postfix) with ESMTP id 80B8228C278 for ; Mon, 9 Nov 2009 16:49:16 -0800 (PST) Received: from [133.93.19.5] (host-19-5.meeting.ietf.org [133.93.19.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id 7A26B576A94 for ; Tue, 10 Nov 2009 01:49:42 +0100 (CET) Message-ID: <4AF8B8A5.4040602@ismailov.eu> Date: Tue, 10 Nov 2009 01:49:41 +0100 From: Yuri Ismailov User-Agent: Thunderbird 2.0.0.23 (X11/20091002) MIME-Version: 1.0 To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] The point about multiple listening sockets at the client side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:49:17 -0000 Hi all, I've got a request to make this point on the list. It might be just the lack of my understanding and there is no any issue around that. The simple scenario below: A client with let's say 3 interfaces connects to a server through one of them for http download. Server decides to use all three interfaces at the client side. My question was if the client should open listening sockets for accepting server initiated connections over other interfaces? Regards Yuri From alan.ford@roke.co.uk Mon Nov 9 16:58:22 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B883A69DE for ; Mon, 9 Nov 2009 16:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2PI1AixWWev for ; Mon, 9 Nov 2009 16:58:21 -0800 (PST) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id 3BBB03A6959 for ; Mon, 9 Nov 2009 16:58:21 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nAA0wfLM028720 for ; Tue, 10 Nov 2009 00:58:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: AFDK BIMM Bq1V CfPX Cmad C4Ji Dz0u D1I3 EMFk FLYA Fb1W FvAe F7iW GR48 GyrJ G426; 1; bQB1AGwAdABpAHAAYQB0AGgAdABjAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {3C708A4D-9708-4BDE-8384-338C3C6B187F}; YQBsAGEAbgAuAGYAbwByAGQAQAByAG8AawBlAC4AYwBvAC4AdQBrAA==; Tue, 10 Nov 2009 00:58:48 GMT; TwBwAHQAaQBvAG4AcwAgAG8AcgAgAFAAYQB5AGwAbwBhAGQAPwA= x-cr-puzzleid: {3C708A4D-9708-4BDE-8384-338C3C6B187F} Content-class: urn:content-classes:message Date: Tue, 10 Nov 2009 00:58:48 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Options or Payload? Thread-Index: AcphoPYqM13XFcsoT3yDBuE0UMQEPw== From: "Ford, Alan" To: X-roke-co-uk-MailScanner-ID: nAA0wfLM028720 X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Subject: [multipathtcp] Options or Payload? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:58:22 -0000 Hi all, One of the big issues to be raised during yesterday's MPTCP session was the question of whether TCP Options are really the right place to be doing this. This is not the first time this has come up but deserves further exploration. Specifically, instead of doing this with TCP Options, the same instructions could be included in the payload. Similar to TLS, the data could be chunked and each chunk has a data sequence and length header. These can be interspersed with control blocks to signal addresses, security of joining subflows to connections, and connection close. A simple 2-octet TCP option would still be used in the initial SYN to signal MPTCP capability. This has the benefit that it would allow the signalling to have reliability, and we wouldn't be hit with option space limits, and thus be potentially able to do better security algorithms. It would also give us greater freedom in signals for future extensibility (for example, if we wanted to signal ports for additional subflows, not just addresses). On the downside, there may be cases where this could confuse middleboxes, e.g. expecting HTTP on port 80 and finding this kind of data instead. However, since a TCP option would be used at the start to identify capability, if this were dropped by a middlebox/proxy then MPTCP would not be used. What do people think is the best approach? Regards, Alan From alan.ford@roke.co.uk Mon Nov 9 17:06:06 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6693A69F5 for ; Mon, 9 Nov 2009 17:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqCVSSUu4-5G for ; Mon, 9 Nov 2009 17:06:05 -0800 (PST) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id 4A1783A69F2 for ; Mon, 9 Nov 2009 17:06:04 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nAA16Oo3029342; Tue, 10 Nov 2009 01:06:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 01:06:32 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <4AF8B8A5.4040602@ismailov.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] The point about multiple listening sockets at theclient side Thread-Index: Acphn8m32o0zihtfT7KRtvMq0jbVfQAAcq2w References: <4AF8B8A5.4040602@ismailov.eu> From: "Ford, Alan" To: "Yuri Ismailov" X-roke-co-uk-MailScanner-ID: nAA16Oo3029342 X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] The point about multiple listening sockets at theclient side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:06:06 -0000 Hi Yuri, The client (in terms of software) does not need to open listening sockets in this case. But the MPTCP stack itself will be listening on all interfaces for potential incoming subflows from the server, which when initiated are joined to the existing connection. The application does not need to do anything for this to happen (but if an extended API were in use it could, for example, have callbacks to be informed). Regards, Alan > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On > Behalf Of Yuri Ismailov > Sent: 10 November 2009 00:50 > To: multipathtcp@ietf.org > Subject: [multipathtcp] The point about multiple listening sockets at > theclient side >=20 > Hi all, > I've got a request to make this point on the list. It might be just the > lack of my understanding and there is no any issue around that. > The simple scenario below: > A client with let's say 3 interfaces connects to a server through one of > them for http download. > Server decides to use all three interfaces at the client side. > My question was if the client should open listening sockets for > accepting server initiated connections over other interfaces? >=20 > Regards > Yuri >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nishida@sfc.wide.ad.jp Mon Nov 9 17:35:01 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9F53A67A2 for ; Mon, 9 Nov 2009 17:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.042 X-Spam-Level: * X-Spam-Status: No, score=1.042 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2UVFr9aqbkh for ; Mon, 9 Nov 2009 17:35:00 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id EBDE23A69DA for ; Mon, 9 Nov 2009 17:34:59 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id E2FE94C0BC; Tue, 10 Nov 2009 10:35:22 +0900 (JST) Date: Tue, 10 Nov 2009 10:35:22 +0900 (JST) Message-Id: <20091110.103522.15256464.nishida@sfc.wide.ad.jp> To: alan.ford@roke.co.uk From: Yoshifumi Nishida In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Options or Payload? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:35:01 -0000 Hello, How about having a simple option which indicates the offset for real tcp payload? For example, if mptcp packets conveys 10 bytes control info in the payload, set offset to 10 in the option. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: "Ford, Alan" Subject: [multipathtcp] Options or Payload? Date: Tue, 10 Nov 2009 00:58:48 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> > Hi all, > > One of the big issues to be raised during yesterday's MPTCP session was > the question of whether TCP Options are really the right place to be > doing this. This is not the first time this has come up but deserves > further exploration. > > Specifically, instead of doing this with TCP Options, the same > instructions could be included in the payload. Similar to TLS, the data > could be chunked and each chunk has a data sequence and length header. > These can be interspersed with control blocks to signal addresses, > security of joining subflows to connections, and connection close. A > simple 2-octet TCP option would still be used in the initial SYN to > signal MPTCP capability. > > This has the benefit that it would allow the signalling to have > reliability, and we wouldn't be hit with option space limits, and thus > be potentially able to do better security algorithms. It would also give > us greater freedom in signals for future extensibility (for example, if > we wanted to signal ports for additional subflows, not just addresses). > > On the downside, there may be cases where this could confuse > middleboxes, e.g. expecting HTTP on port 80 and finding this kind of > data instead. However, since a TCP option would be used at the start to > identify capability, if this were dropped by a middlebox/proxy then > MPTCP would not be used. > > What do people think is the best approach? > > Regards, > Alan > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From alan.ford@roke.co.uk Mon Nov 9 17:52:20 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF293A684C for ; Mon, 9 Nov 2009 17:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QPuDg-OocYr for ; Mon, 9 Nov 2009 17:52:19 -0800 (PST) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id 2E0BE3A67D3 for ; Mon, 9 Nov 2009 17:52:19 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nAA1qcWE003357; Tue, 10 Nov 2009 01:52:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 01:52:44 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7BB56@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <20091110.103522.15256464.nishida@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Options or Payload? Thread-Index: AcphpipTNgChHF0vTPCqCfg7zAMUzAAAVLQQ References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> <20091110.103522.15256464.nishida@sfc.wide.ad.jp> From: "Ford, Alan" To: "Yoshifumi Nishida" X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Options or Payload? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:52:20 -0000 We had considered that, however the main reason against this was whether certain middleboxes would split and coalesce TCP payloads thus breaking the placement of the extended options - the TCP payload is essentially no longer a continuous stream. Wes Eddy proposed a "Long Options Option" (http://tools.ietf.org/id/draft-eddy-tcp-loo-04.txt) which seemed to be a possible way of doing a very similar thing, by negotiating to ensure that long options would work along a path. Although, this draft is now expired, and I'm not sure why it was dropped. Anyone know? Regards, Alan > -----Original Message----- > From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > Sent: 10 November 2009 01:35 > To: Ford, Alan > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] Options or Payload? >=20 >=20 > Hello, > How about having a simple option which indicates the offset for real tcp > payload? > For example, if mptcp packets conveys 10 bytes control info in the payload, > set > offset to 10 in the option. >=20 > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp >=20 > From: "Ford, Alan" > Subject: [multipathtcp] Options or Payload? > Date: Tue, 10 Nov 2009 00:58:48 -0000 > Message-ID: > <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> >=20 > > Hi all, > > > > One of the big issues to be raised during yesterday's MPTCP session was > > the question of whether TCP Options are really the right place to be > > doing this. This is not the first time this has come up but deserves > > further exploration. > > > > Specifically, instead of doing this with TCP Options, the same > > instructions could be included in the payload. Similar to TLS, the data > > could be chunked and each chunk has a data sequence and length header. > > These can be interspersed with control blocks to signal addresses, > > security of joining subflows to connections, and connection close. A > > simple 2-octet TCP option would still be used in the initial SYN to > > signal MPTCP capability. > > > > This has the benefit that it would allow the signalling to have > > reliability, and we wouldn't be hit with option space limits, and thus > > be potentially able to do better security algorithms. It would also give > > us greater freedom in signals for future extensibility (for example, if > > we wanted to signal ports for additional subflows, not just addresses). > > > > On the downside, there may be cases where this could confuse > > middleboxes, e.g. expecting HTTP on port 80 and finding this kind of > > data instead. However, since a TCP option would be used at the start to > > identify capability, if this were dropped by a middlebox/proxy then > > MPTCP would not be used. > > > > What do people think is the best approach? > > > > Regards, > > Alan > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp From touch@ISI.EDU Mon Nov 9 17:55:41 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7449F3A6A42 for ; Mon, 9 Nov 2009 17:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVBfT7yQ84Yo for ; Mon, 9 Nov 2009 17:55:40 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 179EB3A69E2 for ; Mon, 9 Nov 2009 17:55:21 -0800 (PST) Received: from [133.93.24.140] (host-24-140.meeting.ietf.org [133.93.24.140]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nAA1sYpG005605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Nov 2009 17:54:36 -0800 (PST) Message-ID: <4AF8C7D9.5020506@isi.edu> Date: Mon, 09 Nov 2009 17:54:33 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yoshifumi Nishida References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> <20091110.103522.15256464.nishida@sfc.wide.ad.jp> In-Reply-To: <20091110.103522.15256464.nishida@sfc.wide.ad.jp> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nAA1sYpG005605 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Options or Payload? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:55:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This has been tried in various places in TCP to extend the options space. It'd be useful to take a look at that work as context. Joe Yoshifumi Nishida wrote: > Hello, > How about having a simple option which indicates the offset for real tcp payload? > For example, if mptcp packets conveys 10 bytes control info in the payload, set > offset to 10 in the option. > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > From: "Ford, Alan" > Subject: [multipathtcp] Options or Payload? > Date: Tue, 10 Nov 2009 00:58:48 -0000 > Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> > > > Hi all, > > > > One of the big issues to be raised during yesterday's MPTCP session was > > the question of whether TCP Options are really the right place to be > > doing this. This is not the first time this has come up but deserves > > further exploration. > > > > Specifically, instead of doing this with TCP Options, the same > > instructions could be included in the payload. Similar to TLS, the data > > could be chunked and each chunk has a data sequence and length header. > > These can be interspersed with control blocks to signal addresses, > > security of joining subflows to connections, and connection close. A > > simple 2-octet TCP option would still be used in the initial SYN to > > signal MPTCP capability. > > > > This has the benefit that it would allow the signalling to have > > reliability, and we wouldn't be hit with option space limits, and thus > > be potentially able to do better security algorithms. It would also give > > us greater freedom in signals for future extensibility (for example, if > > we wanted to signal ports for additional subflows, not just addresses). > > > > On the downside, there may be cases where this could confuse > > middleboxes, e.g. expecting HTTP on port 80 and finding this kind of > > data instead. However, since a TCP option would be used at the start to > > identify capability, if this were dropped by a middlebox/proxy then > > MPTCP would not be used. > > > > What do people think is the best approach? > > > > Regards, > > Alan > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkr4x9kACgkQE5f5cImnZrvWAwCghDjI91tfGfNVoizvAD7u8CA1 DF0AoJa7A4tFzxvsrjYKiVRIJIuF96CD =dJcd -----END PGP SIGNATURE----- From wherrin@gmail.com Mon Nov 9 18:37:49 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74AF23A6807 for ; Mon, 9 Nov 2009 18:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baK0Umb5b7m2 for ; Mon, 9 Nov 2009 18:37:48 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 533FF3A6405 for ; Mon, 9 Nov 2009 18:37:48 -0800 (PST) Received: by ewy3 with SMTP id 3so3825423ewy.37 for ; Mon, 09 Nov 2009 18:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=IGAbqiYR5Q4DYZSDx1PNj7KPRStg/oV4qcpPehGQQts=; b=WJhvOXR5y6y8KgBfhE9B48ADa00jZ7/Z8sSUzzwMd2dmaGu0IYNZF7UHvT7t2QqB1W kc+U9JN1cLVWw851z7SFfygJPi7AbcZc/Yw24sl32Aafh7Cwm1L+v6Zy/FrLXD+MxDKg W3jsDcx6WDdajcaociL6gmWPrdCTIwGWxvSRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=KQgcjZsJrOMvXTk6AKWl+QGClvQu4Z3eTU77Snd6x0MGuHT8Fz3JIRAJKP6zRTnhr5 avVTqMl5hU82u2GIBYTKgMB4hyU9cXSjAeSJ4cC8GyWdaYoGYqlNmsfqWYECJ06cldsQ bdblbZmTbW4o46mYoQBfwCxxkWHvf7B3B+lyI= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.85.210 with SMTP id u60mr114666wee.226.1257820690149; Mon, 09 Nov 2009 18:38:10 -0800 (PST) In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> Date: Mon, 9 Nov 2009 21:38:10 -0500 X-Google-Sender-Auth: ae9ea4c5c441ec37 Message-ID: <3c3e3fca0911091838w6620d955m68074495027d7c5d@mail.gmail.com> From: William Herrin To: "Ford, Alan" Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Options or Payload? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:37:49 -0000 On Mon, Nov 9, 2009 at 7:58 PM, Ford, Alan wrote: > One of the big issues to be raised during yesterday's MPTCP session was > the question of whether TCP Options are really the right place to be > doing this. > Specifically, instead of doing this with TCP Options, the same > instructions could be included in the payload. > What do people think is the best approach? Hi Alan, There isn't enough room in the options to transfer an encryption key, a hostname or other likely methods of authenticating the offered addresses. There isn't really enough to transfer all of the candidate addresses either, not once we start talking v4/v6 agnosticism, so we'd have to send adds and deletes instead of updates. When I tinkered with a throwaway concept (http://bill.herrin.us/network/multipathtcp2.html) I pretty quickly moved to the data section because trying to keep it all in the options got funky fast. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Michael.Scharf@alcatel-lucent.com Mon Nov 9 18:48:33 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072B23A681B for ; Mon, 9 Nov 2009 18:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIYCnW-Roakp for ; Mon, 9 Nov 2009 18:48:32 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id EB0B73A6405 for ; Mon, 9 Nov 2009 18:48:31 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn2.rcs.de.alcatel-lucent.com [149.204.60.99]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id nAA2mtv9015558; Tue, 10 Nov 2009 03:48:55 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 03:48:53 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C01B6AC34@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Options or Payload? Thread-Index: AcphoPYqM13XFcsoT3yDBuE0UMQEPwADQ09A References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> From: "SCHARF, Michael" To: "Ford, Alan" , X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Subject: Re: [multipathtcp] Options or Payload? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:48:33 -0000 Hi all, > Specifically, instead of doing this with TCP Options, the=20 > same instructions could be included in the payload. Similar=20 > to TLS, the data could be chunked and each chunk has a data=20 > sequence and length header. > These can be interspersed with control blocks to signal=20 > addresses, security of joining subflows to connections, and=20 > connection close. A simple 2-octet TCP option would still be=20 > used in the initial SYN to signal MPTCP capability. >=20 > This has the benefit that it would allow the signalling to=20 > have reliability, and we wouldn't be hit with option space=20 > limits, and thus be potentially able to do better security=20 > algorithms. It would also give us greater freedom in signals=20 > for future extensibility (for example, if we wanted to signal=20 > ports for additional subflows, not just addresses). Maybe there is a further advantage: I could imagine that payload chunks could simplify the MPTCP stack design. Sporadically adding TCP options other than SACK could result a mess in a real stack (correct MSS calculation, dealing with segmentation offloading, etc.). At least I recall that we had such problems in our Quick-Start TCP implementation in Linux. Michael From touch@ISI.EDU Mon Nov 9 19:03:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5F03A68F3 for ; Mon, 9 Nov 2009 19:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ggUt5NiHz+f for ; Mon, 9 Nov 2009 19:03:58 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1C1883A68E6 for ; Mon, 9 Nov 2009 19:03:58 -0800 (PST) Received: from [133.93.113.124] (host-113-124.meeting.ietf.org [133.93.113.124]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAA349oX010174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Nov 2009 19:04:12 -0800 (PST) Message-ID: <4AF8D828.1070404@isi.edu> Date: Mon, 09 Nov 2009 19:04:08 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Ford, Alan" References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> <20091110.103522.15256464.nishida@sfc.wide.ad.jp> <2181C5F19DD0254692452BFF3EAF1D6808D7BB56@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808D7BB56@rsys005a.comm.ad.roke.co.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Options or Payload? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:03:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ford, Alan wrote: > We had considered that, however the main reason against this was whether > certain middleboxes would split and coalesce TCP payloads thus breaking > the placement of the extended options - the TCP payload is essentially > no longer a continuous stream. > > Wes Eddy proposed a "Long Options Option" > (http://tools.ietf.org/id/draft-eddy-tcp-loo-04.txt) which seemed to be > a possible way of doing a very similar thing, by negotiating to ensure > that long options would work along a path. Although, this draft is now > expired, and I'm not sure why it was dropped. Anyone know? Same problems. Joe >> -----Original Message----- >> From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] >> Sent: 10 November 2009 01:35 >> To: Ford, Alan >> Cc: multipathtcp@ietf.org >> Subject: Re: [multipathtcp] Options or Payload? >> >> >> Hello, >> How about having a simple option which indicates the offset for real > tcp >> payload? >> For example, if mptcp packets conveys 10 bytes control info in the > payload, >> set >> offset to 10 in the option. >> >> Thanks, >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >> >> From: "Ford, Alan" >> Subject: [multipathtcp] Options or Payload? >> Date: Tue, 10 Nov 2009 00:58:48 -0000 >> Message-ID: >> <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> >> >> > Hi all, >> > >> > One of the big issues to be raised during yesterday's MPTCP session > was >> > the question of whether TCP Options are really the right place to > be >> > doing this. This is not the first time this has come up but > deserves >> > further exploration. >> > >> > Specifically, instead of doing this with TCP Options, the same >> > instructions could be included in the payload. Similar to TLS, the > data >> > could be chunked and each chunk has a data sequence and length > header. >> > These can be interspersed with control blocks to signal addresses, >> > security of joining subflows to connections, and connection close. > A >> > simple 2-octet TCP option would still be used in the initial SYN to >> > signal MPTCP capability. >> > >> > This has the benefit that it would allow the signalling to have >> > reliability, and we wouldn't be hit with option space limits, and > thus >> > be potentially able to do better security algorithms. It would also > give >> > us greater freedom in signals for future extensibility (for > example, if >> > we wanted to signal ports for additional subflows, not just > addresses). >> > >> > On the downside, there may be cases where this could confuse >> > middleboxes, e.g. expecting HTTP on port 80 and finding this kind > of >> > data instead. However, since a TCP option would be used at the > start to >> > identify capability, if this were dropped by a middlebox/proxy then >> > MPTCP would not be used. >> > >> > What do people think is the best approach? >> > >> > Regards, >> > Alan >> > >> > _______________________________________________ >> > multipathtcp mailing list >> > multipathtcp@ietf.org >> > https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkr42CgACgkQE5f5cImnZrsyRwCg89PYtNKtA6LsK2vEGFB9sXJy NMwAmQHJ5C8MkXkTQqFdAurtj4ayeKBA =IEs8 -----END PGP SIGNATURE----- From wherrin@gmail.com Mon Nov 9 19:18:14 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7FC3A6824 for ; Mon, 9 Nov 2009 19:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXJaUwlb8UyC for ; Mon, 9 Nov 2009 19:18:13 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 4FD403A67B0 for ; Mon, 9 Nov 2009 19:18:13 -0800 (PST) Received: by ewy3 with SMTP id 3so3847537ewy.37 for ; Mon, 09 Nov 2009 19:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=9pq6Ht10gA0VVIZYqVKnNzicgXMe6xhNxoAZ5HDQvPQ=; b=p0wGI675/YYDI1ITkdEsOem4++fASXggwjfV0injj7gawH0sX4DWuvKXlQby2GkrSv iBrEd4ttwcyH2S/gkUltf19tIH7/Mk1RDVWbuF8N4VEWACBP1dVmcgbfchEOXH083VS9 px5ArOiVgh6Ql7t3Jv0rL4jh7zqxBWLjBBnl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Kb+kS4VDiS0yr0u86sHsujwABPUWqYjFkWOZgcvFZnIADH9PVVruULZYgVQQTfMk38 /LDNo3dFUidXaSuoExJ8Dv46Q/eUGnoqfY5XK4sJ6awH6kQtrOH1XJ8KUDh7wEmLqYdY qnUK4rNdeHZRyhBUcjzEK/tcADycxMuwiuXOc= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.93.18 with SMTP id k18mr2840490wef.218.1257823114139; Mon, 09 Nov 2009 19:18:34 -0800 (PST) In-Reply-To: <4AF8B70E.90908@isi.edu> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> <4AF09EA5.9030308@isi.edu> <3c3e3fca0911041219o5ddea192h297afa82882992e3@mail.gmail.com> <4AF8B70E.90908@isi.edu> Date: Mon, 9 Nov 2009 22:18:33 -0500 X-Google-Sender-Auth: 3ea90008992c63d8 Message-ID: <3c3e3fca0911091918l27562923j5b1b7fd15461c04f@mail.gmail.com> From: William Herrin To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:18:14 -0000 On Mon, Nov 9, 2009 at 7:42 PM, Joe Touch wrote: >> Is there a good discussion on this somewhere so I can read up on the >> rationale that brought it into being? > > Since it's an artifact, I don't think there is. The issue is that > unknown options are ignored (as per RFC1122). The only time when you can > find out if an option is supported in a way that you know will preceded > all other segments is to put it in the SYN. > > If you put it in a later segment, you don't know when the segment will > be received. Here's the problem, when A sends to B (assuming the > connection is already open): > > =A0 =A0 =A0 =A0A sends segment #223 with option X > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0presuming this is the first segment A send= s > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0with option X > > Does A stop sending segments beyond 223 until option X is ACK'd? This > violates window processing. If A sends segment 224 with option X, and B > receives segment 224 before 223, it MUST ignore option X. Hi Joe, I'm missing something here. I would have expected TCP to hold segment 224 and not process it (except perhaps for selective ack or to retransmit 222's ack) until after 223 had been received and processed. In other words, unless the option was defined to be unordered, I'd expect the receiver to process it in the same order as the packet sequence numbers. That's not how TCP functions? The options are required to be processed in order received rather than ordered by sequence? Or is it just that all options to date have been designed to be processed in the order received? I can see the point of doing that; I'm just trying to get a scope on the issue. > So you can't put in a new option that has a required effect or is > confirmed; there's no way to 'stop the stream' until the endpoints sync. > The only times the endpoints sync is during the SYN. My first thought would be a three-part handshake. Request option X, option X accepted, option X in effect. Requires that the receiver understand that order is important after sending X accepted though. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From touch@ISI.EDU Mon Nov 9 19:27:31 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7633A6824 for ; Mon, 9 Nov 2009 19:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oC4gWK6ds2G for ; Mon, 9 Nov 2009 19:27:30 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E9ED23A681B for ; Mon, 9 Nov 2009 19:27:30 -0800 (PST) Received: from [133.93.113.124] (host-113-124.meeting.ietf.org [133.93.113.124]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAA3RajR016555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Nov 2009 19:27:39 -0800 (PST) Message-ID: <4AF8DDA7.9030108@isi.edu> Date: Mon, 09 Nov 2009 19:27:35 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: William Herrin References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> <4AF09EA5.9030308@isi.edu> <3c3e3fca0911041219o5ddea192h297afa82882992e3@mail.gmail.com> <4AF8B70E.90908@isi.edu> <3c3e3fca0911091918l27562923j5b1b7fd15461c04f@mail.gmail.com> In-Reply-To: <3c3e3fca0911091918l27562923j5b1b7fd15461c04f@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:27:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 William Herrin wrote: > On Mon, Nov 9, 2009 at 7:42 PM, Joe Touch wrote: >>> Is there a good discussion on this somewhere so I can read up on the >>> rationale that brought it into being? >> Since it's an artifact, I don't think there is. The issue is that >> unknown options are ignored (as per RFC1122). The only time when you can >> find out if an option is supported in a way that you know will preceded >> all other segments is to put it in the SYN. >> >> If you put it in a later segment, you don't know when the segment will >> be received. Here's the problem, when A sends to B (assuming the >> connection is already open): >> >> A sends segment #223 with option X >> presuming this is the first segment A sends >> with option X >> >> Does A stop sending segments beyond 223 until option X is ACK'd? This >> violates window processing. If A sends segment 224 with option X, and B >> receives segment 224 before 223, it MUST ignore option X. > > Hi Joe, > > I'm missing something here. I would have expected TCP to hold segment > 224 and not process it (except perhaps for selective ack or to > retransmit 222's ack) until after 223 had been received and processed. > In other words, unless the option was defined to be unordered, I'd > expect the receiver to process it in the same order as the packet > sequence numbers. That requires that options are processed on the data after ordered, as you note. However, TCP is an unordered protocol. So here's the catch. Let's say you introduce option X in segment 224. - - can you send it in 225, or does the protocol come to a grinding halt? If this is the first option, you need to ACK it. But you can't ACK 225. So first, until everything up to 225 is ACKd, you can't send 226. And second, while that's happening the reciever can't ACK 225, because 224 might have an option that's incompatible with the one in 225. So the transmitter keeps sending 225, and the receiver keeps ignoring it. Ultimately, what you need is a separate sequence number space and retransmission mechanism for these options, and rules for how they tie to TCP's data path. That's a HUGE, non-backward compatible change to TCP. > That's not how TCP functions? The options are required to be processed > in order received rather than ordered by sequence? Yes. Options are part of the control plane, and that's processed when the segment is received - including ACKs. Data is passed up to the app after reordering - it's only data that is queued. > Or is it just that > all options to date have been designed to be processed in the order > received? I can see the point of doing that; I'm just trying to get a > scope on the issue. See above. Doing otherwise requires a sequence space that doesn't exist. >> So you can't put in a new option that has a required effect or is >> confirmed; there's no way to 'stop the stream' until the endpoints sync. >> The only times the endpoints sync is during the SYN. > > My first thought would be a three-part handshake. Request option X, > option X accepted, option X in effect. Requires that the receiver > understand that order is important after sending X accepted though. Right. How do you bury that handshake in an unordered, unreliable stream without halting it, though? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkr43acACgkQE5f5cImnZrvVLACg/kQ0SrBx8JEELMQWYpODzo8m vvQAoM+JpZ69JBm3IBP8BlVpWXKYh3gI =+Jxu -----END PGP SIGNATURE----- From pasi.sarolahti@iki.fi Mon Nov 9 21:01:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEFF3A6A27 for ; Mon, 9 Nov 2009 21:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIhIs8hcknCM for ; Mon, 9 Nov 2009 21:01:40 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id D20513A69DC for ; Mon, 9 Nov 2009 21:01:39 -0800 (PST) Received: from host-128-144.meeting.ietf.org (host-128-144.meeting.ietf.org [133.93.128.144]) by argo.otaverkko.fi (Postfix) with ESMTP id C4A5925ED11; Tue, 10 Nov 2009 07:02:04 +0200 (EET) Message-Id: From: Pasi Sarolahti To: William Herrin In-Reply-To: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 14:01:59 +0900 References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] API: which address to use X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:01:41 -0000 On Nov 9, 2009, at 10:42 PM, William Herrin wrote: > On Mon, Nov 9, 2009 at 5:49 AM, Pasi Sarolahti > wrote: >> This problem was just discussed in the meeting. Could one possible >> solution >> to the getsockname semantics problem be to use a separate address >> family for >> multipath connections? It could be similarly structured to the >> traditional >> AF, but from the different AF the app would know the semantics are >> different. > > Not really, no. > > Backwards compatibility is an issue, as you mentioned. So is a desire > to be able to use both IPv4 and IPv6 paths in a single multipath TCP > connection. If it's a legacy app then it's expecting getsockname to > return the same address family that it used to initiate the socket. If > you provide something else you could open a path for buffer overflows > or other mischief. Ok, so there could be a non-backwards compatible way and a (pseudo)backwards compatible way. I don't think these had to be exclusive, and both could be supported at the same time. Non-backwards compatible version would be to use new AF_MULTIPATH, that would be an array of AF_INET and AF_INET6 entries. Of course that would need to be used consistently throughout the connection lifetime. gethostname and getpeername would return the current set of active addresses at local or remote end. bind() could use this to bind to several addresses at a time. connect() could use this to give more than one known destination addresses to connect to (although the MPTCP protocol logic may prevent the actual connect operation from happening simultaneously). gethostbyname might return several addresses from DNS in a single AF_MULTIPATH record, to be directly used by connect(AF_MULTIPATH), instead of needing to cycle through the addresses separately, as a traditional single-homed version would do. This would require modifications also elsewhere than TCP code, but that's what you get for having an API that exposes the IP address to the application and assumes only one address is in use at a time. The backwards compatible version could just return the oldest active address and hope nothing breaks on legacy apps. I don't know if this is better or worse choice than returning the first used address that might not exist anymore. Has it been specified anywhere that getsockname/getpeername should return same result through the connection lifetime? - Pasi From c.raiciu@cs.ucl.ac.uk Mon Nov 9 21:50:42 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737743A6899 for ; Mon, 9 Nov 2009 21:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcdYvfPzDu5b for ; Mon, 9 Nov 2009 21:50:41 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 4174428C0F0 for ; Mon, 9 Nov 2009 21:50:41 -0800 (PST) Received: from host-32-98.meeting.ietf.org ([133.93.32.98]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N7jX3-000DA8-B8; Tue, 10 Nov 2009 05:44:45 +0000 In-Reply-To: <4AF8B8A5.4040602@ismailov.eu> References: <4AF8B8A5.4040602@ismailov.eu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Tue, 10 Nov 2009 14:50:33 +0900 To: Yuri Ismailov X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] The point about multiple listening sockets at the client side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:50:42 -0000 Hi, Neither the server or the client need to open listening sockets for additional subflows. These subflows are demultiplexed using the connection token, so the port is not needed as a rendezvous point. Thus, any port can be put in the SYN packet - it does not matter (as long as the 5 tuple is unique for the two hosts - which it is, if the client of the subflow picks a port unused in the connection). Semantically this may seem a bit weird - but in fact its not. TCP semantics say that the client (i.e. the side doing the active open) can accept a SYN packet (n.b. not syn/ack, which it would get from a passive end upon receipt of syn) after it has sent his own SYN. This is to support simultaneous open, and effectively amounts to "accepting" a connection request without calling accept (the client calls connect). We can think of the multipath case as a natural extension of simultaneous open in TCP - that lasts the whole connection. Costin On 10 Nov 2009, at 09:49, Yuri Ismailov wrote: > Hi all, > I've got a request to make this point on the list. It might be just > the > lack of my understanding and there is no any issue around that. > The simple scenario below: > A client with let's say 3 interfaces connects to a server through > one of > them for http download. > Server decides to use all three interfaces at the client side. > My question was if the client should open listening sockets for > accepting server initiated connections over other interfaces? > > Regards > Yuri > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From wherrin@gmail.com Tue Nov 10 12:20:11 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747693A65A6 for ; Tue, 10 Nov 2009 12:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 892KYs6g+dyJ for ; Tue, 10 Nov 2009 12:20:10 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 58CC53A688F for ; Tue, 10 Nov 2009 12:20:10 -0800 (PST) Received: by ewy3 with SMTP id 3so440390ewy.37 for ; Tue, 10 Nov 2009 12:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=bOR5XG4Y6khMxqNd2JtKD4LGO8A8V4GJyhNeDDLt4pM=; b=tjhaTfgjc2Yo5K37FcNdWcEsny/deglI4jU2cESSr/hqrRxGueJ+SEuHIs8buPV6m4 3PCS5ntDXc4cU7XRtIDvH0ASAxAuURtIC0qtwagoizdheam8YFMmMNX3hYudoYhpfnr/ I3lptevIcPlMYwFZ3KvVPrxTqz+NuYsYJyLQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=I0AweyyOEs932n11PczX4VtQRcCkOr7CBiA1fpO6jqQp3H5Ssaq45zf14jwvuHixne gEmgF5fySl61MkhzjGXOhu7lPFhN9gLwT7Vh5fW4uuZRlrYgQ9ieYEeD0ipP+e2p1UX3 Ntg9/+QC5YOai+ibglm12PzDkZVTBke4mBapc= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.86.212 with SMTP id w62mr189520wee.131.1257884432782; Tue, 10 Nov 2009 12:20:32 -0800 (PST) In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> References: <4AF8B8A5.4040602@ismailov.eu> <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> Date: Tue, 10 Nov 2009 15:20:32 -0500 X-Google-Sender-Auth: fd4278c0ddf27e5e Message-ID: <3c3e3fca0911101220g55f84f79nf62526d8693d39fa@mail.gmail.com> From: William Herrin To: "Ford, Alan" Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] The point about multiple listening sockets at theclient side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:20:11 -0000 On Mon, Nov 9, 2009 at 8:06 PM, Ford, Alan wrote: > The client (in terms of software) does not need to open listening > sockets in this case. But the MPTCP stack itself will be listening on > all interfaces for potential incoming subflows from the server, which > when initiated are joined to the existing connection. The application > does not need to do anything for this to happen (but if an extended API > were in use it could, for example, have callbacks to be informed). Hi Alan, Two thoughts: 1. When the initiator (of the overall connection) tries to add a subflow, he'll want to use the same destination port number and a full syn-syn/ack-ack handshake to maximize the chances of getting through the acceptor's firewall unscathed. 2. When the acceptor tries to add a subflow, he best not offer a syn. The syn won't get through the initiator's firewall. Nor should it: a SYN packet to a non-multipath host would be interpreted as a plain connection attempt. One implication is that adding a subflow is an asymetric operation: the connection's initiator follows a different process than the acceptor. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Tue Nov 10 12:45:22 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4284C3A67E4 for ; Tue, 10 Nov 2009 12:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E77b4598qznT for ; Tue, 10 Nov 2009 12:45:21 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id E0FE63A690C for ; Tue, 10 Nov 2009 12:45:20 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so100398eyd.51 for ; Tue, 10 Nov 2009 12:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=Wq1ouUUyVpchucaoRBgCFkk6mFU7NTdvGpAWvU+7tVI=; b=fUBEZ61j/20lMkZqqp4NAJKOoQ5UEJL2lwLGpHAYu/hk9ejTHyOtZSCWmKUYdzXNVf GDm/kC17vbgLpU6mklqHYM24pWpc/TEDMN8yN8d/Evmv6ypbxqt7MaubREtxogNwID+p v/ynLOosUX7vJDIOSRYZvaMyZ1LVFaVqAbuGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=d/xAZU6FwfYAk98n8s0CgJEx72B2QolS2z/2ctqzA8WE1td9XBYzaml/sUnUJUb8wa RThgoRm1AOLagFN4Jo42Nf8f5D0s8fo2FJxokq4dviGdkmhisoZvAn1kHfI6g8dja8xN HEI3/GvdZCl6+jRdHwYiOPDYExK+ZWl2fU1F4= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.89.8 with SMTP id b8mr173227wef.180.1257885942653; Tue, 10 Nov 2009 12:45:42 -0800 (PST) In-Reply-To: <4AF8DDA7.9030108@isi.edu> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> <4AF09EA5.9030308@isi.edu> <3c3e3fca0911041219o5ddea192h297afa82882992e3@mail.gmail.com> <4AF8B70E.90908@isi.edu> <3c3e3fca0911091918l27562923j5b1b7fd15461c04f@mail.gmail.com> <4AF8DDA7.9030108@isi.edu> Date: Tue, 10 Nov 2009 15:45:42 -0500 X-Google-Sender-Auth: 68126215f049b44a Message-ID: <3c3e3fca0911101245y7db0aa21wab41a66834feef19@mail.gmail.com> From: William Herrin To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:45:22 -0000 On Mon, Nov 9, 2009 at 10:27 PM, Joe Touch wrote: > That requires that options are processed on the data after ordered, as > you note. However, TCP is an unordered protocol. > >> My first thought would be a three-part handshake. Request option X, >> option X accepted, option X in effect. Requires that the receiver >> understand that order is important after sending X accepted though. > > Right. How do you bury that handshake in an unordered, unreliable stream > without halting it, though? Hi Joe, How about a 4-step handshake like this: Request option X, option X accepted, option X in effect (1), option X in effect (2). When you receive X accepted, attach X1 to *every* outgoing packet until you get an ack for everything up to and including the first X1 packet. Then start sending X2 in every outgoing packet until you get an ack for any X2 packet. Then stop sending the X option on any packet that isn't a retransmission of one where X1 or X2 was sent. At the receiver end: until you receive a packet with X2, only packets with X1 or X2 have option X in effect. After you see any packet with X2, all subsequent packets have option X in effect regardless of the presence of X1 or X2. Nobody pauses. Options are processed in the order received. And you're dealing with pretty trivial state changes on each end. One concern that jumps to mind is if the receiver gets a late copy of an already received and acked segment where option X is not in effect. What will the receiver do with the late packet? Let me narrow that a bit: assuming option X does not affect the use of the TCP sequence number in any way, what will the receiver do with a late copy of an already received packet where it thinks X is in effect but in reality X was not requested? On the other hand, if option X has some other intrinsic value (such has holding the multipath TCP connection ID for middleboxes to decode) then you can just keep sending it in every packet which uses it for the remainder of the connection instead of the fancy handshake. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From touch@ISI.EDU Tue Nov 10 13:12:45 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A9C28C1EC for ; Tue, 10 Nov 2009 13:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlXaPiuSMkNV for ; Tue, 10 Nov 2009 13:12:44 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 88A523A68A2 for ; Tue, 10 Nov 2009 13:12:44 -0800 (PST) Received: from [133.93.113.124] (host-113-124.meeting.ietf.org [133.93.113.124]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAALCepD009972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Nov 2009 13:12:43 -0800 (PST) Message-ID: <4AF9D747.5080707@isi.edu> Date: Tue, 10 Nov 2009 13:12:39 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: William Herrin References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> <4AF09EA5.9030308@isi.edu> <3c3e3fca0911041219o5ddea192h297afa82882992e3@mail.gmail.com> <4AF8B70E.90908@isi.edu> <3c3e3fca0911091918l27562923j5b1b7fd15461c04f@mail.gmail.com> <4AF8DDA7.9030108@isi.edu> <3c3e3fca0911101245y7db0aa21wab41a66834feef19@mail.gmail.com> In-Reply-To: <3c3e3fca0911101245y7db0aa21wab41a66834feef19@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:12:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 William Herrin wrote: > On Mon, Nov 9, 2009 at 10:27 PM, Joe Touch wrote: >> That requires that options are processed on the data after ordered, as >> you note. However, TCP is an unordered protocol. >> >>> My first thought would be a three-part handshake. Request option X, >>> option X accepted, option X in effect. Requires that the receiver >>> understand that order is important after sending X accepted though. >> Right. How do you bury that handshake in an unordered, unreliable stream >> without halting it, though? > > Hi Joe, > > How about a 4-step handshake like this: > > Request option X, option X accepted, option X in effect (1), option X > in effect (2). > > When you receive X accepted, attach X1 to *every* outgoing packet > until you get an ack for everything up to and including the first X1 > packet. What happens to retransmitted packets that were first sent before you decided to set X? > Then start sending X2 in every outgoing packet until you get > an ack for any X2 packet. Then stop sending the X option on any packet > that isn't a retransmission of one where X1 or X2 was sent. > > At the receiver end: until you receive a packet with X2, only packets > with X1 or X2 have option X in effect. So now you have a problem. Some packets are handled as if option X is in effect, and some are not. These could arrive in any order. What if the option has something to do with the order in which the packets are ACKd? Or the order in which they're sent to the app? You now have essentially two separate data streams, so you need to reimplement buffering to handle the old stream as it was, and the new stream treats the option exchange as a SYN-SYN/ACK-ACK exchange. The issue is that the receiver cannot act on X until the handshake completes (it gets X2). None of the data with X1 in it can be processed until X2 is received. But this "processing" could mean ACKing too - you can't even ACK the data because the option could mean "ACK every four" or something like that. > After you see any packet with > X2, all subsequent packets have option X in effect regardless of the > presence of X1 or X2. Not packets sent before X was set at the source. Again, you have two separate streams now - the one before X, and the one after X2. The first is your current connection, which is essentially draining out. The second is your new connection - with X set - that is basically starting anew. At that point, it's going to be a LOT simpler to just treat this as a CLOSE and subsequent OPEN than to do this all inside a single connection. > Nobody pauses. Disagree - see above. > Options are processed in the order received. Disagree - see above. They can't be. > And you're > dealing with pretty trivial state changes on each end. Disagree - you now need another 11-state machine to talk about all the possible ways in which the "set X" operation can fail, and to avoid trying to negotiate another option while the first negotiation is going on. > One concern that jumps to mind is if the receiver gets a late copy of > an already received and acked segment where option X is not in effect. > What will the receiver do with the late packet? Let me narrow that a > bit: assuming option X does not affect the use of the TCP sequence > number in any way, what will the receiver do with a late copy of an > already received packet where it thinks X is in effect but in reality > X was not requested? I think at best that there would need to be a LOT of constraints on what the option could do. But I'm not sure there's a useful way even if that's true to make this work. > On the other hand, if option X has some other intrinsic value (such > has holding the multipath TCP connection ID for middleboxes to decode) > then you can just keep sending it in every packet which uses it for > the remainder of the connection instead of the fancy handshake. Options can add asynchronous information - which is how they're used now. They simply cannot add synchronized info - which is why they can't be used to negotiate new options - AFAICT. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkr510cACgkQE5f5cImnZrtlpgCg7q4Dm/RtIcnNOfTkpPWlzini JVcAn0zJpg/7Nxgx+IPTucWKqr9R7llX =20o5 -----END PGP SIGNATURE----- From wherrin@gmail.com Tue Nov 10 14:12:22 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215C23A68E4 for ; Tue, 10 Nov 2009 14:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvyiIlg0Ejib for ; Tue, 10 Nov 2009 14:12:21 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 6AF563A680B for ; Tue, 10 Nov 2009 14:12:20 -0800 (PST) Received: by ewy3 with SMTP id 3so556365ewy.37 for ; Tue, 10 Nov 2009 14:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=5aDY0pS5L/4IFDwlngwzTC2J+hDrqLgHQv91JsDQEMI=; b=exs4M+0VP7IU/7Y4BZ7dadZIm8tkak80xaDwblGAqQo/CDl7JotcoPvbXv97VOuRE4 I7ZA39XD6X7t71Jv+zOJLwmKxeqdFb6KQ1aNZfimxg9uVcFGeAXO+aYnqEmAlZKQMhYT qkQaskvJukARNxuCfvfCMjVNS3bslsYF+Y+zA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=GSPdUnHFWFzf9Rmz7aYRobQaXXS0WMUjSPylp3EVPiAzys0Letz2ZPCqADi44Xg2Ro plvaG80N3nR17vW/UFqEv3AgsDipcdcw/pau5nFkpxgb5yBk+H4QgL0EfNoO5tAYDlu7 GLRdlTRiFd1emIysupMuuir/YSHx5n9uIYdrc= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.91.5 with SMTP id g5mr219772wef.168.1257891163820; Tue, 10 Nov 2009 14:12:43 -0800 (PST) In-Reply-To: <4AF9D747.5080707@isi.edu> References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> <4AF09EA5.9030308@isi.edu> <3c3e3fca0911041219o5ddea192h297afa82882992e3@mail.gmail.com> <4AF8B70E.90908@isi.edu> <3c3e3fca0911091918l27562923j5b1b7fd15461c04f@mail.gmail.com> <4AF8DDA7.9030108@isi.edu> <3c3e3fca0911101245y7db0aa21wab41a66834feef19@mail.gmail.com> <4AF9D747.5080707@isi.edu> Date: Tue, 10 Nov 2009 17:12:43 -0500 X-Google-Sender-Auth: d4a3a610ebf0c27b Message-ID: <3c3e3fca0911101412m78a9b95ay1b10e0a9787f200f@mail.gmail.com> From: William Herrin To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:12:22 -0000 On Tue, Nov 10, 2009 at 4:12 PM, Joe Touch wrote: > William Herrin wrote: >> On Mon, Nov 9, 2009 at 10:27 PM, Joe Touch wrote: >>> Right. How do you bury that handshake in an unordered, unreliable stream >>> without halting it, though? >> >> When you receive X accepted, attach X1 to *every* outgoing packet >> until you get an ack for everything up to and including the first X1 >> packet. > > What happens to retransmitted packets that were first sent before you > decided to set X? Hi Joe, Retransmit as originally sent. Otherwise you could have two very different packets show up for the same segment. Set X1 only on packets whose first transmission comes after option X accepted. >> Then start sending X2 in every outgoing packet until you get >> an ack for any X2 packet. Then stop sending the X option on any packet >> that isn't a retransmission of one where X1 or X2 was sent. >> >> At the receiver end: until you receive a packet with X2, only packets >> with X1 or X2 have option X in effect. > > So now you have a problem. Some packets are handled as if option X is in > effect, and some are not. These could arrive in any order. What if the > option has something to do with the order in which the packets are ACKd? As I mentioned: constraint on the option in this exchange in that it can't impact the handling of the sequence number. ACK is handling the sequence number. > Or the order in which they're sent to the app? You mean like URG data? I'm surprised URG hasn't been deprecated given the inconsistent implementations. So, I gather we'd have to add a constraint that the use of URG or reordering options is incompatible with the use of a post-syn-negotiated stateful option. Otherwise, there's no ordering problem, right? The stack delivers data to the app in order by sequence number and will have made all the data in segments before the first X1 available to the app before the sender sends the first X2. >> After you see any packet with >> X2, all subsequent packets have option X in effect regardless of the >> presence of X1 or X2. > > Not packets sent before X was set at the source. Excepting any late arriving duplicates (where the data will be discarded), there's no way for the receiver to get a packet that was sent before X was set at the source. The source confirmed that by switching to setting X2 only after everything up to and including the first X1 packet was acked. >> On the other hand, if option X has some other intrinsic value (such >> has holding the multipath TCP connection ID for middleboxes to decode) >> then you can just keep sending it in every packet which uses it for >> the remainder of the connection instead of the fancy handshake. > > Options can add asynchronous information - which is how they're used > now. They simply cannot add synchronized info - which is why they can't > be used to negotiate new options - AFAICT. By the way, I appreciate you bouncing this back and forth with me. I don't doubt your conclusions but I find that trying to poke holes in a conclusion is one of the more effective ways to learn the underlying issues that brought it about. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From c.raiciu@cs.ucl.ac.uk Tue Nov 10 16:32:20 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77FC13A691F for ; Tue, 10 Nov 2009 16:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4aJVyZ7OYDP for ; Tue, 10 Nov 2009 16:32:19 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id A06093A691A for ; Tue, 10 Nov 2009 16:32:18 -0800 (PST) Received: from host-32-98.meeting.ietf.org ([133.93.32.98]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N812F-000DPC-RC for multipathtcp@ietf.org; Wed, 11 Nov 2009 00:26:08 +0000 Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: "multipathtcp@ietf.org List" From: Costin Raiciu Date: Wed, 11 Nov 2009 09:32:18 +0900 X-Mailer: Apple Mail (2.753.1) Subject: [multipathtcp] Implementers Meeting at 3pm X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:32:20 -0000 Hi, Let's meet at 3pm in front of the IETF Registration desk. See you, Costin From alan.ford@roke.co.uk Tue Nov 10 17:06:51 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747593A68B3 for ; Tue, 10 Nov 2009 17:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHwOpm9UCxB8 for ; Tue, 10 Nov 2009 17:06:50 -0800 (PST) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id 6332D3A689C for ; Tue, 10 Nov 2009 17:06:50 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nAB175iT030549; Wed, 11 Nov 2009 01:07:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 01:07:13 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7BDEE@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <3c3e3fca0911101220g55f84f79nf62526d8693d39fa@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] The point about multiple listening sockets at theclient side Thread-Index: AcpiQ1KJ+8bIwAg0RrOPhsXcilrchAAJk98g References: <4AF8B8A5.4040602@ismailov.eu> <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911101220g55f84f79nf62526d8693d39fa@mail.gmail.com> From: "Ford, Alan" To: "William Herrin" X-roke-co-uk-MailScanner-ID: nAB175iT030549 X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] The point about multiple listening sockets at theclient side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:06:51 -0000 Hi Bill, all, > On Mon, Nov 9, 2009 at 8:06 PM, Ford, Alan wrote: > > The client (in terms of software) does not need to open listening > > sockets in this case. But the MPTCP stack itself will be listening on > > all interfaces for potential incoming subflows from the server, which > > when initiated are joined to the existing connection. The application > > does not need to do anything for this to happen (but if an extended API > > were in use it could, for example, have callbacks to be informed). >=20 > Hi Alan, >=20 > Two thoughts: >=20 > 1. When the initiator (of the overall connection) tries to add a > subflow, he'll want to use the same destination port number and a full > syn-syn/ack-ack handshake to maximize the chances of getting through > the acceptor's firewall unscathed. Agreed - and not to upset port-based traffic engineering either. > 2. When the acceptor tries to add a subflow, he best not offer a syn. > The syn won't get through the initiator's firewall. Nor should it: a > SYN packet to a non-multipath host would be interpreted as a plain > connection attempt. Disagree. Well, I can see what you're saying, but subflows /need/ to be SYN+SYN/ACKed, whichever way they go, since they are essentially standard TCP sessions, reassembled at the endpoints. In particular, although there may be some firewalls that would let that traffic through, many others would not (not part of a known TCP session), not to mention other middleboxes anywhere along the path, including many NATs, that would not know what to do with TCP packets that do not appear to be part of a session they know about (since they haven't seen a SYN for that particular 5-tuple). Regards, Alan From c.raiciu@cs.ucl.ac.uk Tue Nov 10 18:21:01 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D82028C266 for ; Tue, 10 Nov 2009 18:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKvAPu9GQaph for ; Tue, 10 Nov 2009 18:21:00 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 754803A696E for ; Tue, 10 Nov 2009 18:21:00 -0800 (PST) Received: from host-32-98.meeting.ietf.org ([133.93.32.98]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N82jQ-000DPq-Ci for multipathtcp@ietf.org; Wed, 11 Nov 2009 02:14:48 +0000 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <3c3e3fca0911091838w6620d955m68074495027d7c5d@mail.gmail.com> References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911091838w6620d955m68074495027d7c5d@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Wed, 11 Nov 2009 11:21:03 +0900 To: "multipathtcp@ietf.org List" X-Mailer: Apple Mail (2.753.1) Subject: [multipathtcp] Options or Payload: pros and cons X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:21:01 -0000 Hi I tried to assemble a pros and cons list for the two approaches. Please add bullets to both lists until we get something reasonably exhaustive, and then we can make an informed decision. At a high level, we need to use options on every subflow at least in the syn exchange. Otherwise we can't attach the subflow to the existing connection, or can't negotiate mptcp in the first place. Ideally you'd like fate sharing: if the syn/ack exchange passes, the subflow should work. Options + nice with tcp + single subflow mptcp if friendly with IDSes, and traffic normalizers (i.e. data flow is what the app receives). - reliability is more difficult (how often do you retransmit?) drop packets? what's the failure mode when options don't get through? - boxes may crash when parsing unknown stuff. The hope is that on SYN processing is more robust with unknown options. ECN story is frightening :). Murari (Microsoft) says that even changing position of padding bits in options crashes some middleboxes; I've heard a similar story from the Linux kernel experience. However, we can't (cleanly) avoid sending options on SYNs. Payload + option space limits no longer matter; can do funkier stuff later, like negotiate keys, etc. + easier to get reliability; retransmit of control data linked to data retransmit + easier to deal with middleboxes that resegment (it just works!) + new options on syns may be allowed, but not on data (is this true)? - feels like a hack, not the traditional way to evolve tcp - implies encoding of any data sent MUST be ASCII; middleboxes (ids, traffic normalizers) that look at content and see binary stuff will probably drop the data; finally, if we used binary stuff, there is no guarantee for fate sharing. . Text encoding is less space efficient; does it matter? Any more? Costin From touch@ISI.EDU Tue Nov 10 18:56:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD1A3A69B9 for ; Tue, 10 Nov 2009 18:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHLeOIy-WPMu for ; Tue, 10 Nov 2009 18:56:39 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CE0833A6952 for ; Tue, 10 Nov 2009 18:56:39 -0800 (PST) Received: from [133.93.24.140] (host-24-140.meeting.ietf.org [133.93.24.140]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAB2ujuE010936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Nov 2009 18:56:48 -0800 (PST) Message-ID: <4AFA27EC.6070409@isi.edu> Date: Tue, 10 Nov 2009 18:56:44 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: William Herrin References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808C85178@rsys005a.comm.ad.roke.co.uk> <4AF09EA5.9030308@isi.edu> <3c3e3fca0911041219o5ddea192h297afa82882992e3@mail.gmail.com> <4AF8B70E.90908@isi.edu> <3c3e3fca0911091918l27562923j5b1b7fd15461c04f@mail.gmail.com> <4AF8DDA7.9030108@isi.edu> <3c3e3fca0911101245y7db0aa21wab41a66834feef19@mail.gmail.com> <4AF9D747.5080707@isi.edu> <3c3e3fca0911101412m78a9b95ay1b10e0a9787f200f@mail.gmail.com> In-Reply-To: <3c3e3fca0911101412m78a9b95ay1b10e0a9787f200f@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] High-level design decisions /architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:56:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Bill, William Herrin wrote: > On Tue, Nov 10, 2009 at 4:12 PM, Joe Touch wrote: >> William Herrin wrote: >>> On Mon, Nov 9, 2009 at 10:27 PM, Joe Touch wrote: >>>> Right. How do you bury that handshake in an unordered, unreliable stream >>>> without halting it, though? >>> When you receive X accepted, attach X1 to *every* outgoing packet >>> until you get an ack for everything up to and including the first X1 >>> packet. >> What happens to retransmitted packets that were first sent before you >> decided to set X? > > Hi Joe, > > Retransmit as originally sent. Otherwise you could have two very > different packets show up for the same segment. Set X1 only on packets > whose first transmission comes after option X accepted. The issue is that there is no synchronization between options and segments or segment offsets. You're now requiring that - which is a huge complication. >>> Then start sending X2 in every outgoing packet until you get >>> an ack for any X2 packet. Then stop sending the X option on any packet >>> that isn't a retransmission of one where X1 or X2 was sent. >>> >>> At the receiver end: until you receive a packet with X2, only packets >>> with X1 or X2 have option X in effect. >> So now you have a problem. Some packets are handled as if option X is in >> effect, and some are not. These could arrive in any order. What if the >> option has something to do with the order in which the packets are ACKd? > > As I mentioned: constraint on the option in this exchange in that it > can't impact the handling of the sequence number. ACK is handling the > sequence number. I think that the option has more constraints than that - it can't affect anything in the data stream - ACK or anything else. >> Or the order in which they're sent to the app? > > You mean like URG data? I'm surprised URG hasn't been deprecated given > the inconsistent implementations. URG is about how quickly you tell the user about data you've ACKd. This is about whether you need to hold data you've ACKd until the new option is ACKd - an "anti"-URG. > So, I gather we'd have to add a constraint that the use of URG or > reordering options is incompatible with the use of a > post-syn-negotiated stateful option. More than that - you also need to hold the queue - an "anti"-URG - until the option is negotiated. This is a new behavior not currently supported. > Otherwise, there's no ordering problem, right? The stack delivers data > to the app in order by sequence number and will have made all the data > in segments before the first X1 available to the app before the sender > sends the first X2. The option could affect how the data is delivered - e.g., whether there are markers, or the chunksize sent to the app. If so, you can't send the data up until you negotiate the option that tags that data. >>> After you see any packet with >>> X2, all subsequent packets have option X in effect regardless of the >>> presence of X1 or X2. >> Not packets sent before X was set at the source. > > Excepting any late arriving duplicates (where the data will be > discarded), there's no way for the receiver to get a packet that was > sent before X was set at the source. The source confirmed that by > switching to setting X2 only after everything up to and including the > first X1 packet was acked. Late arriving dups have both data and header info. TCP decides how to handle the data LAST - it operates on the header first. You can't decide to ignore a header field based on whether the data will be dropped because that happens last. >>> On the other hand, if option X has some other intrinsic value (such >>> has holding the multipath TCP connection ID for middleboxes to decode) >>> then you can just keep sending it in every packet which uses it for >>> the remainder of the connection instead of the fancy handshake. >> Options can add asynchronous information - which is how they're used >> now. They simply cannot add synchronized info - which is why they can't >> be used to negotiate new options - AFAICT. > > By the way, I appreciate you bouncing this back and forth with me. I > don't doubt your conclusions but I find that trying to poke holes in a > conclusion is one of the more effective ways to learn the underlying > issues that brought it about. No problem... I hope it's continuing to be useful. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkr6J+wACgkQE5f5cImnZrsHVwCfRE1ODyNvGmIXozp1ZYK3HMC2 obIAniJm3Tk87R+zpcf22IUqOCGA+Q49 =pzbC -----END PGP SIGNATURE----- From wherrin@gmail.com Wed Nov 11 17:36:41 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865C53A67B1 for ; Wed, 11 Nov 2009 17:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG0udFsBtP1L for ; Wed, 11 Nov 2009 17:36:40 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 669ED3A63EB for ; Wed, 11 Nov 2009 17:36:40 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so644086fga.13 for ; Wed, 11 Nov 2009 17:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=qgt+bztInAs0GBHenN3Rf+8rKuTUHoye0wOK9Mjg0ys=; b=Mo7kJlaVAYWHOLbNUnN03QVRXBi4AF/rjKTbpoWDx21SapmOlAfBzbODnX8gaeD/IJ D7EMehSn8tnEnV1BBU1VFNgU3euepzNuhG+pkxn8+ugv0Sm82j2Ru0z63qQLtStMn6sv ifJGsds0Or8fqsMFt9D2BlNbbqGn3abbufzIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Lr2ItkCggjsi2DUhL9ZmtgZ6+HFdLvHNA4pEdR0rcVIu72UFbioGZhfV24qb2Lhawt bVy2KQc+wyFOPzIkuesEHs/maahTPMUci1H63ukcGZB1hMsOwY4Zg3C1IxBgZTIpK675 G/OMMDQ/qFCr6PRrpW/yFKcqTnJ8cBnCrTh8g= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.86.195 with SMTP id w45mr745060wee.82.1257989825241; Wed, 11 Nov 2009 17:37:05 -0800 (PST) In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808D7BDEE@rsys005a.comm.ad.roke.co.uk> References: <4AF8B8A5.4040602@ismailov.eu> <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911101220g55f84f79nf62526d8693d39fa@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808D7BDEE@rsys005a.comm.ad.roke.co.uk> Date: Wed, 11 Nov 2009 20:37:05 -0500 X-Google-Sender-Auth: 5f238bc426ab74fa Message-ID: <3c3e3fca0911111737t5c783bf7rb96f49bb15f360e3@mail.gmail.com> From: William Herrin To: "Ford, Alan" Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] The point about multiple listening sockets at theclient side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:36:41 -0000 On Tue, Nov 10, 2009 at 8:07 PM, Ford, Alan wrote: >> On Mon, Nov 9, 2009 at 8:06 PM, Ford, Alan > wrote: >> 2. When the acceptor tries to add a subflow, he best not offer a syn. >> The syn won't get through the initiator's firewall. Nor should it: a >> SYN packet to a non-multipath host would be interpreted as a plain >> connection attempt. > > Disagree. Well, I can see what you're saying, but subflows /need/ to be > SYN+SYN/ACKed, whichever way they go, since they are essentially > standard TCP sessions, reassembled at the endpoints. In particular, > although there may be some firewalls that would let that traffic > through, many others would not (not part of a known TCP session), not to > mention other middleboxes anywhere along the path, including many NATs, > that would not know what to do with TCP packets that do not appear to be > part of a session they know about (since they haven't seen a SYN for > that particular 5-tuple). Hi Alan, Plot the middlebox use scenarios: TS: TCP SYN-SYN/ACK-ACK from the server to the client which includes the multipath TCP subflow join option. MJ: TCP packet without SYN but containing the multipath TCP join option and expecting the same sort of JOIN-JOIN/ACK-ACK handshake. Scenarios: No firewall: TS succeeds. MJ succeeds. Packet filter: TS fails. SYN to a random client port? Don't think so! MJ succeeds. Legacy Stateful firewall: TS fails. MJ fails. Legacy "DSL router": TS fails. MJ fails. Multipath-aware stateful firewall: TS fails. SYN to a random client port? Bad plan! MJ succeeds. Multipath-aware "DSL router": TS fails. SYN to a random client port? Come on! MJ succeeds. Or am I missing something? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scott.brim@gmail.com Wed Nov 11 17:46:20 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0935B28C18E for ; Wed, 11 Nov 2009 17:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUbpoWa8VNHg for ; Wed, 11 Nov 2009 17:46:19 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id B33CB28C17B for ; Wed, 11 Nov 2009 17:46:18 -0800 (PST) Received: by yxe30 with SMTP id 30so1826811yxe.29 for ; Wed, 11 Nov 2009 17:46:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=6+MuFAAz1/zaaO82uDykLqrIX4PHoTTMlxVdYls+xgg=; b=iwVYMKx43jMqWvNC5mLfgSBa0iaxYXoZgqlIpXGhV3Y+L8Q8pW/UvWuN2FC4v/alsB emGcVrjmD6zTZcbyO2zTDeYQ8FJxFiAMn3QtXEf6ESXCpyF5gT8kthgssssQ2xKKndeq BE08+byk9jDsn/ntz0NP/dlm/5gixtflVk2VI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=JhkGpUOR5wRdJ6EBb/NUlRm3UsMynjhYh6O5TINNnvCr8Ah8cEFMakdpuIODQPhskv PoIGRh1tBOqX8/GKBSD0Tx8FcsFAfgFPfFRK8Q7FIt/aAMfJ6PiaJcA7vMGqgnv41a9i VEKG2+8YK+zDnYwy4DZd4Af/ylx/qwCy31xYY= Received: by 10.150.243.5 with SMTP id q5mr4170433ybh.13.1257990402942; Wed, 11 Nov 2009 17:46:42 -0800 (PST) Received: from host-24-56.meeting.ietf.org (host-24-56.meeting.ietf.org [133.93.24.56]) by mx.google.com with ESMTPS id 16sm10991gxk.11.2009.11.11.17.46.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 17:46:42 -0800 (PST) Message-ID: <4AFB68FE.2040606@gmail.com> Date: Thu, 12 Nov 2009 10:46:38 +0900 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Ford, Alan" References: <4AF8B8A5.4040602@ismailov.eu> <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] The point about multiple listening sockets at theclient side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:46:20 -0000 Ford, Alan allegedly wrote on 11/10/2009 10:06 AM: > Hi Yuri, > > The client (in terms of software) does not need to open listening > sockets in this case. But the MPTCP stack itself will be listening on > all interfaces for potential incoming subflows from the server, All or some, which can be a local config option. In any case it's not something the app has to be involved in. (The app _could_ be involved.) From Michael.Scharf@alcatel-lucent.com Wed Nov 11 17:57:37 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5784E3A689F for ; Wed, 11 Nov 2009 17:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xvbru1awe3cs for ; Wed, 11 Nov 2009 17:57:36 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id E59943A6859 for ; Wed, 11 Nov 2009 17:57:35 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn2.rcs.de.alcatel-lucent.com [149.204.60.99]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id nAC1vts5004064; Thu, 12 Nov 2009 02:57:56 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 02:57:53 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD21@SLFSNX.rcs.alcatel-research.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Options or Payload: pros and cons Thread-Index: AcpidbAuiuf3FDhCS16ZftfPqCghoQAxCBHA References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk><3c3e3fca0911091838w6620d955m68074495027d7c5d@mail.gmail.com> From: "SCHARF, Michael" To: "Costin Raiciu" , X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Subject: Re: [multipathtcp] Options or Payload: pros and cons X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:57:37 -0000 > Payload > + option space limits no longer matter; can do funkier stuff later, > like negotiate keys, etc. > + easier to get reliability; retransmit of control data linked to > data retransmit > + easier to deal with middleboxes that resegment (it just works!) new=20 > + options on syns may be allowed, but not on data (is this true)? > - feels like a hack, not the traditional way to evolve tcp > - implies encoding of any data sent MUST be ASCII;=20 > middleboxes (ids, traffic normalizers) that look at content=20 > and see binary stuff will probably drop the data; finally, if=20 > we used binary stuff, there is no guarantee for fate sharing.=20 > . Text encoding is less space efficient; does it matter? I don't understand why ASCII encoding is mandatory. An IDS that parses the content may anyway be confused by the incomplete content inside one MPTCP subflow, independent of the question whether options or payload encoding is used. Or do I miss something? Michael From Michael.Scharf@alcatel-lucent.com Wed Nov 11 18:10:43 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E016A3A6B84 for ; Wed, 11 Nov 2009 18:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rweXqVgvqvbv for ; Wed, 11 Nov 2009 18:10:43 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 92A633A6B6A for ; Wed, 11 Nov 2009 18:10:42 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn2.rcs.de.alcatel-lucent.com [149.204.60.99]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id nAC2B4X1006770; Thu, 12 Nov 2009 03:11:04 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 03:11:01 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD22@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <3c3e3fca0911090615g7a2dedb6x8a6a1ddf2aea2dd8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] API: which address to use Thread-Index: AcphRycJIIqU3wUIQEKM9ZGeoTUMfgB9Nqaw References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <3c3e3fca0911090615g7a2dedb6x8a6a1ddf2aea2dd8@mail.gmail.com> From: "SCHARF, Michael" To: "William Herrin" , "Pasi Sarolahti" X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] API: which address to use X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:10:44 -0000 > I stand by what I said about getsockname, however specifying=20 > a PF_INETMP in the original socket call would be more=20 > appropriate than PF_INET or PF_INET6 if we intend multipath=20 > to be protocol family agnostic. It would also be a reasonable=20 > way for the app to signal to the stack whether it expects the=20 > use of multipath. I think that a PF_INETMP could indeed be a non-mandatory way to enable MPTCP (MPTCP would still also be used with PF_INET or PF_INET6 in order to be backward compatible). Are there any other opinions on the PF_INETMP solution? Michael From magnus.westerlund@ericsson.com Wed Nov 11 18:16:44 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BBE28C17B for ; Wed, 11 Nov 2009 18:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egPurJxwSE5L for ; Wed, 11 Nov 2009 18:16:43 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CEDC13A6B6A for ; Wed, 11 Nov 2009 18:16:42 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-73-4afb70264106 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id A0.3F.04191.6207BFA4; Thu, 12 Nov 2009 03:17:10 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 03:17:10 +0100 Received: from [153.88.46.204] ([153.88.46.204]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 03:17:09 +0100 Message-ID: <4AFB7024.8030503@ericsson.com> Date: Thu, 12 Nov 2009 11:17:08 +0900 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "multipathtcp@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Nov 2009 02:17:10.0031 (UTC) FILETIME=[3D4191F0:01CA633E] X-Brightmail-Tracker: AAAAAA== Subject: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:16:44 -0000 Hi, I just looked at draft-ford-mptcp-multiaddressed-02 and saw that the add address option lacks a port number. I think that will not work for two reasons. 1. First, there will a large amount of single flow TCP connections and you will run into a synchronization issue and resource constrain issue if you limit your interface port to be the same over all interfaces. 2. Your NAT traversal will fail as soon it encounters a NAT that is unable to do port preservation. That is likelier and likelier to happen, espeically for ISP place NATs where the load level is higher. Port preservation will also fail as soon as two sub-flows goes over the same NAT. Thus to enable MPTCP to work in cases where you use either an explicit signalling protocol (UPnP, etc) or implicit methods, like STUN to find out your external subflow address they will not be able to preserver the port in the generic case. Thus there is need to be able to indicate the listening port. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Michael.Scharf@alcatel-lucent.com Wed Nov 11 18:33:15 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364343A6B11 for ; Wed, 11 Nov 2009 18:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmjBKiEXWAge for ; Wed, 11 Nov 2009 18:33:14 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id F40163A69CD for ; Wed, 11 Nov 2009 18:33:13 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn2.rcs.de.alcatel-lucent.com [149.204.60.99]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id nAC2XeZc011469 for ; Thu, 12 Nov 2009 03:33:40 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 03:33:37 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initial ideas for API requirements Thread-Index: AcpjQIoAoL44kE9NT7qhi+E9z7bf/Q== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Subject: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:33:15 -0000 Dear all, draft-scharf-mptcp-api-00 contains a list of potential requirements on the MPTCP API towards application. This list is of course just a starting point. Currently, it is certainly not complete and may also include requirements that will be removed in later stage, once the MPTCP architecture spec evolves. Still, we would really appreciate comments on the scope of the (optional) extended API. Please find below a copy of the list in the draft. REQ1: Turn on/off MPTCP: An application should be able to request to turn on or turn off the usage of MPTCP. This means that an application should be able to explicitly request the use of MPTCP if this is possible. Applications should also be able to request not to enable MPTCP and to use regular TCP transport instead. (This can be implicit in many cases, e.g., by the use of binding to a specific address versus all addresses). REQ2: An application will want to be able to restrict MPTCP to binding to a given set of addresses or interfaces. REQ3: An application should be able to know if multiple subflows are in use. REQ4: An application should be able to extract a unique identifier for the connection (per endpoint), analogous to a port, i.e. it should be able to retrieve MPTCP's connection identifier. REQ5: An application should be able to enumerate all subflows in use, obtain information on the addresses used by a subflow, and obtain a subflow's usage (e.g., ratio of traffic sent via this subflow). REQ6: Set/get application profile, as discussed in the previous section. REQ7: Constrain the maximum number of subflows to be used by an MPTCP connection. (Or just infer from application profile?) REQ8: Request a change in scheduling between subflows? (i.e. a more granular version of application profile?) REQ9: Request a change in the number of subflows in use, thus triggering removal or addition of subflows. (A finer control granularity would be: Request the establishment of a new subflow to a provided destination, and request the termination of a specified, existing subflow.) REQ10: Control automatic establishment/termination of subflows? There could be different configurations of the path manager, e.g., 'try ASAP', 'wait until there is a bunch of data, etc. (Tied to application profile?) REQ11: Set/get preferred subflows or subflow usage policies? There could be different configurations of the multipath scheduler, e.g., 'all-or-nothing', 'overflow', etc. (Again, tied to application profile). REQ12: Set/get sporadic sending of segments on unused paths ("keepalives"). REQ13: An application should be able to modify the MPTCP configuration while communication is ongoing, i.e., after establishment of the MPTCP connection. Thanks Michael From pasi.sarolahti@iki.fi Wed Nov 11 19:36:10 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883853A682A for ; Wed, 11 Nov 2009 19:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KQEt0hM2nhg for ; Wed, 11 Nov 2009 19:36:09 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 678273A67D3 for ; Wed, 11 Nov 2009 19:36:09 -0800 (PST) Received: from host-128-144.meeting.ietf.org (host-128-144.meeting.ietf.org [133.93.128.144]) by argo.otaverkko.fi (Postfix) with ESMTP id 2D5B625ED12; Thu, 12 Nov 2009 05:36:35 +0200 (EET) Message-Id: From: Pasi Sarolahti To: Magnus Westerlund In-Reply-To: <4AFB7024.8030503@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Nov 2009 12:36:30 +0900 References: <4AFB7024.8030503@ericsson.com> X-Mailer: Apple Mail (2.936) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:36:10 -0000 Hi, I agree that port needs to be included. To clarify (also to myself): the only method of adding subflows is the =20= Join-option, right? That allows any port to be used with a subflow. I =20= see Add Address option as a kind of a hint to the other end, asking =20 its receiver to send a Join-option in the reverse direction, to come =20 around certain NAT situations where direct Join does not work. I think =20= the draft might need to be a bit more clear about this in section 4.3, =20= saying that host should not add a subflow based on an ADDR option, but =20= can rather react by sending a Join option to the given address, which =20= in successful case leads to creation of a subflow. I think including IP addresses in transport protocol is a kind of a =20 layer violation and therefore little ugly, but can well see why this =20 is needed here. I wouldn't mind if it was emphasized that use of this =20= option is, in fact, optional. It's such an expense to the option =20 space, especially with IPv6 (with which the need of this option is =20 questionable anyway). In theory there might also be other address =20 families than IPv4 or IPv6... - Pasi On Nov 12, 2009, at 11:17 AM, Magnus Westerlund wrote: > Hi, > > I just looked at draft-ford-mptcp-multiaddressed-02 and saw that the =20= > add > address option lacks a port number. I think that will not work for two > reasons. > > 1. First, there will a large amount of single flow TCP connections and > you will run into a synchronization issue and resource constrain issue > if you limit your interface port to be the same over all interfaces. > > 2. Your NAT traversal will fail as soon it encounters a NAT that is > unable to do port preservation. That is likelier and likelier to =20 > happen, > espeically for ISP place NATs where the load level is higher. Port > preservation will also fail as soon as two sub-flows goes over the =20 > same > NAT. Thus to enable MPTCP to work in cases where you use either an > explicit signalling protocol (UPnP, etc) or implicit methods, like =20 > STUN > to find out your external subflow address they will not be able to > preserver the port in the generic case. Thus there is need to be =20 > able to > indicate the listening port. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From yuri@ismailov.eu Wed Nov 11 20:22:48 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D2228C1EC for ; Wed, 11 Nov 2009 20:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUFsyiNRYz9R for ; Wed, 11 Nov 2009 20:22:47 -0800 (PST) Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.12]) by core3.amsl.com (Postfix) with ESMTP id 0E53428C1ED for ; Wed, 11 Nov 2009 20:22:47 -0800 (PST) Received: from [133.93.19.5] (host-19-5.meeting.ietf.org [133.93.19.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id E2136576AA4; Thu, 12 Nov 2009 05:23:13 +0100 (CET) Message-ID: <4AFB8DAC.1030008@ismailov.eu> Date: Thu, 12 Nov 2009 05:23:08 +0100 From: Yuri Ismailov User-Agent: Thunderbird 2.0.0.23 (X11/20091002) MIME-Version: 1.0 To: William Herrin References: <4AF8B8A5.4040602@ismailov.eu> <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911101220g55f84f79nf62526d8693d39fa@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808D7BDEE@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911111737t5c783bf7rb96f49bb15f360e3@mail.gmail.com> In-Reply-To: <3c3e3fca0911111737t5c783bf7rb96f49bb15f360e3@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] The point about multiple listening sockets at theclient side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 04:22:48 -0000 William Herrin wrote: > On Tue, Nov 10, 2009 at 8:07 PM, Ford, Alan wrote: > >>> On Mon, Nov 9, 2009 at 8:06 PM, Ford, Alan >>> >> wrote: >> >>> 2. When the acceptor tries to add a subflow, he best not offer a syn. >>> The syn won't get through the initiator's firewall. Nor should it: a >>> SYN packet to a non-multipath host would be interpreted as a plain >>> connection attempt. >>> >> Disagree. Well, I can see what you're saying, but subflows /need/ to be >> SYN+SYN/ACKed, whichever way they go, since they are essentially >> standard TCP sessions, reassembled at the endpoints. In particular, >> although there may be some firewalls that would let that traffic >> through, many others would not (not part of a known TCP session), not to >> mention other middleboxes anywhere along the path, including many NATs, >> that would not know what to do with TCP packets that do not appear to be >> part of a session they know about (since they haven't seen a SYN for >> that particular 5-tuple). >> > > Hi Alan, > > Plot the middlebox use scenarios: > > TS: TCP SYN-SYN/ACK-ACK from the server to the client which includes > the multipath TCP subflow join option. > > MJ: TCP packet without SYN but containing the multipath TCP join > option and expecting the same sort of JOIN-JOIN/ACK-ACK handshake. > > Scenarios: > > No firewall: TS succeeds. MJ succeeds. > Packet filter: TS fails. SYN to a random client port? Don't think so! > MJ succeeds. > Legacy Stateful firewall: TS fails. MJ fails. > Legacy "DSL router": TS fails. MJ fails. > Multipath-aware stateful firewall: TS fails. SYN to a random client > port? Bad plan! MJ succeeds. > Multipath-aware "DSL router": TS fails. SYN to a random client port? > Come on! MJ succeeds. > > Or am I missing something? > > Regards, > Bill Herrin > > > Hi, As it looks like a client should be initiator at all times in order to provide a smooth operation. Would it be reasonable to send some options or needed information in the join flow from server to client, so that the client would start SYN-SYNACK-ACK exchange? Regards Yuri From c.raiciu@cs.ucl.ac.uk Wed Nov 11 22:51:46 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4435A28C0F6 for ; Wed, 11 Nov 2009 22:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwaX6qqdyRhK for ; Wed, 11 Nov 2009 22:51:45 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 7525A3A6B90 for ; Wed, 11 Nov 2009 22:51:45 -0800 (PST) Received: from host-32-98.meeting.ietf.org ([133.93.32.98]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N8TQN-000Del-6X; Thu, 12 Nov 2009 06:44:55 +0000 In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD21@SLFSNX.rcs.alcatel-research.de> References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk><3c3e3fca0911091838w6620d955m68074495027d7c5d@mail.gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C01B6AD21@SLFSNX.rcs.alcatel-research.de> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Thu, 12 Nov 2009 15:51:46 +0900 To: "SCHARF, Michael" X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp Subject: Re: [multipathtcp] Options or Payload: pros and cons X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 06:51:46 -0000 Hi, I am thinking of middleboxes that expect "text-only" protocols and we would introduce binary data in the payload. That's not going to go down well, but in the end it's just another failure mode. I guess whichever way we go, we really need to think carefully about failure modes. Let me add one more bullet to the list, after my discussion with Murari today. Payload - involves mixing the control and data plane in host stacks; will be much more difficult to implement On 12 Nov 2009, at 10:57, SCHARF, Michael wrote: >> > > I don't understand why ASCII encoding is mandatory. An IDS that parses > the content may anyway be confused by the incomplete content inside > one > MPTCP subflow, independent of the question whether options or payload > encoding is used. Or do I miss something? > > Michael From c.raiciu@cs.ucl.ac.uk Wed Nov 11 23:00:06 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF753A6B05 for ; Wed, 11 Nov 2009 23:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLWpY8O87F6j for ; Wed, 11 Nov 2009 23:00:05 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 0BB823A6919 for ; Wed, 11 Nov 2009 23:00:05 -0800 (PST) Received: from host-32-98.meeting.ietf.org ([133.93.32.98]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N8TYR-000Der-AJ; Thu, 12 Nov 2009 06:53:15 +0000 In-Reply-To: <4AFB7024.8030503@ericsson.com> References: <4AFB7024.8030503@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <385671C6-967F-4908-8928-E70ADED5AB75@cs.ucl.ac.uk> Content-Transfer-Encoding: quoted-printable From: Costin Raiciu Date: Thu, 12 Nov 2009 16:00:01 +0900 To: Magnus Westerlund X-Mailer: Apple Mail (2.753.1) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 07:00:06 -0000 Hi, There is plenty of discussion on the mailing list about this, but =20 maybe it doesn't cover all the issues. Let me try to summarize again: - for ADDITIONAL subflows (i.e. not the first one) the port number in =20= the SYN packet does not matter for the host; demultiplexing is done =20 using the connection token. (this addresses point 1 - you don't need =20= to reserve that port on all interfaces). - let's first answer the question of WHEN add address option is used. =20= It is only used when subflow establishment fails from A to B (which =20 probably means B is behind NAT). At this point, the host with address =20= A will send add address on another subflow, telling the host with =20 address B please contact me here. B will send a SYN to A, with the =20 proper token. If A is behind a NAT (both A and B are now natted) this =20= will not work. People are arguing that if a port were signalled from =20 A to B this might work. I have doubts, since this doesn't really work =20= today either. However, I have nothing against putting the port in if =20 people think it would help reachability. Costin On 12 Nov 2009, at 11:17, Magnus Westerlund wrote: > Hi, > > I just looked at draft-ford-mptcp-multiaddressed-02 and saw that =20 > the add > address option lacks a port number. I think that will not work for two > reasons. > > 1. First, there will a large amount of single flow TCP connections and > you will run into a synchronization issue and resource constrain issue > if you limit your interface port to be the same over all interfaces. > > 2. Your NAT traversal will fail as soon it encounters a NAT that is > unable to do port preservation. That is likelier and likelier to =20 > happen, > espeically for ISP place NATs where the load level is higher. Port > preservation will also fail as soon as two sub-flows goes over the =20 > same > NAT. Thus to enable MPTCP to work in cases where you use either an > explicit signalling protocol (UPnP, etc) or implicit methods, like =20 > STUN > to find out your external subflow address they will not be able to > preserver the port in the generic case. Thus there is need to be =20 > able to > indicate the listening port. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From c.raiciu@cs.ucl.ac.uk Wed Nov 11 23:02:00 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D573A6B4B for ; Wed, 11 Nov 2009 23:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOq9QrYPunQm for ; Wed, 11 Nov 2009 23:01:59 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 752E23A6919 for ; Wed, 11 Nov 2009 23:01:59 -0800 (PST) Received: from host-32-98.meeting.ietf.org ([133.93.32.98]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N8TaH-000Dew-OJ; Thu, 12 Nov 2009 06:55:10 +0000 In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Thu, 12 Nov 2009 16:02:00 +0900 To: "SCHARF, Michael" X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 07:02:00 -0000 How about redundancy? I can think of cases where the app might like to send all segments on all paths, to reduce end to end rtt, etc. Costin On 12 Nov 2009, at 11:33, SCHARF, Michael wrote: > Dear all, > > draft-scharf-mptcp-api-00 contains a list of potential requirements on > the MPTCP API towards application. This list is of course just a > starting point. Currently, it is certainly not complete and may also > include requirements that will be removed in later stage, once the > MPTCP > architecture spec evolves. > > Still, we would really appreciate comments on the scope of the > (optional) extended API. Please find below a copy of the list in the > draft. > > REQ1: Turn on/off MPTCP: An application should be able to request > to turn on or turn off the usage of MPTCP. This means that > an application should be able to explicitly request the use > of MPTCP if this is possible. Applications should also be > able to request not to enable MPTCP and to use regular TCP > transport instead. (This can be implicit in many cases, > e.g., by the use of binding to a specific address versus > all > addresses). > > REQ2: An application will want to be able to restrict MPTCP to > binding to a given set of addresses or interfaces. > > REQ3: An application should be able to know if multiple subflows > are in use. > > REQ4: An application should be able to extract a unique > identifier > for the connection (per endpoint), analogous to a port, > i.e. > it should be able to retrieve MPTCP's connection > identifier. > > REQ5: An application should be able to enumerate all subflows in > use, obtain information on the addresses used by a subflow, > and obtain a subflow's usage (e.g., ratio of traffic > sent via > this subflow). > > REQ6: Set/get application profile, as discussed in the previous > section. > > REQ7: Constrain the maximum number of subflows to be used by an > MPTCP connection. (Or just infer from application > profile?) > > REQ8: Request a change in scheduling between subflows? (i.e. a > more > granular version of application profile?) > > REQ9: Request a change in the number of subflows in use, thus > triggering removal or addition of subflows. (A finer > control > granularity would be: Request the establishment of a new > subflow to a provided destination, and request the > termination of a specified, existing subflow.) > > REQ10: Control automatic establishment/termination of subflows? > There could be different configurations of the path > manager, > e.g., 'try ASAP', 'wait until there is a bunch of data, > etc. > (Tied to application profile?) > > REQ11: Set/get preferred subflows or subflow usage policies? > There > could be different configurations of the multipath > scheduler, > e.g., 'all-or-nothing', 'overflow', etc. (Again, tied to > application profile). > > REQ12: Set/get sporadic sending of segments on unused paths > ("keepalives"). > > REQ13: An application should be able to modify the MPTCP > configuration while communication is ongoing, i.e., after > establishment of the MPTCP connection. > > Thanks > > Michael > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From alan.ford@roke.co.uk Wed Nov 11 23:27:05 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A753A6A4F for ; Wed, 11 Nov 2009 23:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf7FASvDLTEN for ; Wed, 11 Nov 2009 23:27:04 -0800 (PST) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id 14E973A6853 for ; Wed, 11 Nov 2009 23:27:03 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nAC7RGrD000651; Thu, 12 Nov 2009 07:27:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 07:27:03 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7C070@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <3c3e3fca0911111737t5c783bf7rb96f49bb15f360e3@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] The point about multiple listening sockets at theclient side Thread-Index: AcpjOLeIseBn6uzCTbKfisJChmvLKwAL765g References: <4AF8B8A5.4040602@ismailov.eu> <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911101220g55f84f79nf62526d8693d39fa@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808D7BDEE@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911111737t5c783bf7rb96f49bb15f360e3@mail.gmail.com> From: "Ford, Alan" To: "William Herrin" X-roke-co-uk-MailScanner-ID: nAC7RGrD000651 X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] The point about multiple listening sockets at theclient side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 07:27:05 -0000 Hi Bill, all, > Plot the middlebox use scenarios: >=20 > TS: TCP SYN-SYN/ACK-ACK from the server to the client which includes > the multipath TCP subflow join option. >=20 > MJ: TCP packet without SYN but containing the multipath TCP join > option and expecting the same sort of JOIN-JOIN/ACK-ACK handshake. >=20 > Scenarios: >=20 > No firewall: TS succeeds. MJ succeeds. > Packet filter: TS fails. SYN to a random client port? Don't think so! > MJ succeeds. > Legacy Stateful firewall: TS fails. MJ fails. > Legacy "DSL router": TS fails. MJ fails. > Multipath-aware stateful firewall: TS fails. SYN to a random client > port? Bad plan! MJ succeeds. > Multipath-aware "DSL router": TS fails. SYN to a random client port? > Come on! MJ succeeds. So the only cases here where TS !=3D MJ is when you're talking about Multipath-aware routers or firewalls? In order for them to let through MJ they need the existence of the Join option to override the natural rejection of such a packet due to coming from an unknown address. In which case, they could do the same for TS! (Secondary point is that TS is likely to be going to a port on the client which is already in use, even though it's from the ephemeral range. The multipath-aware middlebox may well be aware of this). Regards, Alan From olivier.bonaventure@uclouvain.be Thu Nov 12 00:10:21 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D0A3A6A40 for ; Thu, 12 Nov 2009 00:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKFa67wJDgae for ; Thu, 12 Nov 2009 00:10:19 -0800 (PST) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 4961C3A6A24 for ; Thu, 12 Nov 2009 00:10:19 -0800 (PST) Received: from mbpobo.local (ip-80-236-231-212.dsl.scarlet.be [80.236.231.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 1C7B4E9244; Thu, 12 Nov 2009 09:10:45 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp1.sgsi.ucl.ac.be 1C7B4E9244 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1258013445; bh=ClRxeR2aDiaVh8kbdFt+w3CNxTyMqrhoWPTkfV8WhUw=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Iif5SEBfvlGBB6FTAHbKMIgrFj+pjxkp3HydZkfkLB2wKZvoygqgyFBZEZjkB6DW7 +m4dJ2FCQcfItCLATW3wpyXg7WIYXKUgXmQSHOCsw+o2WdxmgXgHEzj6UWVu+XmeoJ DLLRmH2LInyLnz3eKe5+sexPVdHDewsgY/bBGB0Y= Message-ID: <4AFBC301.5090000@uclouvain.be> Date: Thu, 12 Nov 2009 09:10:41 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "SCHARF, Michael" References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1C7B4E9244.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 12 Nov 2009 08:10:21 -0000 Michael, > > draft-scharf-mptcp-api-00 contains a list of potential requirements on > the MPTCP API towards application. This list is of course just a > starting point. Currently, it is certainly not complete and may also > include requirements that will be removed in later stage, once the MPTCP > architecture spec evolves. I am frightened by the long list of requirements and I fear that this would make the API far too complex. The layering principle tells us that we need to hide some of the details of the underlying layer to the upper layer and experience should that this works well in practice. To take an analogy, let's look at how the socket API evolved with changes in TCP such as the introduction of congestion control, the fats retransmit, the selective acks, timers computations, ... All of these mechanisms have changed the behaviour of the TCP stack and its reaction against losses but we never had to update the API to reflect this. > REQ1: Turn on/off MPTCP: An application should be able to request > to turn on or turn off the usage of MPTCP. This means that > an application should be able to explicitly request the use > of MPTCP if this is possible. Applications should also be > able to request not to enable MPTCP and to use regular TCP > transport instead. (This can be implicit in many cases, > e.g., by the use of binding to a specific address versus all > addresses). I would love to have a higher layer API where the application indicates that it needs a reliable delivery and the stack chooses the most appropriate transport protocol (tcp, sctp, mtcp, ...) automatically. This would allow the application and the transport to evolve independently. > REQ2: An application will want to be able to restrict MPTCP to > binding to a given set of addresses or interfaces. why ? > REQ3: An application should be able to know if multiple subflows > are in use. why ? today's application do not ask whether there have been retransmissions > REQ4: An application should be able to extract a unique identifier > for the connection (per endpoint), analogous to a port, i.e. > it should be able to retrieve MPTCP's connection identifier. this looks reasonable > REQ5: An application should be able to enumerate all subflows in > use, obtain information on the addresses used by a subflow, > and obtain a subflow's usage (e.g., ratio of traffic sent via > this subflow). why ? today's application do not ask whether there have been retransmissions > REQ6: Set/get application profile, as discussed in the previous > section. remember that for intserv we almost never managed to have application developers define their QoS requirements > REQ7: Constrain the maximum number of subflows to be used by an > MPTCP connection. (Or just infer from application profile?) the stack should do this automatically > REQ8: Request a change in scheduling between subflows? (i.e. a more > granular version of application profile?) why ? today's applications do not set for example the MSS to be used > REQ9: Request a change in the number of subflows in use, thus > triggering removal or addition of subflows. (A finer control > granularity would be: Request the establishment of a new > subflow to a provided destination, and request the > termination of a specified, existing subflow.) this is the job of the tcp implementation, not the application > REQ10: Control automatic establishment/termination of subflows? > There could be different configurations of the path manager, > e.g., 'try ASAP', 'wait until there is a bunch of data, etc. > (Tied to application profile?) i don't see why an application should want to do this > REQ11: Set/get preferred subflows or subflow usage policies? There > could be different configurations of the multipath scheduler, > e.g., 'all-or-nothing', 'overflow', etc. (Again, tied to > application profile). > > REQ12: Set/get sporadic sending of segments on unused paths > ("keepalives"). no > REQ13: An application should be able to modify the MPTCP > configuration while communication is ongoing, i.e., after > establishment of the MPTCP connection. we should have as few mptcp configuration as possible, otherwise pmtcp will be too complex for the application developers Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From alan.ford@roke.co.uk Thu Nov 12 01:56:57 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190C33A68B9 for ; Thu, 12 Nov 2009 01:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNhGjc9yBJgH for ; Thu, 12 Nov 2009 01:56:56 -0800 (PST) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id C4D683A680F for ; Thu, 12 Nov 2009 01:56:55 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nAC9vDRI029963; Thu, 12 Nov 2009 09:57:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 09:57:07 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7C0E2@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <4AFBC301.5090000@uclouvain.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Initial ideas for API requirements Thread-Index: Acpjb7mby6UhRcSoTUGCEB8XipcNVgADQmJQ References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> From: "Ford, Alan" To: , "SCHARF, Michael" X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 09:56:57 -0000 Hi Olivier, Thanks for feedback. The purpose of this list of requirements is to generate exactly this discussion :) > I am frightened by the long list of requirements and I fear that this > would make the API far too complex. The layering principle tells us that > we need to hide some of the details of the underlying layer to the upper > layer and experience should that this works well in practice. Agreed. However, there are two strands we need to consider when defining this API: 1. Ensuring the same control as is provided for TCP is also provided for MPTCP 2. Allowing an application to exploit some of the _key beneficial features_ of MPTCP. > To take an analogy, let's look at how the socket API evolved with > changes in TCP such as the introduction of congestion control, the fats > retransmit, the selective acks, timers computations, ... All of these > mechanisms have changed the behaviour of the TCP stack and its reaction > against losses but we never had to update the API to reflect this. A good analogy, yes. > > REQ1: Turn on/off MPTCP: An application should be able to request > > to turn on or turn off the usage of MPTCP. This means that > > an application should be able to explicitly request the use > > of MPTCP if this is possible. Applications should also be > > able to request not to enable MPTCP and to use regular TCP > > transport instead. (This can be implicit in many cases, > > e.g., by the use of binding to a specific address versus all > > addresses). >=20 > I would love to have a higher layer API where the application indicates > that it needs a reliable delivery and the stack chooses the most > appropriate transport protocol (tcp, sctp, mtcp, ...) automatically. > This would allow the application and the transport to evolve independently. There several issues here. One is for a MPTCP-aware application to request the use of Multipath. Pasi's suggestion of AF_INETMP or similar would seem a possibly solution to this. The next is for a MPTCP-aware application to request NOT to use MPTCP. Here, the use of AF_INET / AF_INET6 would not be sufficient, since how would the API tell the difference between this and a non-MPTCP-aware application?=20 So we probably need another call for MPTCP-aware apps. Hmm. If we accept this as a requirement, anyway. > > REQ2: An application will want to be able to restrict MPTCP to > > binding to a given set of addresses or interfaces. >=20 > why ? Analogous to TCP (binding to a given address, or SO_BINDTODEVICE). Just needs to be able to cope with >1 interface/address! > > REQ3: An application should be able to know if multiple subflows > > are in use. >=20 > why ? today's application do not ask whether there have been retransmissions >=20 > > REQ4: An application should be able to extract a unique identifier > > for the connection (per endpoint), analogous to a port, i.e. > > it should be able to retrieve MPTCP's connection identifier. >=20 > this looks reasonable >=20 > > REQ5: An application should be able to enumerate all subflows in > > use, obtain information on the addresses used by a subflow, > > and obtain a subflow's usage (e.g., ratio of traffic sent via > > this subflow). >=20 > why ? today's application do not ask whether there have been retransmissions Combining REQ3 & REQ5, probably all we need is the ability to get the list of address pairs in use. This is analogous to getpeername() and getsockname(). > > REQ6: Set/get application profile, as discussed in the previous > > section. >=20 > remember that for intserv we almost never managed to have application > developers define their QoS requirements However, in MPTCP this does make a _real_ difference. This is not simply a case of saying "do I want the best QoS or not the best QoS" (for which there's no wonder an application always says they want the best). This is a case of "do I want throughput, or reduced jitter" for example. > > REQ7: Constrain the maximum number of subflows to be used by an > > MPTCP connection. (Or just infer from application profile?) >=20 > the stack should do this automatically Yep, and the profile could definitely influence this. > we should have as few mptcp configuration as possible, otherwise pmtcp > will be too complex for the application developers Agree to some extent. We don't want it so automatic, so inflexible, that application developers (and of course users) don't find it sufficiently beneficial to use. Regards, Alan From caozhenpku@gmail.com Thu Nov 12 03:08:55 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D613A6A4E for ; Thu, 12 Nov 2009 03:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSkWcw2VOzfh for ; Thu, 12 Nov 2009 03:08:54 -0800 (PST) Received: from mail-px0-f197.google.com (mail-px0-f197.google.com [209.85.216.197]) by core3.amsl.com (Postfix) with ESMTP id 7EF6F3A6920 for ; Thu, 12 Nov 2009 03:08:54 -0800 (PST) Received: by pxi35 with SMTP id 35so1584881pxi.18 for ; Thu, 12 Nov 2009 03:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KPsHVM8h0B33+0P6Md/kAox7xG5wyUO/Ots1j/Q91YA=; b=FdBy5Yb08Emhq69bDB3gJTHhpdL6LheuOyJL32kTmAb0p1wW/MVhnNv+oV4sZwGuTF JH29W4E33huoYp31G6X5qFvU3YuCcH8TgqGyPyFCTnGrudRGtObxVlDNhMPZtL+w9uOj /jJePf1Pg9/yPd+QgPbzwU4sPsXk5bw0nG4gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GfTGsp6Et4W3NNOMFvN4vJhe9IrA78N4q9wqljlU/Al6ePry2wCmUk2UyVX4SQMFOc 9vU+tG/Jc59y6t86u1OdAVreGeQhul9SG2CoYaUWdRB7qj2BRAipzHE0+5+EIAiC4gDB Qy3FQq4H9Fr2vs+qXv+DK/zydEd06pAXjQjeI= MIME-Version: 1.0 Received: by 10.142.9.11 with SMTP id 11mr308996wfi.101.1258024160153; Thu, 12 Nov 2009 03:09:20 -0800 (PST) In-Reply-To: <4AFBC301.5090000@uclouvain.be> References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> Date: Thu, 12 Nov 2009 19:09:20 +0800 Message-ID: From: Zhen Cao To: Olivier.Bonaventure@uclouvain.be Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org, "SCHARF, Michael" Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 11:08:55 -0000 On Thu, Nov 12, 2009 at 4:10 PM, Olivier Bonaventure wrote: > > To take an analogy, let's look at how the socket API evolved with > changes in TCP such as the introduction of congestion control, the fats > retransmit, the selective acks, timers computations, ... All of these > mechanisms have changed the behaviour of the TCP stack and its reaction > against losses but we never had to update the API to reflect this. > My concern is, if we update the stack to support new features like mptcp, everything on the application level will be changed even if they do not want to use mptcp. >> =A0 =A0REQ7: =A0 Constrain the maximum number of subflows to be used by = an >> =A0 =A0 =A0 =A0 =A0 =A0MPTCP connection. =A0(Or just infer from applicat= ion profile?) > > the stack should do this automatically > why ? today's applications do not set for example the MSS to be used > >> =A0 =A0REQ9: =A0 Request a change in the number of subflows in use, thus >> =A0 =A0 =A0 =A0 =A0 =A0triggering removal or addition of subflows. =A0(A= finer control >> =A0 =A0 =A0 =A0 =A0 =A0granularity would be: Request the establishment o= f a new >> =A0 =A0 =A0 =A0 =A0 =A0subflow to a provided destination, and request th= e >> =A0 =A0 =A0 =A0 =A0 =A0termination of a specified, existing subflow.) > > this is the job of the tcp implementation, not the application Implementation can do the job, and if we export these implementation to the application by a new set of APIs, developers will benefit from it. Thanks, -Zhen China Mobile From wherrin@gmail.com Thu Nov 12 05:15:17 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F57A3A6903 for ; Thu, 12 Nov 2009 05:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLH9Q1p0VJ7F for ; Thu, 12 Nov 2009 05:15:16 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 697E23A6937 for ; Thu, 12 Nov 2009 05:15:16 -0800 (PST) Received: by fxm7 with SMTP id 7so2226322fxm.29 for ; Thu, 12 Nov 2009 05:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=guE9GqG6bhhz/ppLv7PCIw0C3bUm9Jllf0uEmrJ/b0o=; b=faJeTZ9xCT7AwuPa6jjvkcbyq2MOOuEfqipgUKZOrTqQBcj4COFHVHnrQQFrUWAAww 6v1SUd7zg4N6MbEdLcDFobOk8FUFwZlShlxo5HDzZWfZ0pbTS+IIoNFbphaVuhx5TlNR y1J9z0+73Z7GNKALJqzNDikt736HX7r3mjzKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=mItCB9pi5FwcZqcp7qNIX5I4/7K7CaIvYAV+kflLdcRhF/WJ/MMo6cuWuv+20cTw4O 1DoPOJBLQJbVW52nIaffz6TotTF/7LGicFmXaC0F6NlNG69zP7/2i4V7V1lXaH5s1dAy ZlMWdLj5Kd99a/2UteS9KBOWtqg6bkO2RYDAs= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.89.9 with SMTP id b9mr899233wef.61.1258031741173; Thu, 12 Nov 2009 05:15:41 -0800 (PST) In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808D7C070@rsys005a.comm.ad.roke.co.uk> References: <4AF8B8A5.4040602@ismailov.eu> <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911101220g55f84f79nf62526d8693d39fa@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808D7BDEE@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911111737t5c783bf7rb96f49bb15f360e3@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808D7C070@rsys005a.comm.ad.roke.co.uk> Date: Thu, 12 Nov 2009 08:15:41 -0500 X-Google-Sender-Auth: b0e057315d82a95a Message-ID: <3c3e3fca0911120515u642a549bke68a789298fae056@mail.gmail.com> From: William Herrin To: "Ford, Alan" Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] The point about multiple listening sockets at theclient side X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 13:15:17 -0000 On Thu, Nov 12, 2009 at 2:27 AM, Ford, Alan wrote: >> TS: TCP SYN-SYN/ACK-ACK from the server to the client which includes >> the multipath TCP subflow join option. >> >> MJ: TCP packet without SYN but containing the multipath TCP join >> option and expecting the same sort of JOIN-JOIN/ACK-ACK handshake. >> >> Scenarios: >> >> No firewall: TS succeeds. MJ succeeds. >> Packet filter: TS fails. SYN to a random client port? Don't think so! >> MJ succeeds. >> Legacy Stateful firewall: TS fails. MJ fails. >> Legacy "DSL router": TS fails. MJ fails. >> Multipath-aware stateful firewall: TS fails. SYN to a random client >> port? Bad plan! MJ succeeds. >> Multipath-aware "DSL router": TS fails. SYN to a random client port? >> Come on! MJ succeeds. > > So the only cases here where TS != MJ is when you're talking about > Multipath-aware routers or firewalls? Hi Alan, No, basic packet filtering firewalls too. The ones we'll all move to instead of NAT firewalls if the IPv6 folks get their way. The point you were supposed to take is that NONE of the firewalled cases can be reasonably expected to handle an inbound join in a TCP SYN while MANY can be expected to handle an inbound subflow creation crafted without using a SYN packet. In fairness, that was mistaken. There is actually ONE firewalled case where the TCP SYN version can be expected to suceed as well: Multipath-aware proxy firewall: TS succeeds. MJ succeeds. The proxy firewall isn't passing the raw SYN packet back to the client; he's handling it himself. So in that one firewalled case, the TCP SYN version can be expected to succeed. > In order for them to let through > MJ they need the existence of the Join option to override the natural > rejection of such a packet due to coming from an unknown address. In > which case, they could do the same for TS! But they won't, because TCP SYN has unacceptable security implications that a packet which contains a join option without setting the syn flag does not. What it boils down to is this: if there's the slightest chance that a bad actor crafting custom packets could establish a *non-multipath* TCP connection, it won't be allowed through the firewall. In fact, if it so much as complicates the code which has to make the decision about basic SYN packets, it won't be allowed through the firewall because of the risk of introducing a security bug. Even with MJ we'll have to do a thorough security analysis to make the case that the packet is completely harmless if sent to a non-multipath host. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Thu Nov 12 07:21:19 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10753A691F for ; Thu, 12 Nov 2009 07:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1mAUb55q6gv for ; Thu, 12 Nov 2009 07:21:18 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 5528728C12C for ; Thu, 12 Nov 2009 07:21:18 -0800 (PST) Received: by fxm7 with SMTP id 7so2363840fxm.29 for ; Thu, 12 Nov 2009 07:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=4Y79Q6aO1LpSn9C64woeBmDcJnQxfNBEAaqPu4AT94E=; b=IsuhKEREhgjjj4lUgbWTXpttH/CHEXdT431SjPpmaWqEcEnXIRUclCNu6jNWhpg4ss jWTFRldYzqywwu73SxyJq0EUHPDPrRk1clXsmJZRDp6ZxjEcyHavHb4Qi6Egz/2vnGmH bnCBAXhmb9H9EXwCSyUxPWK6cw+hj43r+7z5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=k4Y0Cw9ArYBWcfWfLGd9mqsUwLWCxo9zl0xv0dwu0xcA0JUXDsGdnUuNqGFTTHR4X7 96EeaZ1kolQ6vaMFSrChWbLmhazLRzZCTthISPR93/CFaSrd8qB+m06nxA/5LS+sKyJO it8JNwk/0zfPeLF8jcJgwIJZyxI/lCENhZbrA= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.93.74 with SMTP id k52mr951716wef.144.1258039302152; Thu, 12 Nov 2009 07:21:42 -0800 (PST) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> Date: Thu, 12 Nov 2009 10:21:42 -0500 X-Google-Sender-Auth: d16481ba3840838c Message-ID: <3c3e3fca0911120721i6ac25c84n62fbceefe4f0365c@mail.gmail.com> From: William Herrin To: "SCHARF, Michael" Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 15:21:19 -0000 On Wed, Nov 11, 2009 at 9:33 PM, SCHARF, Michael wrote: > REQ3: An application should be able to know if multiple subflows > are in use. > > REQ4: An application should be able to extract a unique identifier > for the connection (per endpoint), analogous to a port, i.e. > it should be able to retrieve MPTCP's connection identifier. > > REQ5: An application should be able to enumerate all subflows in > use, obtain information on the addresses used by a subflow, > and obtain a subflow's usage (e.g., ratio of traffic sent via > this subflow). Hi Michael, Specific items the application may want to know: 1. Whether multipath was negotiated, regardless of the number of subflows currently in use. 2. Both endpoint connection IDs if multipath is negotiated. Primarily for logging and matching your logs to the remote or middlebox's logs. 3. Classic TCP connection IDs (2xIP,2xport) if multipath is not negotiated. 4. What are the local and remote candidate addresses for subflows? Not just the ones in use, the ones that might be used. Are 3 and 4 the same call that returns a variable size structure? Or are they different calls that the app has to be aware of? 5. What are the actual subflows in use? 6. Subflow characteristics such as retransmitted packet count, total packet count, delay characteristics. Also, for each of these items, WHEN do you tell the application? Upon connection startup only? Upon request by the application? With a callback as they change? All of the above? > REQ12: Set/get sporadic sending of segments on unused paths > ("keepalives"). Is there a reason to do this in the extended API instead of the current API? Put another way, why would we want keepalives on only chosen subflows instead of all of them? > REQ13: An application should be able to modify the MPTCP REQ14: multiply addressed connect. Should be able to pass a list of addresses to connect() instead of just one so that MPTCP can implement a reasonable degree of parallelism when establishing the initial connection. The whole "wait for connect to address A to time out, cancel it and then try address B" deal that applications do now would be suboptimal in an MPTCP scenario. REQ15: connect by destination hostname. Not only does this avoid making every single application developer reinvent the wheel, it also enables: * MPTCP to re-find the destination out of band should all known addresses fail while the connection is active. * MPTCP apps to seamlessly handle future successor protocols to IPv6 by not requiring the app to understand their address formats. And if this means apps actually honor the DNS TTL, that'd be a bonus. REQ16: set source hostname. Same as 15 but allows the connection's acceptor to re-find the initiator. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From olivier.bonaventure@uclouvain.be Thu Nov 12 08:26:14 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562E63A689B for ; Thu, 12 Nov 2009 08:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1l6isIDnetE for ; Thu, 12 Nov 2009 08:26:13 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id D91333A6985 for ; Thu, 12 Nov 2009 08:26:12 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B246BF2469; Thu, 12 Nov 2009 17:26:43 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be B246BF2469 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1258043203; bh=Bx9dT3AhmJcsmFV5dJYywMH3xzTtF2Awlmvf4i+7b8w=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aDT2iVYZtMjIPKOTQVY5R8V6Rgxzu7f/Ocr44rNxindxdPM2eFNs2TEFxBQZC7CAb bdTZC5z1M/zDwOq98EnmwsAm9clohx7qphbTu542qKZ+88e/KX480humQFfokKBN6b qyB1OOF/46hpKsV79BHRJWheynDYLFKAvBmBl370= Message-ID: <4AFC3739.6010502@uclouvain.be> Date: Thu, 12 Nov 2009 17:26:33 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Ford, Alan" References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> <2181C5F19DD0254692452BFF3EAF1D6808D7C0E2@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808D7C0E2@rsys005a.comm.ad.roke.co.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: B246BF2469.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org, "SCHARF, Michael" Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 12 Nov 2009 16:26:14 -0000 Alan, > >>> REQ1: Turn on/off MPTCP: An application should be able to > request >>> to turn on or turn off the usage of MPTCP. This means > that >>> an application should be able to explicitly request the > use >>> of MPTCP if this is possible. Applications should also > be >>> able to request not to enable MPTCP and to use regular > TCP >>> transport instead. (This can be implicit in many cases, >>> e.g., by the use of binding to a specific address versus > all >>> addresses). >> I would love to have a higher layer API where the application > indicates >> that it needs a reliable delivery and the stack chooses the most >> appropriate transport protocol (tcp, sctp, mtcp, ...) automatically. >> This would allow the application and the transport to evolve > independently. > > There several issues here. > > One is for a MPTCP-aware application to request the use of Multipath. > Pasi's suggestion of AF_INETMP or similar would seem a possibly solution > to this. The next is for a MPTCP-aware application to request NOT to use > MPTCP. Here, the use of AF_INET / AF_INET6 would not be sufficient, > since how would the API tell the difference between this and a > non-MPTCP-aware application? I would suggest to have mtcp on by default and an option to disable it if required by the application. Most applications don't care of their data is transported to the destination, the only issue for them is that the data must reach the destination reliably. > So we probably need another call for MPTCP-aware apps. Hmm. If we accept > this as a requirement, anyway. > >>> REQ2: An application will want to be able to restrict MPTCP to >>> binding to a given set of addresses or interfaces. >> why ? > > Analogous to TCP (binding to a given address, or SO_BINDTODEVICE). Just > needs to be able to cope with >1 interface/address! maybe this could be useful on some multihomed hosts >>> REQ3: An application should be able to know if multiple > subflows >>> are in use. >> why ? today's application do not ask whether there have been > retransmissions >>> REQ4: An application should be able to extract a unique > identifier >>> for the connection (per endpoint), analogous to a port, > i.e. >>> it should be able to retrieve MPTCP's connection > identifier. >> this looks reasonable >> >>> REQ5: An application should be able to enumerate all subflows > in >>> use, obtain information on the addresses used by a > subflow, >>> and obtain a subflow's usage (e.g., ratio of traffic sent > via >>> this subflow). >> why ? today's application do not ask whether there have been > retransmissions > > Combining REQ3 & REQ5, probably all we need is the ability to get the > list of address pairs in use. This is analogous to getpeername() and > getsockname(). i don't think that application needs more than this >>> REQ6: Set/get application profile, as discussed in the previous >>> section. >> remember that for intserv we almost never managed to have application >> developers define their QoS requirements > > However, in MPTCP this does make a _real_ difference. This is not simply > a case of saying "do I want the best QoS or not the best QoS" (for which > there's no wonder an application always says they want the best). This > is a case of "do I want throughput, or reduced jitter" for example. i'm not convinced that application developpers will want to deal with these details. We need to keep the API as simple as possible (and perhaps simpler than that) >>> REQ7: Constrain the maximum number of subflows to be used by an >>> MPTCP connection. (Or just infer from application > profile?) >> the stack should do this automatically > > Yep, and the profile could definitely influence this. For me, profile is similar to traffic contract in intserv, I don't expect that many applications will define their profile. Most applications will use the default profile and this what we should optimise >> we should have as few mptcp configuration as possible, otherwise pmtcp >> will be too complex for the application developers > > Agree to some extent. We don't want it so automatic, so inflexible, that > application developers (and of course users) don't find it sufficiently > beneficial to use. We want a multipath tcp that works for 99% of applications. Some applications implement a transport protocol inside the application, but these applications are very rare and we should not optimise mptcp for the needs of such applications since anyway they will implement complex stuff in the application layer Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From olivier.bonaventure@uclouvain.be Thu Nov 12 08:31:06 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4E53A682D for ; Thu, 12 Nov 2009 08:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xspYAl8ngvrp for ; Thu, 12 Nov 2009 08:31:05 -0800 (PST) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 37B5F3A6A6C for ; Thu, 12 Nov 2009 08:31:04 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 66B38E93F3; Thu, 12 Nov 2009 17:31:21 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp1.sgsi.ucl.ac.be 66B38E93F3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1258043481; bh=dJZj/vO2rQNBUFCZkjy/udVlrKaTlDwJAxHyCl3yZ1I=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TIsTPxgySVTIsMxz8pCwtzv7JgNFshIbLuFb6qopehLB97KkL2t8L7f8rriqSJYLE RLp2dv4XPhY/cPb8qIXumpz+nq3KnjCIH+uSuQubX8Ta9R4K6d5VStmPmXSp/P5E7f Hd91W6IKUtGUL5jKpgFeWW3nrpjx9xXf3P/IGAWA= Message-ID: <4AFC3855.2050404@uclouvain.be> Date: Thu, 12 Nov 2009 17:31:17 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Zhen Cao References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 66B38E93F3.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org, "SCHARF, Michael" Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 12 Nov 2009 16:31:06 -0000 Zhen, > On Thu, Nov 12, 2009 at 4:10 PM, Olivier Bonaventure > wrote: >> To take an analogy, let's look at how the socket API evolved with >> changes in TCP such as the introduction of congestion control, the fats >> retransmit, the selective acks, timers computations, ... All of these >> mechanisms have changed the behaviour of the TCP stack and its reaction >> against losses but we never had to update the API to reflect this. >> > > My concern is, if we update the stack to support new features like > mptcp, everything on the application level will be changed even if > they do not want to use mptcp. REQ0 should be that an existing application can benefit from MPTCP without any change to its code. If we force an application to change to support MPTCP, we'll have the same problem to find applications as stcp and ipv6 in the past >>> REQ7: Constrain the maximum number of subflows to be used by an >>> MPTCP connection. (Or just infer from application profile?) >> the stack should do this automatically >> why ? today's applications do not set for example the MSS to be used >> >>> REQ9: Request a change in the number of subflows in use, thus >>> triggering removal or addition of subflows. (A finer control >>> granularity would be: Request the establishment of a new >>> subflow to a provided destination, and request the >>> termination of a specified, existing subflow.) >> this is the job of the tcp implementation, not the application > > Implementation can do the job, and if we export these implementation > to the application by a new set of APIs, developers will benefit from > it. We should maintain a good separation between the layers. We do not expose to applications protocol issues such as MSS, retransmission mechanisms, congestion control mechanism, ... For me, the number of subflows is equivalent to the congestion control and the retransmission mechanisms that are used by TCP today. These improve the performance, but the service provided to the application is still a reliable byte stream. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From jta@fe.up.pt Thu Nov 12 17:47:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418BA28B56A for ; Thu, 12 Nov 2009 17:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D57y8+S22N1G for ; Thu, 12 Nov 2009 17:47:39 -0800 (PST) Received: from dax.ee.ucl.ac.uk (dax.ee.ucl.ac.uk [128.40.42.12]) by core3.amsl.com (Postfix) with ESMTP id 4B7E528C0D6 for ; Thu, 12 Nov 2009 17:47:39 -0800 (PST) Received: from [133.93.25.102] (host-25-102.meeting.ietf.org [133.93.25.102]) (authenticated bits=0) by dax.ee.ucl.ac.uk (8.13.8/8.13.8) with ESMTP id nAD1llGe004131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2009 01:47:56 GMT Message-ID: <4AFCBAC0.1030403@fe.up.pt> Date: Fri, 13 Nov 2009 01:47:44 +0000 From: =?ISO-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= Organization: UCL User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> <4AFC3855.2050404@uclouvain.be> In-Reply-To: <4AFC3855.2050404@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UCL_EE-MailScanner-Information: Please contact mailhelp@ee.ucl.ac.uk for more information X-MailScanner-ID: nAD1llGe004131 X-UCL_EE-MailScanner: Found to be clean X-UCL_EE-MailScanner-From: jta@fe.up.pt Cc: multipathtcp@ietf.org, "SCHARF, Michael" Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.araujo@ucl.ac.uk List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 01:47:40 -0000 Olivier, Olivier Bonaventure wrote: >> My concern is, if we update the stack to support new features like >> mptcp, everything on the application level will be changed even if >> they do not want to use mptcp. >> > > REQ0 should be that an existing application can benefit from MPTCP > without any change to its code. > > If we force an application to change to support MPTCP, we'll have the > same problem to find applications as stcp and ipv6 in the past > This is an oversimplification. MPTCP looks like standard TCP from the perspective of any middlebox, and therefore is inherently deployable. The same can't be said of sctp or ipv6. The fork in the road seems to be that if you masquerade MPTCP as a standard TCP socket for legacy apps, you might break prevailing assumptions. In my mind there is no reason why apps which gain the most benefit (bulk data, mobility, redundancy) would be hesitant in upgrading once OS support is in place. Joao. From scott.brim@gmail.com Thu Nov 12 18:11:48 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEAFA3A6977 for ; Thu, 12 Nov 2009 18:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+HW2ytXMhpw for ; Thu, 12 Nov 2009 18:11:47 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 49D273A6B2E for ; Thu, 12 Nov 2009 18:11:47 -0800 (PST) Received: by yxe30 with SMTP id 30so3058049yxe.29 for ; Thu, 12 Nov 2009 18:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=DeSqTZosU2vEX8dP3gy+DOdTLCtsJoddnvfmV+bTGbE=; b=QljjGb+/sJ5r6U+OzW2ozPPwInljA2Me5g1ew8RhqOFW81399hbmEyNjcUqKpkGoyZ ajFXdlsHxfaCCNCqFeO6sPtEhBBpIRRPua1s9xGX/H0/fwDHPTvXFa38J4w14VS1bMrI a7xnAuPBtZHTMRA+D5QEfGS4j0c3FbWoZZPMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=teOlRR7xeryDRznCfSTir9EdcUBVIhACdgVcIZrYO6NNS41BEEZznr40E/v+ROCbZd HsJiqWBr281Drsw0KA8L/C5c4TOdRq8o1CvGuHnsQc77cVqam0tReBSv/R5ToJoE9U8O F/7WF8Ds3KYdLijJvx03aNsMzg2HYImeHtp6w= Received: by 10.151.18.19 with SMTP id v19mr6717282ybi.66.1258078333505; Thu, 12 Nov 2009 18:12:13 -0800 (PST) Received: from host-24-56.meeting.ietf.org (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 20sm1251088ywh.17.2009.11.12.18.12.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Nov 2009 18:12:12 -0800 (PST) Message-ID: <4AFCC077.9060103@gmail.com> Date: Fri, 13 Nov 2009 11:12:07 +0900 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> In-Reply-To: <4AFBC301.5090000@uclouvain.be> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org, "SCHARF, Michael" Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 02:11:48 -0000 Olivier Bonaventure allegedly wrote on 11/12/2009 5:10 PM: > I am frightened by the long list of requirements and I fear that this > would make the API far too complex. The layering principle tells us that > we need to hide some of the details of the underlying layer to the upper > layer and experience should that this works well in practice. > > To take an analogy, let's look at how the socket API evolved with > changes in TCP such as the introduction of congestion control, the fats > retransmit, the selective acks, timers computations, ... All of these > mechanisms have changed the behaviour of the TCP stack and its reaction > against losses but we never had to update the API to reflect this. Olivier, at a meta-level we want to expose _more_ details of transport to the application, not less. Having Transport treat the application as if it were a child is just like having the network treat the endpoint as if it were a child. Just because capabilities are available in an API doesn't mean every app needs to use them. We can have reasonable defaults, or "unspecified" could mean that Transport should do what it thinks best. This is essentially what will happen with the old socket API in any case. Regards ... Scott From scott.brim@gmail.com Thu Nov 12 18:13:53 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A742A3A6881 for ; Thu, 12 Nov 2009 18:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUzdleDIzQ0d for ; Thu, 12 Nov 2009 18:13:52 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 52EC53A67B1 for ; Thu, 12 Nov 2009 18:13:52 -0800 (PST) Received: by yxe30 with SMTP id 30so3059529yxe.29 for ; Thu, 12 Nov 2009 18:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=2Dt6dC9edV1n6fTBb6YrqBP2yd8gVZEdy/RIDuNhUgo=; b=ocqmAXqTjjlm2lrrvV9plICwUUJ1q3QBOSEEF98m+N1tZ0a5GGzlBmvTuoA2VWHWbp XE2gGLPHE4xGUon3ruukQfEc7u+qpCFXACKS/YYtXpnnjDOnKMTzGr3F/my+TYwlOSN4 thafbEmhE8Gg5v5kQeeaNLa71dptUtURQeSUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=wGbJJan2JDfjjZTWqGvFLg1nh7TN9t0rIjZgVL22hYRgoT0GuGuZG/qaLrMWf+YIwm eHyEQruC8vq32abw+0j5ylQZuRxR35uWGn74nsTtFguTWd6bzSdRW7f4ewepeqyVH4Ms tgQTwgAVqiQPwi242r7A6Fd+1OFB1KuFZooKM= Received: by 10.150.112.39 with SMTP id k39mr6664200ybc.157.1258078459036; Thu, 12 Nov 2009 18:14:19 -0800 (PST) Received: from host-24-56.meeting.ietf.org (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 5sm164553ywd.8.2009.11.12.18.14.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Nov 2009 18:14:18 -0800 (PST) Message-ID: <4AFCC0F5.5070203@gmail.com> Date: Fri, 13 Nov 2009 11:14:13 +0900 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: j.araujo@ucl.ac.uk References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> <4AFC3855.2050404@uclouvain.be> <4AFCBAC0.1030403@fe.up.pt> In-Reply-To: <4AFCBAC0.1030403@fe.up.pt> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: multipathtcp@ietf.org, "SCHARF, Michael" , Olivier.Bonaventure@uclouvain.be Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 02:13:53 -0000 João Taveira Araújo allegedly wrote on 11/13/2009 10:47 AM: > This is an oversimplification. MPTCP looks like standard TCP from the > perspective of any middlebox, and therefore is inherently deployable. Well, except for an extra option, and changes in higher layer packet flow (some middleboxes might not like either of these). swb From olivier.bonaventure@uclouvain.be Fri Nov 13 00:36:58 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCDB3A6911 for ; Fri, 13 Nov 2009 00:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoGwmP+0kAuh for ; Fri, 13 Nov 2009 00:36:57 -0800 (PST) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 83E883A67C1 for ; Fri, 13 Nov 2009 00:36:57 -0800 (PST) Received: from mbpobo.local (ip-80-236-231-136.dsl.scarlet.be [80.236.231.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3BF45E8B98; Fri, 13 Nov 2009 09:37:24 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp1.sgsi.ucl.ac.be 3BF45E8B98 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1258101444; bh=Q8HtmUTH58lf4e8zmmE9nzMrFzzJyRqpHVNrY4k7zkw=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qEHNLmofSr5WKGw+Z5JTihEI2or9DzmMJ9W0O+N6YKEw78lhqga0DldVGl8jrX2Lm eQH4EU5q3YfasFWdb+QF8v0WTue8Ff/0/KARQl0RDpHLkRqSn1mxJXF0nCDK5tvCZe hjBmI1DJ7MjxGfcLFDi6WY/ZFlPW5sbKeXDCIhzI= Message-ID: <4AFD1AC2.8080606@uclouvain.be> Date: Fri, 13 Nov 2009 09:37:22 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: William Herrin References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <3c3e3fca0911120721i6ac25c84n62fbceefe4f0365c@mail.gmail.com> In-Reply-To: <3c3e3fca0911120721i6ac25c84n62fbceefe4f0365c@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 3BF45E8B98.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org, "SCHARF, Michael" Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 13 Nov 2009 08:36:59 -0000 William, > On Wed, Nov 11, 2009 at 9:33 PM, SCHARF, Michael > wrote: >> REQ3: An application should be able to know if multiple subflows >> are in use. >> >> REQ4: An application should be able to extract a unique identifier >> for the connection (per endpoint), analogous to a port, i.e. >> it should be able to retrieve MPTCP's connection identifier. >> >> REQ5: An application should be able to enumerate all subflows in >> use, obtain information on the addresses used by a subflow, >> and obtain a subflow's usage (e.g., ratio of traffic sent via >> this subflow). > > Hi Michael, > > Specific items the application may want to know: > > 1. Whether multipath was negotiated, regardless of the number of > subflows currently in use. Today, applications do not require to know whether rfc1323, sack or other TCP option shave been negotiated on a given TCP connection. > 2. Both endpoint connection IDs if multipath is negotiated. Primarily > for logging and matching your logs to the remote or middlebox's logs. > > 3. Classic TCP connection IDs (2xIP,2xport) if multipath is not negotiated. > > 4. What are the local and remote candidate addresses for subflows? Not > just the ones in use, the ones that might be used. > > Are 3 and 4 the same call that returns a variable size structure? Or > are they different calls that the app has to be aware of? We need to distinguish between information that the application needs to know for each TCP connection and debugging information that we need. To take a common problem, consider PathMTU discovery. Some firewalls block ICMP messages and this breaks PathMTU discovery. These problems are debugged by the network administrators without requiring any change to application and without needing to extend the applications to deal with these problems. > 5. What are the actual subflows in use? > > 6. Subflow characteristics such as retransmitted packet count, total > packet count, delay characteristics. This is clearly something that the application does not need from an API. > Also, for each of these items, WHEN do you tell the application? Upon > connection startup only? Upon request by the application? With a > callback as they change? All of the above? > > >> REQ12: Set/get sporadic sending of segments on unused paths >> ("keepalives"). > > Is there a reason to do this in the extended API instead of the > current API? Put another way, why would we want keepalives on only > chosen subflows instead of all of them? keepalives are handled by the transport protocol internally, they do not need to be exposed to the applications > >> REQ13: An application should be able to modify the MPTCP > > REQ14: multiply addressed connect. Should be able to pass a list of > addresses to connect() instead of just one so that MPTCP can implement > a reasonable degree of parallelism when establishing the initial > connection. The whole "wait for connect to address A to time out, > cancel it and then try address B" deal that applications do now would > be suboptimal in an MPTCP scenario. > > REQ15: connect by destination hostname. Not only does this avoid > making every single application developer reinvent the wheel, it also > enables: > * MPTCP to re-find the destination out of band should all known > addresses fail while the connection is active. > * MPTCP apps to seamlessly handle future successor protocols to IPv6 > by not requiring the app to understand their address formats. This looks reasonable to me. I would suggest Stuart Cheshire's presentation at IETF72as it contains useful info about API design issues http://www.stuartcheshire.org/IETF72/ Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From wherrin@gmail.com Fri Nov 13 17:42:53 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FF63A693B for ; Fri, 13 Nov 2009 17:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.017 X-Spam-Level: X-Spam-Status: No, score=0.017 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcVdEADQpq8o for ; Fri, 13 Nov 2009 17:42:52 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 51AD43A6931 for ; Fri, 13 Nov 2009 17:42:52 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1135603eyd.51 for ; Fri, 13 Nov 2009 17:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=5rdfJlfVZRDgxULLmg0iClEK1UGI5vCBSQMDqkeRsv0=; b=UeWrmPoxdAMC/ceRC2vwBbRiwwx/WwlBhnpUVaAW2dEUNCBB00nLbX/YtAFNJgatuK szTfEMf8cKYC0fwiqC2sHn6+HiIMz0W0Q864nFYFkiFKCSTWzDZR5kkAU7msT2Qht8XU kO7hWKGOMQAMQjTiF/aIQnekpvnhnC5h9hk54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DQ4wpXjpNrdANP9rUoykiRXTd38k7snj7YUcUkbDdx2Vocs7m31yva7kIdiAPIXBCQ npO7FPHlXd3nzD6HK1ZBR4l9v9tCtwD2CAl+jN1qjFH9Vs1BDlAX4nnQXiMDoi9FCBZq Yw/FbcoArUIHHivxTv3JyEVju5HPiWwvw+ryQ= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.93.77 with SMTP id k55mr1569692wef.196.1258162997417; Fri, 13 Nov 2009 17:43:17 -0800 (PST) In-Reply-To: <4AFD1AC2.8080606@uclouvain.be> References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <3c3e3fca0911120721i6ac25c84n62fbceefe4f0365c@mail.gmail.com> <4AFD1AC2.8080606@uclouvain.be> Date: Fri, 13 Nov 2009 20:43:17 -0500 X-Google-Sender-Auth: a47c6184450049e8 Message-ID: <3c3e3fca0911131743q1a003087m6142019be4b1790e@mail.gmail.com> From: William Herrin To: Olivier.Bonaventure@uclouvain.be Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org, "SCHARF, Michael" Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 01:42:54 -0000 On Fri, Nov 13, 2009 at 3:37 AM, Olivier Bonaventure wrote: >> Specific items the application may want to know: >> >> 1. Whether multipath was negotiated, regardless of the number of >> subflows currently in use. > > Today, applications do not require to know whether rfc1323, sack or > other TCP options have been negotiated on a given TCP connection. Hi Olivier, Let's look at it a different way: is there a reason that an application should be denied knowledge of whether multipath TCP was negotiated on a particular connection? The stack certainly knows, so it won't complicate any code if there's a getsockopt that reports whether multipath is in use, will it? >> 2. Both endpoint connection IDs if multipath is negotiated. Primarily >> for logging and matching your logs to the remote or middlebox's logs. >> >> 3. Classic TCP connection IDs (2xIP,2xport) if multipath is not negotiat= ed. >> >> 4. What are the local and remote candidate addresses for subflows? Not >> just the ones in use, the ones that might be used. >> >> Are 3 and 4 the same call that returns a variable size structure? Or >> are they different calls that the app has to be aware of? > > > We need to distinguish between information that the application needs to > know for each TCP connection and debugging information that we > need. Does the application need to know information that the user wants to know? The operator on the acceptor side wants to know who connected to him, for example. That isn't necessarily debug information. What about the javascript security issues that brought about DNS pinning in web browsers? Do we declare that out of bounds for TCP when multipath is operational? Or do we say: hey, that's a neat concept. We should continue support by allowing the app to know what candidate addresses were negotiated during the original HTTP connection so that the whole list can be used in subsequent HTTP connections? > To take a common problem, consider PathMTU discovery. > Some firewalls block ICMP messages and this breaks > PathMTU discovery. These problems are debugged by the network > administrators without requiring any change to application and > without needing to extend the applications to deal with these > problems. I would argue that TCP's PMTUD is one of the most broken things about TCP's current design. It isn't just badly behaving firewalls... There are any number of perfectly rational network designs in which there is a path between two endpoints but not necessarily paths between either endpoint and all intermediate routers. The TCP stack sits there like an idiot retransmitting a packet that never gets through but won't consider the possibility of an MTU problem unless triggered by the intermediate system. You should look at the grief the folks on the RRG went through with the various map-encap designs trying to assure that the intermediate tunnel encoders could successfully receive and translate a fragmentation-needed message, all because TCP breaks without it. Several nasty design constraints at the routing layer would vanish if TCP could identify the path MTU through packet loss without active notification of failure. At any rate, mutlipath TCP needs to be able to quickly determine that a subflow has failed, regardless of the behavior of intermediate systems. If it can't, we could end up with a level of reliability that's actually lower that TCP without multipath. >>> =A0 REQ12: =A0Set/get sporadic sending of segments on unused paths >>> =A0 =A0 =A0 =A0 =A0 ("keepalives"). >> >> Is there a reason to do this in the extended API instead of the >> current API? Put another way, why would we want keepalives on only >> chosen subflows instead of all of them? > > keepalives are handled by the transport protocol internally, they do not > need to be exposed to the applications Keepalives *are* exposed via SO_KEEPALIVE in setsockopt, and I think that's sensible. My question was: is there any reason to handle the general use of SO_KEEPALIVE on subflows differently than on the connection as a whole? I can imagine some instances where TCP might want to send a one-time keepalive on a subflow because it has reason to suspect the subflow has failed and wants to decide whether to kill it, but I'm not sure there's a reason to expose that to the API. > This looks reasonable to me. I would suggest Stuart Cheshire's presentati= on > at IETF72as it contains useful info about API design issues > http://www.stuartcheshire.org/IETF72/ That server is dead at the moment. I'll give it another try later... Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From narave@microsoft.com Fri Nov 13 18:05:49 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EAF53A6931 for ; Fri, 13 Nov 2009 18:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.605 X-Spam-Level: X-Spam-Status: No, score=-8.605 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFlr3tLo+uPm for ; Fri, 13 Nov 2009 18:05:48 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id ED9673A683B for ; Fri, 13 Nov 2009 18:05:47 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 13 Nov 2009 18:06:18 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server id 14.0.639.20; Fri, 13 Nov 2009 18:06:18 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Fri, 13 Nov 2009 18:06:19 -0800 From: Narasimhan Venkataramaiah To: William Herrin , "Olivier.Bonaventure@uclouvain.be" Thread-Topic: [multipathtcp] Initial ideas for API requirements Thread-Index: AQHKY6vv/v5vIJBECEqEqP3lIPUOCZE0N80AgAEepID//37oAA== Date: Sat, 14 Nov 2009 02:06:17 +0000 Message-ID: <086027680891CF44848E18E467A705481B4506CC@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <3c3e3fca0911120721i6ac25c84n62fbceefe4f0365c@mail.gmail.com> <4AFD1AC2.8080606@uclouvain.be> <3c3e3fca0911131743q1a003087m6142019be4b1790e@mail.gmail.com> In-Reply-To: <3c3e3fca0911131743q1a003087m6142019be4b1790e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" , "SCHARF, Michael" Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 02:05:49 -0000 While problems with PMTU discovery are orthogonal to the discussion on the = involvement of an application in the multipath tcp operation=20 "The TCP stack sits there like an idiot retransmitting a packet that never gets through but won't consider the possibility of an MTU problem unless triggered by the intermediate system." this is fixed in regular TCP with black hole detection logic as described i= n RFC 2923 and should be applicable to multipath TCP as well. Simha -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of William Herrin Sent: Friday, November 13, 2009 5:43 PM To: Olivier.Bonaventure@uclouvain.be Cc: multipathtcp@ietf.org; SCHARF, Michael Subject: Re: [multipathtcp] Initial ideas for API requirements On Fri, Nov 13, 2009 at 3:37 AM, Olivier Bonaventure wrote: >> Specific items the application may want to know: >> >> 1. Whether multipath was negotiated, regardless of the number of >> subflows currently in use. > > Today, applications do not require to know whether rfc1323, sack or > other TCP options have been negotiated on a given TCP connection. Hi Olivier, Let's look at it a different way: is there a reason that an application should be denied knowledge of whether multipath TCP was negotiated on a particular connection? The stack certainly knows, so it won't complicate any code if there's a getsockopt that reports whether multipath is in use, will it? >> 2. Both endpoint connection IDs if multipath is negotiated. Primarily >> for logging and matching your logs to the remote or middlebox's logs. >> >> 3. Classic TCP connection IDs (2xIP,2xport) if multipath is not negotiat= ed. >> >> 4. What are the local and remote candidate addresses for subflows? Not >> just the ones in use, the ones that might be used. >> >> Are 3 and 4 the same call that returns a variable size structure? Or >> are they different calls that the app has to be aware of? > > > We need to distinguish between information that the application needs to > know for each TCP connection and debugging information that we > need. Does the application need to know information that the user wants to know? The operator on the acceptor side wants to know who connected to him, for example. That isn't necessarily debug information. What about the javascript security issues that brought about DNS pinning in web browsers? Do we declare that out of bounds for TCP when multipath is operational? Or do we say: hey, that's a neat concept. We should continue support by allowing the app to know what candidate addresses were negotiated during the original HTTP connection so that the whole list can be used in subsequent HTTP connections? > To take a common problem, consider PathMTU discovery. > Some firewalls block ICMP messages and this breaks > PathMTU discovery. These problems are debugged by the network > administrators without requiring any change to application and > without needing to extend the applications to deal with these > problems. I would argue that TCP's PMTUD is one of the most broken things about TCP's current design. It isn't just badly behaving firewalls... There are any number of perfectly rational network designs in which there is a path between two endpoints but not necessarily paths between either endpoint and all intermediate routers. The TCP stack sits there like an idiot retransmitting a packet that never gets through but won't consider the possibility of an MTU problem unless triggered by the intermediate system. You should look at the grief the folks on the RRG went through with the various map-encap designs trying to assure that the intermediate tunnel encoders could successfully receive and translate a fragmentation-needed message, all because TCP breaks without it. Several nasty design constraints at the routing layer would vanish if TCP could identify the path MTU through packet loss without active notification of failure. At any rate, mutlipath TCP needs to be able to quickly determine that a subflow has failed, regardless of the behavior of intermediate systems. If it can't, we could end up with a level of reliability that's actually lower that TCP without multipath. >>> =A0 REQ12: =A0Set/get sporadic sending of segments on unused paths >>> =A0 =A0 =A0 =A0 =A0 ("keepalives"). >> >> Is there a reason to do this in the extended API instead of the >> current API? Put another way, why would we want keepalives on only >> chosen subflows instead of all of them? > > keepalives are handled by the transport protocol internally, they do not > need to be exposed to the applications Keepalives *are* exposed via SO_KEEPALIVE in setsockopt, and I think that's sensible. My question was: is there any reason to handle the general use of SO_KEEPALIVE on subflows differently than on the connection as a whole? I can imagine some instances where TCP might want to send a one-time keepalive on a subflow because it has reason to suspect the subflow has failed and wants to decide whether to kill it, but I'm not sure there's a reason to expose that to the API. > This looks reasonable to me. I would suggest Stuart Cheshire's presentati= on > at IETF72as it contains useful info about API design issues > http://www.stuartcheshire.org/IETF72/ That server is dead at the moment. I'll give it another try later... Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From c.raiciu@cs.ucl.ac.uk Tue Nov 17 08:46:15 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E10C3A698C for ; Tue, 17 Nov 2009 08:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqvLyGmSvYOe for ; Tue, 17 Nov 2009 08:46:14 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 366843A697B for ; Tue, 17 Nov 2009 08:46:14 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1NAR99-000EWf-RV; Tue, 17 Nov 2009 16:43:15 +0000 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <4B02AD46.8090204@ismailov.eu> References: <4B02AD46.8090204@ismailov.eu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17985120-D647-44CA-BA72-E236E963E2B7@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Tue, 17 Nov 2009 16:46:04 +0000 To: Yuri Ismailov , multipathtcp List X-Mailer: Apple Mail (2.753.1) Subject: [multipathtcp] Summary: MPTCP implementors meeting in Hiroshima X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 16:46:15 -0000 Hi, There were roughly 10 people at the meeting, with different interests. More people that wanted to join were not in Hiroshima for the IETF. The meeting was more to meet each other and to set out a implementation plan that gets multipath deployed sooner. As you know, there are several ongoing implementation efforts (e.g. the one by Sebastien Barre, or mine). We mainly want to make sure a) that people implementing multipath talk to each other to share experience and make the process simpler and b) we change the stacks in sensible ways (e.g. for linux we should be able to port the outcome to the main stack). For this we need continued feedback from the guys with the expertise. One of the Linux kernel coders was at the meeting, and he already pointed out important things we need to remember like not increasing skbuff struct size (processor cache considerations) . Other people implementing IKE (ipsec) showed interest in understanding interactions between mptcp; we must use this input to make sure we create a deployable solution. At a high level, people can get access to the existing code and help improve it if they wish; please send us email in that case. We plan to have a reference implementation in a short timeline (<6 months), that would be publicly available, and would track the status of the spec. Thanks, Costin On 17 Nov 2009, at 14:03, Yuri Ismailov wrote: > Hi Costin, > On Wednesday last week in Hiroshima I tried to join the implementors > meeting and did not find anybody at 15.00. > Apparently I missed some info. > Could you please update me in few words what was the outcome of the > meeting? > > Regards > > Yuri > From sebastien.barre@uclouvain.be Tue Nov 17 16:15:54 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584FB3A67B3 for ; Tue, 17 Nov 2009 16:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2zGnGyunF+J for ; Tue, 17 Nov 2009 16:15:44 -0800 (PST) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id C4EB13A6ADF for ; Tue, 17 Nov 2009 16:15:41 -0800 (PST) Received: from [192.168.1.100] (unknown [83.101.32.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sbarre@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E7813EB7D0; Wed, 18 Nov 2009 01:15:31 +0100 (CET) Message-ID: <4B033CA2.7060403@uclouvain.be> Date: Wed, 18 Nov 2009 01:15:30 +0100 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Multipath TCP Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-2.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=83.101.32.63; helo=[192.168.1.100] Received-SPF: Pass (sender authenticated); receiver=; client-ip=83.101.32.63; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: E7813EB7D0.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: sebastien.barre@uclouvain.be X-SGSI-Spam-Status: No Cc: INL , Pierre Reinbold Subject: [multipathtcp] Linux MPTCP version 0.1 released X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:15:56 -0000 Hi, I am happy to announce that Linux MPTCP v0.1 is now released. You can download it here: http://inl.info.ucl.ac.be/mptcp Moreover, thanks to much help from Pierre Reinbold, we have set up a Trac development platform, that gives the following possibilities: *Consult the current documentation *Browse and download the releases *Directly browse the source code and move through the branches of the git repository (main branch is called mtcp). *Contribute by sending bug reports, bug fixes or patches. All this is detailed and accessible from the above website. Note that it is still in an early stage, although it can already be used for some experiments. Do not hesitate to send me comments or questions by mail about this, or already post bug reports or patches on the trac site. Just please be patient to get an answer, since I will be disconnected from now until Dec 8th. regards, Sébastien. -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium http://inl.info.ucl.ac.be/sbarre From magnus.westerlund@ericsson.com Wed Nov 18 05:14:32 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6D33A684C for ; Wed, 18 Nov 2009 05:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piSm1z3jK97M for ; Wed, 18 Nov 2009 05:14:21 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9EA013A67AC for ; Wed, 18 Nov 2009 05:14:17 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-6e-4b03f326c43f Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 97.97.24094.623F30B4; Wed, 18 Nov 2009 14:14:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 14:14:14 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 14:14:14 +0100 Message-ID: <4B03F326.6090302@ericsson.com> Date: Wed, 18 Nov 2009 14:14:14 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Costin Raiciu References: <4AFB7024.8030503@ericsson.com> <385671C6-967F-4908-8928-E70ADED5AB75@cs.ucl.ac.uk> In-Reply-To: <385671C6-967F-4908-8928-E70ADED5AB75@cs.ucl.ac.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Nov 2009 13:14:14.0382 (UTC) FILETIME=[067AA0E0:01CA6851] X-Brightmail-Tracker: AAAAAA== Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 13:14:33 -0000 Hi Costin, I have two comments related to your response. 1. Well, the rest of the world will care about port numbers. Otherwise you have zero possibility of getting through NATs and firewalls. You need to be able to specify where your packet should be going and that you have that port open for listening on that interface or it will in 99.999% cases be eaten by the FW or NAT. Especially if MPTCP actually attempts to make simultaneous open work. It will also be critical if you try to make connections to a host behind a NAT as the port is part of the address to reach the right host and interface. 2. So if the MPTCP stack isn't looking at the port on arriving SYNs then you have reduced the target space for off-path attackers with 16 bits. I don't know how serious that is, but people seem to be attempting to keep the entropy up. /Magnus Costin Raiciu skrev: > Hi, > > There is plenty of discussion on the mailing list about this, but maybe > it doesn't cover all the issues. Let me try to summarize again: > > - for ADDITIONAL subflows (i.e. not the first one) the port number in > the SYN packet does not matter for the host; demultiplexing is done > using the connection token. (this addresses point 1 - you don't need to > reserve that port on all interfaces). > - let's first answer the question of WHEN add address option is used. It > is only used when subflow establishment fails from A to B (which > probably means B is behind NAT). At this point, the host with address A > will send add address on another subflow, telling the host with address > B please contact me here. B will send a SYN to A, with the proper token. > If A is behind a NAT (both A and B are now natted) this will not work. > People are arguing that if a port were signalled from A to B this might > work. I have doubts, since this doesn't really work today either. > However, I have nothing against putting the port in if people think it > would help reachability. > > Costin > > > On 12 Nov 2009, at 11:17, Magnus Westerlund wrote: > >> Hi, >> >> I just looked at draft-ford-mptcp-multiaddressed-02 and saw that the add >> address option lacks a port number. I think that will not work for two >> reasons. >> >> 1. First, there will a large amount of single flow TCP connections and >> you will run into a synchronization issue and resource constrain issue >> if you limit your interface port to be the same over all interfaces. >> >> 2. Your NAT traversal will fail as soon it encounters a NAT that is >> unable to do port preservation. That is likelier and likelier to happen, >> espeically for ISP place NATs where the load level is higher. Port >> preservation will also fail as soon as two sub-flows goes over the same >> NAT. Thus to enable MPTCP to work in cases where you use either an >> explicit signalling protocol (UPnP, etc) or implicit methods, like STUN >> to find out your external subflow address they will not be able to >> preserver the port in the generic case. Thus there is need to be able to >> indicate the listening port. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > > -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Michael.Scharf@alcatel-lucent.com Thu Nov 19 01:16:55 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98AF93A6995 for ; Thu, 19 Nov 2009 01:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoWAefe9O0cR for ; Thu, 19 Nov 2009 01:16:54 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 74BED3A693E for ; Thu, 19 Nov 2009 01:16:53 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn2.rcs.de.alcatel-lucent.com [149.204.60.99]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id nAJ9GjRF029465; Thu, 19 Nov 2009 10:16:45 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Nov 2009 10:16:44 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C01FFA496@SLFSNX.rcs.alcatel-research.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Initial ideas for API requirements Thread-Index: AcpjZhoEJ3liFBKyQ7uq0t1Tgh6bfQFkRx5w References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> From: "SCHARF, Michael" To: "Costin Raiciu" X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Cc: multipathtcp Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 09:16:55 -0000 > How about redundancy? I can think of cases where the app=20 > might like to send all segments on all paths, to reduce end=20 > to end rtt, etc. Good point. However, I think that this only makes sense in selected use cases, given that it can significantly increase the total amount of sent traffic. I have the impression that one mostly would want to use this feature for low-bandwidth interactive applications (telnet, voice, ...), and in particular if the paths are not significantly congested. One might be able to implicitly detect some of these situations inside the stack and then send all packets on all paths, but I think that there should be an (optional, as always) control API as well. Michael From lars.eggert@nokia.com Thu Nov 19 01:38:00 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF4B3A67FD for ; Thu, 19 Nov 2009 01:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0hb31Kd40B1 for ; Thu, 19 Nov 2009 01:37:59 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 1181A3A6831 for ; Thu, 19 Nov 2009 01:37:58 -0800 (PST) Received: from [10.180.10.29] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nAJ9bibp012695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Nov 2009 11:37:44 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-74--1004103388; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4AFBC301.5090000@uclouvain.be> Date: Thu, 19 Nov 2009 11:37:34 +0200 Message-Id: <965F9DAA-4C47-4F12-93B3-CB150DF76FF6@nokia.com> References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> To: "Olivier.Bonaventure@uclouvain.be" X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [212.213.221.39]); Thu, 19 Nov 2009 11:37:45 +0200 (EET) Cc: "multipathtcp@ietf.org" , "SCHARF, Michael" Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 09:38:00 -0000 --Apple-Mail-74--1004103388 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, agree with Olivier for the most part. I think we need to distinguish what information should be offered to = applications via the socket API, and which information should be offered = via a management interface (e.g., a revision to RFC4022/RFC4898). The = requirements list below seems to be mixing the two kinds. Lars On 2009-11-12, at 10:10, Olivier Bonaventure wrote: > Michael, >>=20 >> draft-scharf-mptcp-api-00 contains a list of potential requirements = on >> the MPTCP API towards application. This list is of course just a >> starting point. Currently, it is certainly not complete and may also >> include requirements that will be removed in later stage, once the = MPTCP >> architecture spec evolves. >=20 >=20 > I am frightened by the long list of requirements and I fear that this > would make the API far too complex. The layering principle tells us = that > we need to hide some of the details of the underlying layer to the = upper > layer and experience should that this works well in practice. >=20 > To take an analogy, let's look at how the socket API evolved with > changes in TCP such as the introduction of congestion control, the = fats > retransmit, the selective acks, timers computations, ... All of these > mechanisms have changed the behaviour of the TCP stack and its = reaction > against losses but we never had to update the API to reflect this. >=20 >> REQ1: Turn on/off MPTCP: An application should be able to request >> to turn on or turn off the usage of MPTCP. This means that >> an application should be able to explicitly request the use >> of MPTCP if this is possible. Applications should also be >> able to request not to enable MPTCP and to use regular TCP >> transport instead. (This can be implicit in many cases, >> e.g., by the use of binding to a specific address versus = all >> addresses). >=20 > I would love to have a higher layer API where the application = indicates > that it needs a reliable delivery and the stack chooses the most > appropriate transport protocol (tcp, sctp, mtcp, ...) automatically. > This would allow the application and the transport to evolve = independently. >=20 >=20 >> REQ2: An application will want to be able to restrict MPTCP to >> binding to a given set of addresses or interfaces. >=20 > why ? >=20 >> REQ3: An application should be able to know if multiple subflows >> are in use. >=20 > why ? today's application do not ask whether there have been = retransmissions >=20 >> REQ4: An application should be able to extract a unique = identifier >> for the connection (per endpoint), analogous to a port, = i.e. >> it should be able to retrieve MPTCP's connection = identifier. >=20 > this looks reasonable >=20 >> REQ5: An application should be able to enumerate all subflows in >> use, obtain information on the addresses used by a subflow, >> and obtain a subflow's usage (e.g., ratio of traffic sent = via >> this subflow). >=20 > why ? today's application do not ask whether there have been = retransmissions >=20 >> REQ6: Set/get application profile, as discussed in the previous >> section. >=20 > remember that for intserv we almost never managed to have application > developers define their QoS requirements >=20 >> REQ7: Constrain the maximum number of subflows to be used by an >> MPTCP connection. (Or just infer from application = profile?) >=20 > the stack should do this automatically >=20 >> REQ8: Request a change in scheduling between subflows? (i.e. a = more >> granular version of application profile?) >=20 > why ? today's applications do not set for example the MSS to be used >=20 >> REQ9: Request a change in the number of subflows in use, thus >> triggering removal or addition of subflows. (A finer = control >> granularity would be: Request the establishment of a new >> subflow to a provided destination, and request the >> termination of a specified, existing subflow.) >=20 > this is the job of the tcp implementation, not the application >=20 >> REQ10: Control automatic establishment/termination of subflows? >> There could be different configurations of the path = manager, >> e.g., 'try ASAP', 'wait until there is a bunch of data, = etc. >> (Tied to application profile?) >=20 > i don't see why an application should want to do this >=20 >> REQ11: Set/get preferred subflows or subflow usage policies? = There >> could be different configurations of the multipath = scheduler, >> e.g., 'all-or-nothing', 'overflow', etc. (Again, tied to >> application profile). >>=20 >> REQ12: Set/get sporadic sending of segments on unused paths >> ("keepalives"). >=20 > no >=20 >> REQ13: An application should be able to modify the MPTCP >> configuration while communication is ongoing, i.e., after >> establishment of the MPTCP connection. >=20 > we should have as few mptcp configuration as possible, otherwise pmtcp > will be too complex for the application developers >=20 >=20 >=20 > Olivier >=20 > --=20 > http://inl.info.ucl.ac.be , UCLouvain, Belgium > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail-74--1004103388 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTExOTA5MzczNFowIwYJKoZIhvcNAQkEMRYEFAiY/mV2oaHSu2au4VZYnusftDMkMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDnTB2HFFTH8+I9/fAqaYpZ3IrSRyJgx65qysHnb5mkXSTJZMZsslo5OfgE6QJ4WiLR7Xzz xtFeYbMMxmd+a/VpLleA8XfHpb+JbfOK4SWdQh6lZPgDYSnwrAZkgGtZBrGyonVCYnhi2K4p7ZYZ VkkvIX3/SCVJi8o0DRtERX8O0DkiLwH3xH1ZWQn1Ps3GjCfaLtnEtHY7ZFfFkMyk5HNjEG4OYSfN c1DS6edAHIVbHyZkAsSq5xVRytrwNhM4dts0qfobYGwvtLtjXP8LqgMpWsptDNdFOmBUGf7CV5M0 znbpteM8V9IJFRDr2TBZsac5hXCm/L5NiRt5ZNs0uNwGAAAAAAAA --Apple-Mail-74--1004103388-- From Michael.Scharf@alcatel-lucent.com Thu Nov 19 04:36:13 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3CC3A693A for ; Thu, 19 Nov 2009 04:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RagCTPSFMCMi for ; Thu, 19 Nov 2009 04:36:12 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 7F7623A6A70 for ; Thu, 19 Nov 2009 04:36:12 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn2.rcs.de.alcatel-lucent.com [149.204.60.99]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id nAJCa6Ir010381; Thu, 19 Nov 2009 13:36:06 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Nov 2009 13:36:05 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C01FFA4B9@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <4AFC3739.6010502@uclouvain.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Initial ideas for API requirements Thread-Index: AcpjtO3gdHRQTHgQSGOQ0gDcwH83CwFW3otQ References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> <2181C5F19DD0254692452BFF3EAF1D6808D7C0E2@rsys005a.comm.ad.roke.co.uk> <4AFC3739.6010502@uclouvain.be> From: "SCHARF, Michael" To: , "Ford, Alan" X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:36:13 -0000 Olivier,=20 thanks a lot for the feedback. I just comment here on the application profile; the other aspects have already been discussed in the thread. > >>> REQ6: Set/get application profile, as discussed in=20 > the previous > >>> section. > >> remember that for intserv we almost never managed to have=20 > application=20 > >> developers define their QoS requirements > >=20 > > However, in MPTCP this does make a _real_ difference. This is not=20 > > simply a case of saying "do I want the best QoS or not the=20 > best QoS"=20 > > (for which there's no wonder an application always says=20 > they want the=20 > > best). This is a case of "do I want throughput, or reduced=20 > jitter" for example. >=20 > i'm not convinced that application developpers will want to=20 > deal with these details. We need to keep the API as simple as=20 > possible (and perhaps simpler than that) True, the API must be simple. However, app developers also learnt to use TCP_NODELAY, which basically distinguishes two profiles (interactive app. vs. bulk data transport). If it turns out that MPTCP could really benefit from some third profile, I guess that app developers could get familiar to this as well. But, actually, we don't know yet whether we need a distinction beyond TCP_NODELAY - this is all to be discussed. > >>> REQ7: Constrain the maximum number of subflows to be=20 > used by an > >>> MPTCP connection. (Or just infer from application > > profile?) > >> the stack should do this automatically > >=20 > > Yep, and the profile could definitely influence this. >=20 > For me, profile is similar to traffic contract in intserv, I=20 > don't expect that many applications will define their=20 > profile. Most applications will use the default profile and=20 > this what we should optimise I disagree with the comparison to IntServ. The application profiles mentioned in the draft only affect how data is assigned to the different subflows, which significantly affects the delay seen by the application. This is quite similar to TCP_NODELAY. Of course, there are similarities to some DiffServ classes (e. g., RFC 4594), but we are not talking here about a set of 12 DiffServ classes, but a very small amount of choices only. I still think that if the MPTCP stack offers, for instance, two or three different ways how sub-flows are used, and if their difference is easily understandable, app developers could make an informed choice that might be better than an implicit heuristic inside the MPTCP stack. Obviously, as MPTCP will be optimized for bulk data transfer, most TCP-based apps will be happy with the default settings and will not use any API extensions anyway. Michael From Michael.Scharf@alcatel-lucent.com Thu Nov 19 04:39:30 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2A73A6A4B for ; Thu, 19 Nov 2009 04:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gKz6cEs6ZVq for ; Thu, 19 Nov 2009 04:39:29 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id DABE93A68CB for ; Thu, 19 Nov 2009 04:39:28 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn2.rcs.de.alcatel-lucent.com [149.204.60.99]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id nAJCdOFN012143; Thu, 19 Nov 2009 13:39:24 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Nov 2009 13:39:24 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C01FFA4BF@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <965F9DAA-4C47-4F12-93B3-CB150DF76FF6@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Initial ideas for API requirements Thread-Index: Acpo+/ouBh61pgK0SG+iXkXoaziLtQAD1E0Q References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> <965F9DAA-4C47-4F12-93B3-CB150DF76FF6@nokia.com> From: "SCHARF, Michael" To: "Lars Eggert" , X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:39:30 -0000 Olivier, Lars, all, > agree with Olivier for the most part. first, let me state once again that this is a list of *potential* requirements, i. e., it is obvious that some of the items will not be considered finally. It is IMHO very important to discuss which ones do not make sense - and that is the purpose of this large list. Still, I do believe that it is reasonable to define a number of (optional!) API extensions. In addition to what has already been said, I want to mention two additional aspects: On the one hand, the interface between the TCP/IP and apps is actually not simple even today. For instance, the Linux TCP stack has quite a number of (partly non-interoperable) socket options in addition to TCP_NODELAY (e. g., TCP_CORK, TCP_DEFER_ACCEPT, TCP_INFO, TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_LINGER2, TCP_MAXSEG, TCP_QUICKACK, TCP_SYNCNT, TCP_WINDOW_CLAMP, ...). One can certainly question whether all of them are indeed required, or whether this is good API style, but most of these options have probably been implemented because some app developer at some point in time actually needed exactly this option. And IMHO we do have to avoid that each MPTCP stack finally provides its own non-interoperable set of API extensions. On the other hand, instead of MPTCP, an app can always use multiple several TCP connections with an own data striping mechanism. In this case an app has full control. MPTCP to some extent provides an equivalent transport mechanism inside the TCP/IP stack. Thus, when discussing the MPTCP API, we must also compare it to the situation of an app that implementes its own data striping, with a lot of degrees of freedom. (Many of which will be handled by MPTCP internally and automatically without app control). > I think we need to distinguish what information should be=20 > offered to applications via the socket API, and which=20 > information should be offered via a management interface=20 > (e.g., a revision to RFC4022/RFC4898). The requirements list=20 > below seems to be mixing the two kinds. Correct. The sockets interface to the app is indeed not the only user-space MPTCP interface. In addition, there will of course be a configuration interface for setting the default configuration, and other possibilities to retrieve statistics from the stack (e. g., MIB).=20 In some sense, the latter ones are out-of-band interfaces, whereas the socket API is some form of in-band API. The key question is: What information/configuration must be accessible from an individual app? I think that an app is more likely to use an in-band API style, instead of, e. g., a MIB. Michael From caozhenpku@gmail.com Thu Nov 19 05:45:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D9B3A6A20 for ; Thu, 19 Nov 2009 05:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDaByJygM5bk for ; Thu, 19 Nov 2009 05:45:58 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 0A4633A68C4 for ; Thu, 19 Nov 2009 05:45:58 -0800 (PST) Received: by pzk6 with SMTP id 6so1523926pzk.29 for ; Thu, 19 Nov 2009 05:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BW0f8Kxb95bkltzzsdV3S6IjBGEBrd81PaUqSJptA/M=; b=JSKvFuKgFpmilouZQFK1MHWAlKu6AaNqwtsd8EjmwPO+Ic1STzP0U+wRgdf3x2Iaty VptCVrc5k3Z49fgvazh8vDGnE8arAafzUWS7J69JaBt1kiH0c/fv2NpGQ2VaK4pt20PL r2YTGuGf0a6a/pjUIkQYy5j1m7fx6BcGx9bcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MCV3nlI2qaEfUsFuXcFDc7uNXQ7IylI1muJNmTwWp0O9oYmm4X7lQgy9mAMLj5yhZM jIbsf4uADza6b496nZa56JPivWIP84rYHJLUeQn3StZaJKST84nWnmXOg8fcJXn9nKdC lFTyhZsVlDMFmtyCub54r/jo8nYmnNqj2ElZY= MIME-Version: 1.0 Received: by 10.142.195.18 with SMTP id s18mr1359051wff.263.1258638352493; Thu, 19 Nov 2009 05:45:52 -0800 (PST) In-Reply-To: <965F9DAA-4C47-4F12-93B3-CB150DF76FF6@nokia.com> References: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD23@SLFSNX.rcs.alcatel-research.de> <4AFBC301.5090000@uclouvain.be> <965F9DAA-4C47-4F12-93B3-CB150DF76FF6@nokia.com> Date: Thu, 19 Nov 2009 21:45:52 +0800 Message-ID: From: Zhen Cao To: Lars Eggert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multipathtcp@ietf.org" , "SCHARF, Michael" , "Olivier.Bonaventure@uclouvain.be" Subject: Re: [multipathtcp] Initial ideas for API requirements X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 13:45:59 -0000 Hi All, Since there is an open source implementation of MPTCP, I think every body would like to know if the implementors have changed any existing API or find any existing API inadequate for the implementation. That will help the document specification a lot. Thanks, Zhen China Mobile On Thu, Nov 19, 2009 at 5:37 PM, Lars Eggert wrote: > Hi, > > agree with Olivier for the most part. > > I think we need to distinguish what information should be offered to appl= ications via the socket API, and which information should be offered via a = management interface (e.g., a revision to RFC4022/RFC4898). The requirement= s list below seems to be mixing the two kinds. > > Lars > > On 2009-11-12, at 10:10, Olivier Bonaventure wrote: > >> Michael, >>> >>> draft-scharf-mptcp-api-00 contains a list of potential requirements on >>> the MPTCP API towards application. This list is of course just a >>> starting point. Currently, it is certainly not complete and may also >>> include requirements that will be removed in later stage, once the MPTC= P >>> architecture spec evolves. >> >> >> I am frightened by the long list of requirements and I fear that this >> would make the API far too complex. The layering principle tells us that >> we need to hide some of the details of the underlying layer to the upper >> layer and experience should that this works well in practice. >> >> To take an analogy, let's look at how the socket API evolved with >> changes in TCP such as the introduction of congestion control, the fats >> retransmit, the selective acks, timers computations, ... All of these >> mechanisms have changed the behaviour of the TCP stack and its reaction >> against losses but we never had to update the API to reflect this. >> >>> =A0 REQ1: =A0 Turn on/off MPTCP: An application should be able to reque= st >>> =A0 =A0 =A0 =A0 =A0 to turn on or turn off the usage of MPTCP. =A0This = means that >>> =A0 =A0 =A0 =A0 =A0 an application should be able to explicitly request= the use >>> =A0 =A0 =A0 =A0 =A0 of MPTCP if this is possible. =A0Applications shoul= d also be >>> =A0 =A0 =A0 =A0 =A0 able to request not to enable MPTCP and to use regu= lar TCP >>> =A0 =A0 =A0 =A0 =A0 transport instead. =A0(This can be implicit in many= cases, >>> =A0 =A0 =A0 =A0 =A0 e.g., by the use of binding to a specific address v= ersus all >>> =A0 =A0 =A0 =A0 =A0 addresses). >> >> I would love to have a higher layer API where the application indicates >> that it needs a reliable delivery and the stack chooses the most >> appropriate transport protocol (tcp, sctp, mtcp, ...) automatically. >> This would allow the application and the transport to evolve independent= ly. >> >> >>> =A0 REQ2: =A0 An application will want to be able to restrict MPTCP to >>> =A0 =A0 =A0 =A0 =A0 binding to a given set of addresses or interfaces. >> >> why ? >> >>> =A0 REQ3: =A0 An application should be able to know if multiple subflow= s >>> =A0 =A0 =A0 =A0 =A0 are in use. >> >> why ? today's application do not ask whether there have been retransmiss= ions >> >>> =A0 REQ4: =A0 An application should be able to extract a unique identif= ier >>> =A0 =A0 =A0 =A0 =A0 for the connection (per endpoint), analogous to a p= ort, i.e. >>> =A0 =A0 =A0 =A0 =A0 it should be able to retrieve MPTCP's connection id= entifier. >> >> this looks reasonable >> >>> =A0 REQ5: =A0 An application should be able to enumerate all subflows i= n >>> =A0 =A0 =A0 =A0 =A0 use, obtain information on the addresses used by a = subflow, >>> =A0 =A0 =A0 =A0 =A0 and obtain a subflow's usage (e.g., ratio of traffi= c sent via >>> =A0 =A0 =A0 =A0 =A0 this subflow). >> >> why ? today's application do not ask whether there have been retransmiss= ions >> >>> =A0 REQ6: =A0 Set/get application profile, as discussed in the previous >>> =A0 =A0 =A0 =A0 =A0 section. >> >> remember that for intserv we almost never managed to have application >> developers define their QoS requirements >> >>> =A0 REQ7: =A0 Constrain the maximum number of subflows to be used by an >>> =A0 =A0 =A0 =A0 =A0 MPTCP connection. =A0(Or just infer from applicatio= n profile?) >> >> the stack should do this automatically >> >>> =A0 REQ8: =A0 Request a change in scheduling between subflows? (i.e. a = more >>> =A0 =A0 =A0 =A0 =A0 granular version of application profile?) >> >> why ? today's applications do not set for example the MSS to be used >> >>> =A0 REQ9: =A0 Request a change in the number of subflows in use, thus >>> =A0 =A0 =A0 =A0 =A0 triggering removal or addition of subflows. =A0(A f= iner control >>> =A0 =A0 =A0 =A0 =A0 granularity would be: Request the establishment of = a new >>> =A0 =A0 =A0 =A0 =A0 subflow to a provided destination, and request the >>> =A0 =A0 =A0 =A0 =A0 termination of a specified, existing subflow.) >> >> this is the job of the tcp implementation, not the application >> >>> =A0 REQ10: =A0Control automatic establishment/termination of subflows? >>> =A0 =A0 =A0 =A0 =A0 There could be different configurations of the path= manager, >>> =A0 =A0 =A0 =A0 =A0 e.g., 'try ASAP', 'wait until there is a bunch of d= ata, etc. >>> =A0 =A0 =A0 =A0 =A0 (Tied to application profile?) >> >> i don't see why an application should want to do this >> >>> =A0 REQ11: =A0Set/get preferred subflows or subflow usage policies? =A0= There >>> =A0 =A0 =A0 =A0 =A0 could be different configurations of the multipath = scheduler, >>> =A0 =A0 =A0 =A0 =A0 e.g., 'all-or-nothing', 'overflow', etc. =A0(Again,= tied to >>> =A0 =A0 =A0 =A0 =A0 application profile). >>> >>> =A0 REQ12: =A0Set/get sporadic sending of segments on unused paths >>> =A0 =A0 =A0 =A0 =A0 ("keepalives"). >> >> no >> >>> =A0 REQ13: =A0An application should be able to modify the MPTCP >>> =A0 =A0 =A0 =A0 =A0 configuration while communication is ongoing, i.e.,= after >>> =A0 =A0 =A0 =A0 =A0 establishment of the MPTCP connection. >> >> we should have as few mptcp configuration as possible, otherwise pmtcp >> will be too complex for the application developers >> >> >> >> Olivier >> >> -- >> http://inl.info.ucl.ac.be , UCLouvain, Belgium >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From nishida@sfc.wide.ad.jp Fri Nov 20 03:20:22 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF4E3A68C9 for ; Fri, 20 Nov 2009 03:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr+3Z-Y2Hb1K for ; Fri, 20 Nov 2009 03:20:21 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 514573A67A2 for ; Fri, 20 Nov 2009 03:20:21 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 107034C0D3; Fri, 20 Nov 2009 20:20:14 +0900 (JST) Date: Fri, 20 Nov 2009 20:20:13 +0900 (JST) Message-Id: <20091120.202013.237337710.nishida@sfc.wide.ad.jp> To: magnus.westerlund@ericsson.com From: Yoshifumi Nishida In-Reply-To: <4B03F326.6090302@ericsson.com> References: <4AFB7024.8030503@ericsson.com> <385671C6-967F-4908-8928-E70ADED5AB75@cs.ucl.ac.uk> <4B03F326.6090302@ericsson.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 11:20:22 -0000 Hello Magnus, Correct me if I'm wrong.. It seems to me that you want to support NAT-NAT communication (both sub= flow ends = are behind NAT) in mptcp, while the current proposal try to support onl= y = NAT-global communication. = If we really want to support NAT-NAT communication, I think we might ne= ed to have = something like stun server somewhere on the Internet to know the extern= al IP and = port of the interface, or we need to have knowledge about our NAT or FW= , In anycase, this kind of mechanisms will be outside of mptcp, which mig= ht cause = some issues. If you could elaborate your target scenario, it would be very helpful. For 2, I think having longer auth-token can mitigate this, so it might = not = be a very serious issue. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Magnus Westerlund Subject: Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need po= rts in ADD address Date: Wed, 18 Nov 2009 14:14:14 +0100 Message-ID: <4B03F326.6090302@ericsson.com> > Hi Costin, > = > I have two comments related to your response. > = > 1. Well, the rest of the world will care about port numbers. Otherwi= se > you have zero possibility of getting through NATs and firewalls. You= > need to be able to specify where your packet should be going and tha= t > you have that port open for listening on that interface or it will i= n > 99.999% cases be eaten by the FW or NAT. > = > Especially if MPTCP actually attempts to make simultaneous open work= .= > = > It will also be critical if you try to make connections to a host be= hind > a NAT as the port is part of the address to reach the right host and= > interface. > = > 2. So if the MPTCP stack isn't looking at the port on arriving SYNs = then > you have reduced the target space for off-path attackers with 16 bit= s. I > don't know how serious that is, but people seem to be attempting to = keep > the entropy up. > = > /Magnus > = > Costin Raiciu skrev: > > Hi, > > = > > There is plenty of discussion on the mailing list about this, but = maybe > > it doesn't cover all the issues. Let me try to summarize again: > > = > > - for ADDITIONAL subflows (i.e. not the first one) the port number= in > > the SYN packet does not matter for the host; demultiplexing is don= e > > using the connection token. (this addresses point 1 - you don't n= eed to > > reserve that port on all interfaces). > > - let's first answer the question of WHEN add address option is us= ed. It > > is only used when subflow establishment fails from A to B (which > > probably means B is behind NAT). At this point, the host with addr= ess A > > will send add address on another subflow, telling the host with ad= dress > > B please contact me here. B will send a SYN to A, with the proper = token. > > If A is behind a NAT (both A and B are now natted) this will not w= ork. > > People are arguing that if a port were signalled from A to B this = might > > work. I have doubts, since this doesn't really work today either. > > However, I have nothing against putting the port in if people thin= k it > > would help reachability. > > = > > Costin > > = > > = > > On 12 Nov 2009, at 11:17, Magnus Westerlund wrote: > > = > >> Hi, > >> > >> I just looked at draft-ford-mptcp-multiaddressed-02 and saw that = the add > >> address option lacks a port number. I think that will not work fo= r two > >> reasons. > >> > >> 1. First, there will a large amount of single flow TCP connection= s and > >> you will run into a synchronization issue and resource constrain = issue > >> if you limit your interface port to be the same over all interfac= es. > >> > >> 2. Your NAT traversal will fail as soon it encounters a NAT that = is > >> unable to do port preservation. That is likelier and likelier to = happen, > >> espeically for ISP place NATs where the load level is higher. Por= t > >> preservation will also fail as soon as two sub-flows goes over th= e same > >> NAT. Thus to enable MPTCP to work in cases where you use either a= n > >> explicit signalling protocol (UPnP, etc) or implicit methods, lik= e STUN > >> to find out your external subflow address they will not be able t= o > >> preserver the port in the generic case. Thus there is need to be = able to > >> indicate the listening port. > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> IETF Transport Area Director > >> -----------------------------------------------------------------= ----- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> -----------------------------------------------------------------= ----- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.c= om > >> -----------------------------------------------------------------= ----- > >> _______________________________________________ > >> multipathtcp mailing list > >> multipathtcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/multipathtcp > > = > > = > = > = > -- = > = > Magnus Westerlund > = > IETF Transport Area Director > --------------------------------------------------------------------= -- > Multimedia Technologies, Ericsson Research EAB/TVM > --------------------------------------------------------------------= -- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > --------------------------------------------------------------------= -- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From c.raiciu@cs.ucl.ac.uk Fri Nov 20 03:26:28 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06763A68D3 for ; Fri, 20 Nov 2009 03:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+xBtIgUgOV3 for ; Fri, 20 Nov 2009 03:26:27 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 96D7D3A68C9 for ; Fri, 20 Nov 2009 03:26:27 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1NBRYy-000F2G-7T; Fri, 20 Nov 2009 11:22:04 +0000 In-Reply-To: <4B03F326.6090302@ericsson.com> References: <4AFB7024.8030503@ericsson.com> <385671C6-967F-4908-8928-E70ADED5AB75@cs.ucl.ac.uk> <4B03F326.6090302@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Fri, 20 Nov 2009 11:26:18 +0000 To: Magnus Westerlund X-Mailer: Apple Mail (2.753.1) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 11:26:28 -0000 Hi Magnus, In case 1, do you assume a local firewall? I guess in that case the stack can just inform the firewall about the open port, without actually binding it. I have no idea how this is done today - does the firewall monitor bound/listeninng ports? 2. Agree with that. We need to do a careful security analysis anyways, and the outcome is likely going to be stronger than the current token. Cheers Costin > Hi Costin, > > I have two comments related to your response. > > 1. Well, the rest of the world will care about port numbers. Otherwise > you have zero possibility of getting through NATs and firewalls. You > need to be able to specify where your packet should be going and that > you have that port open for listening on that interface or it will in > 99.999% cases be eaten by the FW or NAT. > > Especially if MPTCP actually attempts to make simultaneous open work. > > It will also be critical if you try to make connections to a host > behind > a NAT as the port is part of the address to reach the right host and > interface. > > 2. So if the MPTCP stack isn't looking at the port on arriving SYNs > then > you have reduced the target space for off-path attackers with 16 > bits. I > don't know how serious that is, but people seem to be attempting to > keep > the entropy up. > > /Magnus > > Costin Raiciu skrev: >> Hi, >> >> There is plenty of discussion on the mailing list about this, but >> maybe >> it doesn't cover all the issues. Let me try to summarize again: >> >> - for ADDITIONAL subflows (i.e. not the first one) the port number in >> the SYN packet does not matter for the host; demultiplexing is done >> using the connection token. (this addresses point 1 - you don't >> need to >> reserve that port on all interfaces). >> - let's first answer the question of WHEN add address option is >> used. It >> is only used when subflow establishment fails from A to B (which >> probably means B is behind NAT). At this point, the host with >> address A >> will send add address on another subflow, telling the host with >> address >> B please contact me here. B will send a SYN to A, with the proper >> token. >> If A is behind a NAT (both A and B are now natted) this will not >> work. >> People are arguing that if a port were signalled from A to B this >> might >> work. I have doubts, since this doesn't really work today either. >> However, I have nothing against putting the port in if people >> think it >> would help reachability. >> >> Costin >> >> >> On 12 Nov 2009, at 11:17, Magnus Westerlund wrote: >> >>> Hi, >>> >>> I just looked at draft-ford-mptcp-multiaddressed-02 and saw that >>> the add >>> address option lacks a port number. I think that will not work >>> for two >>> reasons. >>> >>> 1. First, there will a large amount of single flow TCP >>> connections and >>> you will run into a synchronization issue and resource constrain >>> issue >>> if you limit your interface port to be the same over all interfaces. >>> >>> 2. Your NAT traversal will fail as soon it encounters a NAT that is >>> unable to do port preservation. That is likelier and likelier to >>> happen, >>> espeically for ISP place NATs where the load level is higher. Port >>> preservation will also fail as soon as two sub-flows goes over >>> the same >>> NAT. Thus to enable MPTCP to work in cases where you use either an >>> explicit signalling protocol (UPnP, etc) or implicit methods, >>> like STUN >>> to find out your external subflow address they will not be able to >>> preserver the port in the generic case. Thus there is need to be >>> able to >>> indicate the listening port. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> IETF Transport Area Director >>> -------------------------------------------------------------------- >>> -- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> -------------------------------------------------------------------- >>> -- >>> Ericsson AB | Phone +46 10 7148287 >>> Fdrvgatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> -------------------------------------------------------------------- >>> -- >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >> >> > > > -- > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Fdrvgatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Nov 20 06:19:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B45B28C15C for ; Fri, 20 Nov 2009 06:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt98xJywvuA9 for ; Fri, 20 Nov 2009 06:19:58 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2F9DF28C158 for ; Fri, 20 Nov 2009 06:19:57 -0800 (PST) X-AuditID: c1b4fb24-b7b67ae000001a2a-4c-4b06a58a62a6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4C.31.06698.A85A60B4; Fri, 20 Nov 2009 15:19:54 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 15:19:54 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 15:19:53 +0100 Message-ID: <4B06A589.1020800@ericsson.com> Date: Fri, 20 Nov 2009 15:19:53 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yoshifumi Nishida References: <4AFB7024.8030503@ericsson.com> <385671C6-967F-4908-8928-E70ADED5AB75@cs.ucl.ac.uk> <4B03F326.6090302@ericsson.com> <20091120.202013.237337710.nishida@sfc.wide.ad.jp> In-Reply-To: <20091120.202013.237337710.nishida@sfc.wide.ad.jp> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Nov 2009 14:19:53.0993 (UTC) FILETIME=[877F0F90:01CA69EC] X-Brightmail-Tracker: AAAAAA== Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 14:19:59 -0000 Yoshifumi Nishida skrev: > Hello Magnus, > > Correct me if I'm wrong.. > It seems to me that you want to support NAT-NAT communication (both subflow ends > are behind NAT) in mptcp, while the current proposal try to support only > NAT-global communication. It is one potential. Currently simultaneous open doesn't work particular well in NATs. The success rate is around 40% if I remember correctly. > > If we really want to support NAT-NAT communication, I think we might need to have > something like stun server somewhere on the Internet to know the external IP and > port of the interface, or we need to have knowledge about our NAT or FW, > In anycase, this kind of mechanisms will be outside of mptcp, which might cause > some issues. Yes, I agree that you need external mechanism to tell you your external bound address and port. But that exist today, thus it could potentially be used. > > If you could elaborate your target scenario, it would be very helpful. > First, one peer behind a NAT must work. Secondly, a peer behind a FW must work, including local host FWs. This second requires that one use an explicit port that is opened for reception. Thus ports matters and may potentially be different. Third, I think the WG should at least consider what simultaneous open means for MPTCP sub-flows. It is a feature of regular TCP. It might not work that well with NATs and FWs. > For 2, I think having longer auth-token can mitigate this, so it might not > be a very serious issue. > As long as you think about it. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Nov 20 06:24:58 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED283A6AD3 for ; Fri, 20 Nov 2009 06:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXawe5s3jDQV for ; Fri, 20 Nov 2009 06:24:57 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 029903A6946 for ; Fri, 20 Nov 2009 06:24:56 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-dd-4b06a6b57573 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0D.D7.24094.5B6A60B4; Fri, 20 Nov 2009 15:24:53 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 15:24:53 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 15:24:52 +0100 Message-ID: <4B06A6B4.2080908@ericsson.com> Date: Fri, 20 Nov 2009 15:24:52 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Costin Raiciu References: <4AFB7024.8030503@ericsson.com> <385671C6-967F-4908-8928-E70ADED5AB75@cs.ucl.ac.uk> <4B03F326.6090302@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Nov 2009 14:24:52.0873 (UTC) FILETIME=[39A48790:01CA69ED] X-Brightmail-Tracker: AAAAAA== Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 14:24:58 -0000 Costin Raiciu skrev: > Hi Magnus, > > In case 1, do you assume a local firewall? I guess in that case the > stack can just inform the firewall about the open port, without actually > binding it. I have no idea how this is done today - does the firewall > monitor bound/listeninng ports? Today, it appears that you bind to a socket, which makes the FW check the rules for the application that is binding and if the port number is allowed. Variations exist. For non-local firewalls, you can open a particular port for a service, thus you end up with a requirement to use a particular port, otherwise it doesn't work. I am convinced that you will need to be able to indicate the address and port on which you are listening to make MPTCP to be reasonably applicable. Otherwise you will find numerous issues where the SYN simply goes to dev/null. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From c.raiciu@cs.ucl.ac.uk Fri Nov 20 08:11:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1E23A692F for ; Fri, 20 Nov 2009 08:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrTx4w5VgypW for ; Fri, 20 Nov 2009 08:11:57 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 59E733A67E7 for ; Fri, 20 Nov 2009 08:11:55 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1NBW15-000F5x-Ty; Fri, 20 Nov 2009 16:07:23 +0000 In-Reply-To: <4B06A6B4.2080908@ericsson.com> References: <4AFB7024.8030503@ericsson.com> <385671C6-967F-4908-8928-E70ADED5AB75@cs.ucl.ac.uk> <4B03F326.6090302@ericsson.com> <4B06A6B4.2080908@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Fri, 20 Nov 2009 16:11:44 +0000 To: Magnus Westerlund X-Mailer: Apple Mail (2.753.1) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:11:59 -0000 Magnus, You've convinced me :). Costin On 20 Nov 2009, at 14:24, Magnus Westerlund wrote: > Costin Raiciu skrev: >> Hi Magnus, >> >> In case 1, do you assume a local firewall? I guess in that case the >> stack can just inform the firewall about the open port, without >> actually >> binding it. I have no idea how this is done today - does the firewall >> monitor bound/listeninng ports? > > Today, it appears that you bind to a socket, which makes the FW check > the rules for the application that is binding and if the port > number is > allowed. Variations exist. > > For non-local firewalls, you can open a particular port for a service, > thus you end up with a requirement to use a particular port, otherwise > it doesn't work. > > I am convinced that you will need to be able to indicate the > address and > port on which you are listening to make MPTCP to be reasonably > applicable. Otherwise you will find numerous issues where the SYN > simply > goes to dev/null. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Fdrvgatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nishida@sfc.wide.ad.jp Sun Nov 22 16:22:24 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781713A67D3 for ; Sun, 22 Nov 2009 16:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIYiN4dY196j for ; Sun, 22 Nov 2009 16:22:23 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 6C06D3A67A1 for ; Sun, 22 Nov 2009 16:22:23 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 112D64C13D; Mon, 23 Nov 2009 09:22:15 +0900 (JST) Date: Mon, 23 Nov 2009 09:22:14 +0900 (JST) Message-Id: <20091123.092214.140617438.nishida@sfc.wide.ad.jp> To: pasi.sarolahti@iki.fi From: Yoshifumi Nishida In-Reply-To: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] API: which address to use X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 00:22:24 -0000 Hello Pasi, I like the idea. But I have several questions. I think there might be an alternative: having SOCK_MULTISTREAM or using a combination socket type like SOCK_STREAM | SOCK_MULTIPATH from the following reasons. Strictly speaking, AF_MULTIPATH is not a new address type. SCTP socket can be created with AF_INET or AF_INET6, but the socket can support multiple addresses. It's a bit orthgonal behavior from AF_MULTIPATH If the main point of having AF_MULTIPATH is to distinguish between the current TCP socket and multipath TCP socket, using SOCK_MULTISTRAM is not a problem. we might support one-ended approach with the same API. Also, in my feeling, we will need new bind(), connect() to specify multiple addresses. just like sctp_bindx(), sctp_connectx(). Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Pasi Sarolahti Subject: Re: [multipathtcp] API: which address to use Date: Tue, 10 Nov 2009 14:01:59 +0900 Message-ID: > On Nov 9, 2009, at 10:42 PM, William Herrin wrote: > > > On Mon, Nov 9, 2009 at 5:49 AM, Pasi Sarolahti > > wrote: > >> This problem was just discussed in the meeting. Could one possible > >> solution > >> to the getsockname semantics problem be to use a separate address > >> family for > >> multipath connections? It could be similarly structured to the > >> traditional > >> AF, but from the different AF the app would know the semantics are > >> different. > > > > Not really, no. > > > > Backwards compatibility is an issue, as you mentioned. So is a desire > > to be able to use both IPv4 and IPv6 paths in a single multipath TCP > > connection. If it's a legacy app then it's expecting getsockname to > > return the same address family that it used to initiate the socket. If > > you provide something else you could open a path for buffer overflows > > or other mischief. > > Ok, so there could be a non-backwards compatible way and a > (pseudo)backwards compatible way. I don't think these had to be > exclusive, and both could be supported at the same time. > > Non-backwards compatible version would be to use new AF_MULTIPATH, > that would be an array of AF_INET and AF_INET6 entries. Of course that > would need to be used consistently throughout the connection > lifetime. gethostname and getpeername would return the current set of > active addresses at local or remote end. bind() could use this to bind > to several addresses at a time. connect() could use this to give more > than one known destination addresses to connect to (although the MPTCP > protocol logic may prevent the actual connect operation from happening > simultaneously). gethostbyname might return several addresses from > DNS in a single AF_MULTIPATH record, to be directly used by > connect(AF_MULTIPATH), instead of needing to cycle through the > addresses separately, as a traditional single-homed version would > do. This would require modifications also elsewhere than TCP code, but > that's what you get for having an API that exposes the IP address to > the application and assumes only one address is in use at a time. > > The backwards compatible version could just return the oldest active > address and hope nothing breaks on legacy apps. I don't know if this > is better or worse choice than returning the first used address that > might not exist anymore. Has it been specified anywhere that > getsockname/getpeername should return same result through the > connection lifetime? > > - Pasi > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nishida@sfc.wide.ad.jp Sun Nov 22 16:44:14 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0063A6989 for ; Sun, 22 Nov 2009 16:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.204 X-Spam-Level: ** X-Spam-Status: No, score=2.204 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbZk-5JmSmeO for ; Sun, 22 Nov 2009 16:44:13 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id D13E83A6903 for ; Sun, 22 Nov 2009 16:44:13 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6C8834C5EF for ; Mon, 23 Nov 2009 09:44:04 +0900 (JST) Date: Mon, 23 Nov 2009 09:44:04 +0900 (JST) Message-Id: <20091123.094404.171714767.nishida@sfc.wide.ad.jp> To: multipathtcp@ietf.org From: Yoshifumi Nishida In-Reply-To: <20091123.092214.140617438.nishida@sfc.wide.ad.jp> References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [multipathtcp] draft minute at IETF76 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 00:44:14 -0000 Hello people, Sorry for the delay. I've just uploaded the draft version of the minute at IETF76. Please check the following URL to see if there is any problem. http://www.ietf.org/proceedings/09nov/minutes/mptcp.txt Thanks for everyone to attend very active and productive discussions, also we really appreciate Scott and Andrew for very precise note taking. Cheers, -- Phil and Yoshifumi From pasi.sarolahti@iki.fi Mon Nov 23 13:40:12 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F3D28C1BF for ; Mon, 23 Nov 2009 13:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtR7FT1Py1LK for ; Mon, 23 Nov 2009 13:40:11 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 3A6A128C1B6 for ; Mon, 23 Nov 2009 13:40:11 -0800 (PST) Received: from wifi172.ICSI.Berkeley.EDU (wifi172.ICSI.Berkeley.EDU [192.150.187.172]) by argo.otaverkko.fi (Postfix) with ESMTP id B164625ED06; Mon, 23 Nov 2009 23:40:05 +0200 (EET) Message-Id: <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> From: Pasi Sarolahti To: Yoshifumi Nishida , multipathtcp@ietf.org In-Reply-To: <20091123.092214.140617438.nishida@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Nov 2009 13:40:02 -0800 References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> X-Mailer: Apple Mail (2.936) Subject: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:40:12 -0000 Hi, (changed the topic line, it was earlier "API: which address to use". I'm responding to Yoshifumi below, but first wanted to post a general note.) I wrote down some further thinking about the idea of multipath address family in the form of Internet-Draft, which I thought to be better than a long Email to the list. The draft is available at http://tools.ietf.org/html/draft-sarolahti-mptcp-af-multipath-00 and I'd be happy to hear further comments about it. I think a new address family would be a minimal needed change to the current socket API, without extending the API with new operations, but yet provide an interface to handle multiple addresses in a socket. One potentially useful characteristic would be that this would allow name resolver to return multiple IPv4 and/or IPv6 addresses from the name server as a single sockaddr structure, that could be directly given as a parameter to a connect call, which would lead to trying which of the addresses are reachable for the MPTCP session. Traditionally this has been done in the applications, by cycling through the returned addresses from resolver one by one, until connect is successful. Especially dual-stack IPv6/IPv4 hosts should find such feature useful. Yoshifumi- thanks for your comments! Some responses inline below. On Nov 22, 2009, at 4:22 PM, Yoshifumi Nishida wrote: > I like the idea. > But I have several questions. I think there might be an alternative: > having > SOCK_MULTISTREAM or using a combination socket type like SOCK_STREAM > | SOCK_MULTIPATH > from the following reasons. I have thought the 'type' parameter in the socket call to specify the semantics of the socket functions such as read and write. To my understanding the purpose of the MPTCP exercise is to maintain similar read/write semantics to TCP, so if successful in this goal, the socket behavior should be equal to SOCK_STREAM. Or to put it differently, MPTCP is not a new protocol, it is just a (fairly large) modification to TCP. > Strictly speaking, AF_MULTIPATH is not a new address type. I see it as a kind of a super - address family: union of existing address families. But I think that would still fit under a definition of "address family". I understand that there might be different interpretations of what "address family" means, but if there is one specified & correct definition, I'd like to learn about it. > SCTP socket can be created with AF_INET or AF_INET6, but the socket > can > support multiple addresses. It's a bit orthgonal behavior from > AF_MULTIPATH Yes, earlier protocols have done something different for their API. But I'd be interested to learn if there is something why the earlier protocols couldn't begin using something like multipath address family. > If the main point of having AF_MULTIPATH is to distinguish between > the current > TCP socket and multipath TCP socket, using SOCK_MULTISTRAM is not a > problem. In my opinion, the main purpose is to be able to present multiple addresses associated with the same TCP socket. But different address family could be used to distinguish between multi- and singlehomed operations, too. > we might support one-ended approach with the same API. Yep, and that should be possible with AF_MULTIPATH, by having just one address in the address list. I think there might be cases where even single-homed TCP connections might benefit from multiaddress API, even if they ended up using just one of the given addresses at both ends (referring to the name resolver example above). > Also, in my feeling, we will need new bind(), connect() to specify > multiple > addresses. just like sctp_bindx(), sctp_connectx(). I think that adding completely new operations to the good old socket API might be problematic, and would lead to a more updating / maintenance burden in different systems and applications than a new address family would do. But I might be missing something in the required complexity of adding a new address family. - Pasi From olivier.bonaventure@uclouvain.be Tue Nov 24 02:20:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEA03A699C for ; Tue, 24 Nov 2009 02:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmL3RACwoFrs for ; Tue, 24 Nov 2009 02:20:40 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id B69853A68FE for ; Tue, 24 Nov 2009 02:20:39 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E3F54F24A8; Tue, 24 Nov 2009 11:20:14 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be E3F54F24A8 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1259058014; bh=iGB3EObMAgbQ3J2MDcw7nAUFklAsl9HeWiC8dgjSu8g=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=h1sqFwDIG0fc9HV8eDdqhHAsODW4jjEpyvA0QMG3t99scfl0KNlgr5Mf5UYrMk5+B Gn46BKxTp+xUN+rA1blpnVY8LC6sKDQ+kaESKitjCGjdx/Oiw881AZ0C487KElYKnR t3tbZARJ1gbJZbHce/xTT/5hx4Sy0Z5e17qyFgXI= Message-ID: <4B0BB35E.207@uclouvain.be> Date: Tue, 24 Nov 2009 11:20:14 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Pasi Sarolahti References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> In-Reply-To: <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: E3F54F24A8.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 24 Nov 2009 10:20:40 -0000 Pasi, > > (changed the topic line, it was earlier "API: which address to use". I'm > responding to Yoshifumi below, but first wanted to post a general note.) > > I wrote down some further thinking about the idea of multipath address > family in the form of Internet-Draft, which I thought to be better than > a long Email to the list. The draft is available at > http://tools.ietf.org/html/draft-sarolahti-mptcp-af-multipath-00 and I'd > be happy to hear further comments about it. > > I think a new address family would be a minimal needed change to the > current socket API, without extending the API with new operations, but > yet provide an interface to handle multiple addresses in a socket. One > potentially useful characteristic would be that this would allow name > resolver to return multiple IPv4 and/or IPv6 addresses from the name > server as a single sockaddr structure, that could be directly given as a > parameter to a connect call, which would lead to trying which of the > addresses are reachable for the MPTCP session. Traditionally this has > been done in the applications, by cycling through the returned addresses > from resolver one by one, until connect is successful. Especially > dual-stack IPv6/IPv4 hosts should find such feature useful. This could be interesting, but if we change de socket API, why don't we define a new structure that can handle DNS names in addition to IPv4 and IPv6 addresses. This would allow some applications to simply call connect with a DNS name and let the transport protocol figure out whether single path IPv4, single path IPv6, multipath whatever ... should be used to reach this DNS name. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From C.Raiciu@cs.ucl.ac.uk Tue Nov 24 03:33:55 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4063A69C0 for ; Tue, 24 Nov 2009 03:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3A+FCXL9hcm for ; Tue, 24 Nov 2009 03:33:55 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by core3.amsl.com (Postfix) with SMTP id B32493A69C5 for ; Tue, 24 Nov 2009 03:33:54 -0800 (PST) Received: from bells3.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 24 Nov 2009 11:33:40 +0000 Received: from prayer by bells3.cs.ucl.ac.uk with local (Exim 4.54) id 1NCtaV-000Ie3-4U for multipathtcp@ietf.org; Tue, 24 Nov 2009 11:29:39 +0000 From: C.Raiciu@cs.ucl.ac.uk To: multipathtcp@ietf.org Date: 24 Nov 2009 11:29:38 +0000 X-Mailer: Prayer v1.0.16 X-Originating-IP: [128.16.13.139] Message-ID: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Subject: [multipathtcp] Tech report on congestion control coupling X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 11:33:55 -0000 Hi all, We've posted a work-in-progress tech report titled "Practical Congestion Control for Multipath Transport Protocols" that contains the experiments we've been running with coupled congestion control, as well as the theory behind it. This complements the information in the congestion control draft (draft-raiciu-mptcp-congestion-00). The tech report is linked on the multipath resources page: http://nrg.cs.ucl.ac.uk/mptcp/index.html Looking forward to your feedback. Thanks, Costin From C.Raiciu@cs.ucl.ac.uk Tue Nov 24 03:38:38 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9309A28C0FA for ; Tue, 24 Nov 2009 03:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlk0ivP7MbRA for ; Tue, 24 Nov 2009 03:38:37 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by core3.amsl.com (Postfix) with SMTP id 9EBFB3A68E4 for ; Tue, 24 Nov 2009 03:38:37 -0800 (PST) Received: from bells3.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 24 Nov 2009 11:38:30 +0000 Received: from prayer by bells3.cs.ucl.ac.uk with local (Exim 4.54) id 1NCtfB-000If7-9w for multipathtcp@ietf.org; Tue, 24 Nov 2009 11:34:29 +0000 From: C.Raiciu@cs.ucl.ac.uk To: multipathtcp@ietf.org Date: 24 Nov 2009 11:34:29 +0000 X-Mailer: Prayer v1.0.16 X-Originating-IP: [128.16.13.139] Message-ID: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Subject: [multipathtcp] MPTCP code available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 11:38:38 -0000 Hi, Initial releases of the userland implementation of MPTCP (v0.1, http://nrg.cs.ucl.ac.uk/mptcp/mptcp_userland_0.1.tar.gz) and a packet-level simulator implementation of coupled congestion control (v0.1, http://nrg.cs.ucl.ac.uk/mptcp/htsim_0.1.tar.gz) are available. Summaries of these can be found on the multipath implementation page http://nrg.cs.ucl.ac.uk/mptcp/implementation.html The code is far from production quality, but we think they are in good enough shape for people to play with and get insights into how multipath and congestion control works. Looking forward to your opinions. Thanks, Costin From wherrin@gmail.com Tue Nov 24 04:35:03 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4328328C125 for ; Tue, 24 Nov 2009 04:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F07Ep5+TDEwd for ; Tue, 24 Nov 2009 04:35:02 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id B204A28C124 for ; Tue, 24 Nov 2009 04:35:01 -0800 (PST) Received: by ewy7 with SMTP id 7so12699ewy.28 for ; Tue, 24 Nov 2009 04:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=TKbADgD2go2R3pIsnkdFQDbPhzrgEdCGJ5B1IUHqRPs=; b=arQjhbv+vsPaBQlTZTqO6vH18+17f9DuJFq9sjmnCAuR58uy4zotXa5hmqVT8qsCUp CeYbrffXEP/2LdKChpyMK5A+/JZmYnYzaoRaOZ5gHbeCfEWHTdABvs4/JlelIkpWIddP zg/9pGEC4T+KCu+VYD6z/ObyDXB/aPNC/pN2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ewLQq23uIG59J6SSQDBNMQqXxMyqyaxw5WluVGLguio72r7vXmP20RJOVefquu7nhm dUci/wFmU0ZEsqiY6HjcccFyJzUy3M6b6nCnW13d513fpvcSRsF709nM+p48X/aHpknS DsoWu/HNAzJA6bQMtHy1FlDge63AkbPYAkAcw= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.88.201 with SMTP id a51mr1941861wef.154.1259066088424; Tue, 24 Nov 2009 04:34:48 -0800 (PST) In-Reply-To: <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> Date: Tue, 24 Nov 2009 07:34:48 -0500 X-Google-Sender-Auth: 65a32bd2d7b3c915 Message-ID: <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> From: William Herrin To: Pasi Sarolahti Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 12:35:03 -0000 On Mon, Nov 23, 2009 at 4:40 PM, Pasi Sarolahti wrote: > I think a new address family would be a minimal needed change to the current > socket API, without extending the API with new operations, but yet provide > an interface to handle multiple addresses in a socket. One potentially > useful characteristic would be that this would allow name resolver to return > multiple IPv4 and/or IPv6 addresses from the name server as a single > sockaddr structure, that could be directly given as a parameter to a connect > call, which would lead to trying which of the addresses are reachable for > the MPTCP session. Hi Pasi, It seems like you want to preserve the connect() call's parameters by altering the definition of sockaddr so that it can contain multiple addresses. But functionally, what we really want to do is pass an array of sockaddrs to connect(). Stupid question time: what makes redefining sockaddr superior to an extended API call that supplants connect() and accepts an array of sockaddrs? Poking around linux's include files (netinet/in.h, bits/socket.h) I notice that they go to a lot of trouble to make all sockaddrs come out to exactly the same number of bytes. Won't a variable length sockaddr that holds a variable number of addresses make a mess of that? >> SOCK_MULTISTREAM or using a combination socket type like SOCK_STREAM | >> SOCK_MULTIPATH >> from the following reasons. Found a quote I think bears on the topic at http://lkml.indiana.edu/hypermail/linux/net/9904.2/0091.html : >The AF_ prefix stands for "address family" and the PF_prefix stands for >"protocol family". Historicly, the intent was that a single protocol family >might support multiple address families and that the PF_ value was used to >create the socket and the AF_ value was used in socket address structures. >But in actuality, a protocol family supporting multiple address families has >never been supported and the header defines the PF_ value >for a given protocol to be equal to the AF_ value for that protocol. I think when we discuss allowing multipath TCP to use IPv4 and IPv6 addresses interchangeably, we're talking about one protocol family using multiple address families, are we not? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Michael.Tuexen@lurchi.franken.de Tue Nov 24 13:05:20 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46383A68D5 for ; Tue, 24 Nov 2009 13:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=-2.125, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNI9zRvKcopS for ; Tue, 24 Nov 2009 13:05:17 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 875A83A6819 for ; Tue, 24 Nov 2009 13:05:16 -0800 (PST) Received: from [192.168.20.2] (tmo-109-243.customers.d1-online.com [80.187.109.243]) by mail-n.franken.de (Postfix) with ESMTP id 52D1D1C0B4042; Tue, 24 Nov 2009 22:05:03 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> Date: Tue, 24 Nov 2009 22:04:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <151407D2-293C-4B4A-845C-0DAE958CD347@lurchi.franken.de> References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> To: Pasi Sarolahti X-Mailer: Apple Mail (2.1077) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:05:20 -0000 On Nov 23, 2009, at 10:40 PM, Pasi Sarolahti wrote: > Hi, >=20 > (changed the topic line, it was earlier "API: which address to use". = I'm responding to Yoshifumi below, but first wanted to post a general = note.) >=20 > I wrote down some further thinking about the idea of multipath address = family in the form of Internet-Draft, which I thought to be better than = a long Email to the list. The draft is available at = http://tools.ietf.org/html/draft-sarolahti-mptcp-af-multipath-00 and I'd = be happy to hear further comments about it. >=20 > I think a new address family would be a minimal needed change to the = current socket API, without extending the API with new operations, but = yet provide an interface to handle multiple addresses in a socket. One = potentially useful characteristic would be that this would allow name = resolver to return multiple IPv4 and/or IPv6 addresses from the name = server as a single sockaddr structure, that could be directly given as a = parameter to a connect call, which would lead to trying which of the = addresses are reachable for the MPTCP session. Traditionally this has = been done in the applications, by cycling through the returned addresses = from resolver one by one, until connect is successful. Especially = dual-stack IPv6/IPv4 hosts should find such feature useful. There is one thing that I do not understand. Currently there is no way a = DNS server resolves a name indicating that all addresses belong to the same = host. You just get a list of addresses. They might belong to one host or not. At least for SCTP this is important and makes it impossible to use DNS = to resolve a name to multiple addresses belonging to the same host. Best regards Michael >=20 > Yoshifumi- thanks for your comments! Some responses inline below. >=20 > On Nov 22, 2009, at 4:22 PM, Yoshifumi Nishida wrote: >=20 >> I like the idea. >> But I have several questions. I think there might be an alternative: = having >> SOCK_MULTISTREAM or using a combination socket type like SOCK_STREAM = | SOCK_MULTIPATH >> from the following reasons. >=20 > I have thought the 'type' parameter in the socket call to specify the = semantics of the socket functions such as read and write. To my = understanding the purpose of the MPTCP exercise is to maintain similar = read/write semantics to TCP, so if successful in this goal, the socket = behavior should be equal to SOCK_STREAM. Or to put it differently, MPTCP = is not a new protocol, it is just a (fairly large) modification to TCP. >=20 >> Strictly speaking, AF_MULTIPATH is not a new address type. >=20 > I see it as a kind of a super - address family: union of existing = address families. But I think that would still fit under a definition of = "address family". I understand that there might be different = interpretations of what "address family" means, but if there is one = specified & correct definition, I'd like to learn about it. >=20 >> SCTP socket can be created with AF_INET or AF_INET6, but the socket = can >> support multiple addresses. It's a bit orthgonal behavior from = AF_MULTIPATH >=20 > Yes, earlier protocols have done something different for their API. = But I'd be interested to learn if there is something why the earlier = protocols couldn't begin using something like multipath address family. >=20 >> If the main point of having AF_MULTIPATH is to distinguish between = the current >> TCP socket and multipath TCP socket, using SOCK_MULTISTRAM is not a = problem. >=20 > In my opinion, the main purpose is to be able to present multiple = addresses associated with the same TCP socket. But different address = family could be used to distinguish between multi- and singlehomed = operations, too. >=20 >> we might support one-ended approach with the same API. >=20 > Yep, and that should be possible with AF_MULTIPATH, by having just one = address in the address list. I think there might be cases where even = single-homed TCP connections might benefit from multiaddress API, even = if they ended up using just one of the given addresses at both ends = (referring to the name resolver example above). >=20 >> Also, in my feeling, we will need new bind(), connect() to specify = multiple >> addresses. just like sctp_bindx(), sctp_connectx(). >=20 > I think that adding completely new operations to the good old socket = API might be problematic, and would lead to a more updating / = maintenance burden in different systems and applications than a new = address family would do. But I might be missing something in the = required complexity of adding a new address family. >=20 > - Pasi >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 From Michael.Tuexen@lurchi.franken.de Tue Nov 24 13:08:28 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB1C3A6830 for ; Tue, 24 Nov 2009 13:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.356 X-Spam-Level: X-Spam-Status: No, score=0.356 tagged_above=-999 required=5 tests=[AWL=-1.594, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkoX+7E-T9ev for ; Tue, 24 Nov 2009 13:08:27 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 9B3BE3A682D for ; Tue, 24 Nov 2009 13:08:26 -0800 (PST) Received: from [192.168.20.2] (tmo-109-243.customers.d1-online.com [80.187.109.243]) by mail-n.franken.de (Postfix) with ESMTP id 6EEE51C0B461B; Tue, 24 Nov 2009 22:07:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> Date: Tue, 24 Nov 2009 22:07:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> To: William Herrin X-Mailer: Apple Mail (2.1077) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:08:28 -0000 Dear all, just one note: In SCTP we use sctp_connectx() to connect to multiple addresses. Kacheong pointed a couple of years ago out that a more generic connectx() would make sense to other protocols supporting multihoming as well (but there were no). So you might want to look at sctp_connectx() which the SCTP socket API uses to handle the problem. Best regards Michael On Nov 24, 2009, at 1:34 PM, William Herrin wrote: > On Mon, Nov 23, 2009 at 4:40 PM, Pasi Sarolahti = wrote: >> I think a new address family would be a minimal needed change to the = current >> socket API, without extending the API with new operations, but yet = provide >> an interface to handle multiple addresses in a socket. One = potentially >> useful characteristic would be that this would allow name resolver to = return >> multiple IPv4 and/or IPv6 addresses from the name server as a single >> sockaddr structure, that could be directly given as a parameter to a = connect >> call, which would lead to trying which of the addresses are reachable = for >> the MPTCP session. >=20 > Hi Pasi, >=20 > It seems like you want to preserve the connect() call's parameters by > altering the definition of sockaddr so that it can contain multiple > addresses. >=20 > But functionally, what we really want to do is pass an array of > sockaddrs to connect(). >=20 > Stupid question time: what makes redefining sockaddr superior to an > extended API call that supplants connect() and accepts an array of > sockaddrs? >=20 > Poking around linux's include files (netinet/in.h, bits/socket.h) I > notice that they go to a lot of trouble to make all sockaddrs come out > to exactly the same number of bytes. Won't a variable length sockaddr > that holds a variable number of addresses make a mess of that? >=20 >=20 >>> SOCK_MULTISTREAM or using a combination socket type like SOCK_STREAM = | >>> SOCK_MULTIPATH >>> from the following reasons. >=20 > Found a quote I think bears on the topic at > http://lkml.indiana.edu/hypermail/linux/net/9904.2/0091.html : >=20 >> The AF_ prefix stands for "address family" and the PF_prefix stands = for >> "protocol family". Historicly, the intent was that a single protocol = family >> might support multiple address families and that the PF_ value was = used to >> create the socket and the AF_ value was used in socket address = structures. >> But in actuality, a protocol family supporting multiple address = families has >> never been supported and the header defines the PF_ = value >> for a given protocol to be equal to the AF_ value for that protocol. >=20 > I think when we discuss allowing multipath TCP to use IPv4 and IPv6 > addresses interchangeably, we're talking about one protocol family > using multiple address families, are we not? >=20 > Regards, > Bill Herrin >=20 >=20 >=20 > --=20 > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 From julienl@qualcomm.com Tue Nov 24 14:33:08 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C693A67D9 for ; Tue, 24 Nov 2009 14:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.287 X-Spam-Level: X-Spam-Status: No, score=-105.287 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gJZBId8QJ6H for ; Tue, 24 Nov 2009 14:33:07 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 03CB13A680C for ; Tue, 24 Nov 2009 14:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259101982; x=1290637982; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20=3D?iso-8859-1?Q?Michael_T=3DFCxen?=3D=20,=0D=0A=20=20=20=20=20=20=20=20W illiam=20Herrin=20|CC:=20"multipathtcp@ie tf.org"=20|Date:=20Tue,=2024=20Nov =202009=2014:32:58=20-0800|Subject:=20RE:=20[multipathtcp ]=20Multipath=20Address=20Family|Thread-Topic:=20[multipa thtcp]=20Multipath=20Address=20Family|Thread-Index:=20Acp tSkug6ttsDb7CQgiGbU4S+yHW4QACzqjA|Message-ID:=20|References:=20=0D=0A=09<3c3e3fca0911090542h54e45784qbdbf1f338a 4c3e90@mail.gmail.com>=0D=0A=09=0D=0A=09<20091123.092214.140617438.ni shida@sfc.wide.ad.jp>=0D=0A=09<48DA092B-F3BC-432E-A199-B2 65DDED39DA@iki.fi>=0D=0A=09<3c3e3fca0911240434p4d95ec7an3 4615ae218faa4f@mail.gmail.com>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5812"=3B=20a=3D"28359543"; bh=sfnAJt17PtPHa0fbVbV94jc4CFyLuxQCVQNuZcrbzK4=; b=MzrRrUKw6li3BADVppJ2mTG+WwGqOUcaxgTBPR/9Q7qMALJIlC/CYgC8 rh8AASgN9tCXJ9x4yIPMTJfHy+hBLQRuEusgpWvEKmlhbe/XP/4aSEr+M mXzH79qXKzibBK0p9n8w2qea1atq97ft715gAgJ18u1qfxgJDn0zIUYEI w=; X-IronPort-AV: E=McAfee;i="5400,1158,5812"; a="28359543" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 24 Nov 2009 14:33:02 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAOMX2S6026217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2009 14:33:02 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAOMX1I3013970 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Nov 2009 14:33:01 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 Nov 2009 14:33:01 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 24 Nov 2009 14:33:00 -0800 From: "Laganier, Julien" To: =?iso-8859-1?Q?Michael_T=FCxen?= , William Herrin Date: Tue, 24 Nov 2009 14:32:58 -0800 Thread-Topic: [multipathtcp] Multipath Address Family Thread-Index: AcptSkug6ttsDb7CQgiGbU4S+yHW4QACzqjA Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 22:33:08 -0000 Stuart Cheshire had a nice talk at IETF 72 on the drawbacks of the current = getaddrinfo() + connect() model w.r.t. to IPv6 transition,see http://www.st= uartcheshire.org/IETF72/. (Somebody already mentioned that on the list I th= ink.) A connect_to_name() calls that hides all of the address family subtleties u= nder the hood does not have such drawbacks. So if we're going to change the API anyway, t= his looks like a good occasion to fix that issue too, no? --julien=20 > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of Michael T=FCxen > Sent: Tuesday, November 24, 2009 1:08 PM > To: William Herrin > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] Multipath Address Family >=20 > Dear all, >=20 > just one note: > In SCTP we use sctp_connectx() to connect to multiple addresses. > Kacheong pointed a couple of years ago out that a more generic > connectx() would make sense to other protocols supporting multihoming > as well (but there were no). >=20 > So you might want to look at sctp_connectx() which the SCTP socket API > uses to handle the problem. >=20 > Best regards > Michael >=20 > On Nov 24, 2009, at 1:34 PM, William Herrin wrote: >=20 > > On Mon, Nov 23, 2009 at 4:40 PM, Pasi Sarolahti > wrote: > >> I think a new address family would be a minimal needed change to the > current > >> socket API, without extending the API with new operations, but yet > provide > >> an interface to handle multiple addresses in a socket. One > potentially > >> useful characteristic would be that this would allow name resolver > to return > >> multiple IPv4 and/or IPv6 addresses from the name server as a single > >> sockaddr structure, that could be directly given as a parameter to a > connect > >> call, which would lead to trying which of the addresses are > reachable for > >> the MPTCP session. > > > > Hi Pasi, > > > > It seems like you want to preserve the connect() call's parameters by > > altering the definition of sockaddr so that it can contain multiple > > addresses. > > > > But functionally, what we really want to do is pass an array of > > sockaddrs to connect(). > > > > Stupid question time: what makes redefining sockaddr superior to an > > extended API call that supplants connect() and accepts an array of > > sockaddrs? > > > > Poking around linux's include files (netinet/in.h, bits/socket.h) I > > notice that they go to a lot of trouble to make all sockaddrs come > out > > to exactly the same number of bytes. Won't a variable length sockaddr > > that holds a variable number of addresses make a mess of that? > > > > > >>> SOCK_MULTISTREAM or using a combination socket type like > SOCK_STREAM | > >>> SOCK_MULTIPATH > >>> from the following reasons. > > > > Found a quote I think bears on the topic at > > http://lkml.indiana.edu/hypermail/linux/net/9904.2/0091.html : > > > >> The AF_ prefix stands for "address family" and the PF_prefix stands > for > >> "protocol family". Historicly, the intent was that a single protocol > family > >> might support multiple address families and that the PF_ value was > used to > >> create the socket and the AF_ value was used in socket address > structures. > >> But in actuality, a protocol family supporting multiple address > families has > >> never been supported and the header defines the PF_ > value > >> for a given protocol to be equal to the AF_ value for that protocol. > > > > I think when we discuss allowing multipath TCP to use IPv4 and IPv6 > > addresses interchangeably, we're talking about one protocol family > > using multiple address families, are we not? > > > > Regards, > > Bill Herrin > > > > > > > > -- > > William D. Herrin ................ herrin@dirtside.com > bill@herrin.us > > 3005 Crane Dr. ...................... Web: > > Falls Church, VA 22042-3004 > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From touch@ISI.EDU Tue Nov 24 14:39:31 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1FB3A692F for ; Tue, 24 Nov 2009 14:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XvDLieGiN80 for ; Tue, 24 Nov 2009 14:39:30 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5113D3A67D9 for ; Tue, 24 Nov 2009 14:39:30 -0800 (PST) Received: from [75.212.132.192] (192.sub-75-212-132.myvzw.com [75.212.132.192]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAOMcokC007947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2009 14:38:53 -0800 (PST) Message-ID: <4B0C607A.6060503@isi.edu> Date: Tue, 24 Nov 2009 14:38:50 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 22:39:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laganier, Julien wrote: > Stuart Cheshire had a nice talk at IETF 72 on the drawbacks of the current getaddrinfo() + connect() model w.r.t. to IPv6 transition,see http://www.stuartcheshire.org/IETF72/. (Somebody already mentioned that on the list I think.) > > A connect_to_name() calls that hides all of the address family subtleties under the hood > does not have such drawbacks. So if we're going to change the API anyway, this looks like a good occasion to fix that issue too, no? I like this idea, but there needs to be a returned primary IP address if this is intended to support TCP. I.e., you can ask the system to call a name, but it ends up establishing a TCP connection to a socket pair (src IP, dst IP, src port, dst port). I'm still not sure what that means for multipath. There could be secondary socket pairs of course, and they can vary over the life of the connection, but I still feel that if the primary disappears the connection MUST disappear *IF* this is TCP. Of course, if it's not TCP, this could be easily defined in other more useful ways. Joe > --julien > >> -----Original Message----- >> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- >> bounces@ietf.org] On Behalf Of Michael Tüxen >> Sent: Tuesday, November 24, 2009 1:08 PM >> To: William Herrin >> Cc: multipathtcp@ietf.org >> Subject: Re: [multipathtcp] Multipath Address Family >> >> Dear all, >> >> just one note: >> In SCTP we use sctp_connectx() to connect to multiple addresses. >> Kacheong pointed a couple of years ago out that a more generic >> connectx() would make sense to other protocols supporting multihoming >> as well (but there were no). >> >> So you might want to look at sctp_connectx() which the SCTP socket API >> uses to handle the problem. >> >> Best regards >> Michael >> >> On Nov 24, 2009, at 1:34 PM, William Herrin wrote: >> >>> On Mon, Nov 23, 2009 at 4:40 PM, Pasi Sarolahti >> wrote: >>>> I think a new address family would be a minimal needed change to the >> current >>>> socket API, without extending the API with new operations, but yet >> provide >>>> an interface to handle multiple addresses in a socket. One >> potentially >>>> useful characteristic would be that this would allow name resolver >> to return >>>> multiple IPv4 and/or IPv6 addresses from the name server as a single >>>> sockaddr structure, that could be directly given as a parameter to a >> connect >>>> call, which would lead to trying which of the addresses are >> reachable for >>>> the MPTCP session. >>> Hi Pasi, >>> >>> It seems like you want to preserve the connect() call's parameters by >>> altering the definition of sockaddr so that it can contain multiple >>> addresses. >>> >>> But functionally, what we really want to do is pass an array of >>> sockaddrs to connect(). >>> >>> Stupid question time: what makes redefining sockaddr superior to an >>> extended API call that supplants connect() and accepts an array of >>> sockaddrs? >>> >>> Poking around linux's include files (netinet/in.h, bits/socket.h) I >>> notice that they go to a lot of trouble to make all sockaddrs come >> out >>> to exactly the same number of bytes. Won't a variable length sockaddr >>> that holds a variable number of addresses make a mess of that? >>> >>> >>>>> SOCK_MULTISTREAM or using a combination socket type like >> SOCK_STREAM | >>>>> SOCK_MULTIPATH >>>>> from the following reasons. >>> Found a quote I think bears on the topic at >>> http://lkml.indiana.edu/hypermail/linux/net/9904.2/0091.html : >>> >>>> The AF_ prefix stands for "address family" and the PF_prefix stands >> for >>>> "protocol family". Historicly, the intent was that a single protocol >> family >>>> might support multiple address families and that the PF_ value was >> used to >>>> create the socket and the AF_ value was used in socket address >> structures. >>>> But in actuality, a protocol family supporting multiple address >> families has >>>> never been supported and the header defines the PF_ >> value >>>> for a given protocol to be equal to the AF_ value for that protocol. >>> I think when we discuss allowing multipath TCP to use IPv4 and IPv6 >>> addresses interchangeably, we're talking about one protocol family >>> using multiple address families, are we not? >>> >>> Regards, >>> Bill Herrin >>> >>> >>> >>> -- >>> William D. Herrin ................ herrin@dirtside.com >> bill@herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksMYHoACgkQE5f5cImnZrsNfACgh9pUrJDwwvYhwDeJFVR/xI0t /NgAoLjph0OwVVfegYKxYx2otnCIh8Pp =fyli -----END PGP SIGNATURE----- From julienl@qualcomm.com Tue Nov 24 14:56:55 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F823A69CB for ; Tue, 24 Nov 2009 14:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.496 X-Spam-Level: X-Spam-Status: No, score=-105.496 tagged_above=-999 required=5 tests=[AWL=1.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhA8AaDcgp8Q for ; Tue, 24 Nov 2009 14:56:54 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 52C5B3A680C for ; Tue, 24 Nov 2009 14:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259103410; x=1290639410; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Joe=20Touch=20|CC:=20=3D?iso-8859-1 ?Q?Michael_T=3DFCxen?=3D=20,=0D=0A=20=20=20=20=20=20=20=20William=20Herrin=20,=0D=0A=20=20=20=20=20=20=20=20"multipathtcp @ietf.org"=0D=0A=09|Date:=20Tue, =2024=20Nov=202009=2014:56:38=20-0800|Subject:=20RE:=20[m ultipathtcp]=20Multipath=20Address=20Family|Thread-Topic: =20[multipathtcp]=20Multipath=20Address=20Family |Thread-Index:=20AcptVwICpPGBacMFR2+gsbjKH66PgAAAX68w |Message-ID:=20|References:=20=0D=0A=09<3c3e3fca091109 0542h54e45784qbdbf1f338a4c3e90@mail.gmail.com>=0D=0A=09=0D=0A=09<2009 1123.092214.140617438.nishida@sfc.wide.ad.jp>=0D=0A=09<48 DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi>=0D=0A=09<3c3e3 fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com>=0D =0A=09=0D=0A=20=0D=0A=20<4B0C607A.6060503@i si.edu>|In-Reply-To:=20<4B0C607A.6060503@isi.edu> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5812"=3B=20a=3D"28361028"; bh=lSvtsAtlGlTKKWIhif6b2qPUJoLr7W5CE8E6PBigcPM=; b=MIjO1/JEV5ML6IqhzlAo+4MzJah5r6T2iuZcrncejwTcfYilMSMFm09U 4jWsqdiGCnyxXhmX7oFkhN5WzpJOJ//Lq1nnsS7C3+NKLO9ZeanGKSEaJ pbk17Yigwk09Pa23znAikvPRmgZNdUdsgBQkNK2YL6/+e80w/PylRZKa3 Y=; X-IronPort-AV: E=McAfee;i="5400,1158,5812"; a="28361028" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 24 Nov 2009 14:56:50 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAOMunsT029126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2009 14:56:49 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAOMueHO019331 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Nov 2009 14:56:41 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 Nov 2009 14:56:40 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Tue, 24 Nov 2009 14:56:40 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Tue, 24 Nov 2009 14:56:39 -0800 From: "Laganier, Julien" To: Joe Touch Date: Tue, 24 Nov 2009 14:56:38 -0800 Thread-Topic: [multipathtcp] Multipath Address Family Thread-Index: AcptVwICpPGBacMFR2+gsbjKH66PgAAAX68w Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> In-Reply-To: <4B0C607A.6060503@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 22:56:55 -0000 Hi, Joe, >=20 > Laganier, Julien wrote: > > Stuart Cheshire had a nice talk at IETF 72 on the drawbacks of the > > current getaddrinfo() + connect() model w.r.t. to IPv6 transition,see > > http://www.stuartcheshire.org/IETF72/. (Somebody already mentioned that > > on the list I think.) > > > > A connect_to_name() calls that hides all of the address family > > subtleties under the hood > > does not have such drawbacks. So if we're going to change the API > > anyway, this looks like a good occasion to fix that issue too, no? >=20 > I like this idea, but there needs to be a returned primary IP address > if this is intended to support TCP. I.e., you can ask the system to call > a name, but it ends up establishing a TCP connection to a socket pair > (src IP, dst IP, src port, dst port). >=20 > I'm still not sure what that means for multipath. There could be > secondary socket pairs of course, and they can vary over the life of > the connection, but I still feel that if the primary disappears the > connection MUST disappear *IF* this is TCP. >=20 > Of course, if it's not TCP, this could be easily defined in other more > useful ways. Without taking position with respect to fate-sharing between the MPTCP conn= ection and the original address-port pair, whether the MPTCP connection is = torn down when the original address-port pair fails is, I think, an issue o= rthogonal to the specifics of how an application connects to a peer. In both case we can introduce the connect_to_name() call in the new API. Orthogonal to that, if we decide we want to treat the initial address pair(= ) that got used to establish the MPTCP connection in a special fashion, e.g= ., fate-sharing, we can still do so by defining the behavior in the protoco= l specification. Makes sense? --julien From touch@ISI.EDU Tue Nov 24 15:01:03 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312913A6917 for ; Tue, 24 Nov 2009 15:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qnhm8IwBK4Ki for ; Tue, 24 Nov 2009 15:01:02 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2C76E3A67AF for ; Tue, 24 Nov 2009 15:01:02 -0800 (PST) Received: from [75.212.132.192] (192.sub-75-212-132.myvzw.com [75.212.132.192]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAON0XeP013313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2009 15:00:36 -0800 (PST) Message-ID: <4B0C6590.9010000@isi.edu> Date: Tue, 24 Nov 2009 15:00:32 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:01:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laganier, Julien wrote: > Hi, Joe, >> Laganier, Julien wrote: >>> Stuart Cheshire had a nice talk at IETF 72 on the drawbacks of the >>> current getaddrinfo() + connect() model w.r.t. to IPv6 transition,see >>> http://www.stuartcheshire.org/IETF72/. (Somebody already mentioned that >>> on the list I think.) >>> >>> A connect_to_name() calls that hides all of the address family >>> subtleties under the hood >>> does not have such drawbacks. So if we're going to change the API >>> anyway, this looks like a good occasion to fix that issue too, no? >> I like this idea, but there needs to be a returned primary IP address >> if this is intended to support TCP. I.e., you can ask the system to call >> a name, but it ends up establishing a TCP connection to a socket pair >> (src IP, dst IP, src port, dst port). >> >> I'm still not sure what that means for multipath. There could be >> secondary socket pairs of course, and they can vary over the life of >> the connection, but I still feel that if the primary disappears the >> connection MUST disappear *IF* this is TCP. >> >> Of course, if it's not TCP, this could be easily defined in other more >> useful ways. > > Without taking position with respect to fate-sharing between the MPTCP > connection and the original address-port pair, whether the MPTCP > connection is torn down when the original address-port pair fails is, I > think, an issue orthogonal to the specifics of how an application > connects to a peer. > > In both case we can introduce the connect_to_name() call in the new > API. > > Orthogonal to that, if we decide we want to treat the initial address > pair() that got used to establish the MPTCP connection in a special > fashion, e.g., fate-sharing, we can still do so by defining the behavior > in the protocol specification. > > Makes sense? Sure, but either way you need to return at least the primary IP address/port pair as results of the connect_to_name() call. It's not sufficient to return an undistinguished set of such pairs, nor is it sufficient to not return any such pairs. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksMZZAACgkQE5f5cImnZruRSgCgzsQOWsLxX9olLpTzfL6epwn6 xIkAoKGYJQIgG0maVbyJ9quDS6VQg0s2 =ozME -----END PGP SIGNATURE----- From julienl@qualcomm.com Tue Nov 24 15:09:02 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A9D3A67AB for ; Tue, 24 Nov 2009 15:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.557 X-Spam-Level: X-Spam-Status: No, score=-105.557 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1QwwrwiNPXg for ; Tue, 24 Nov 2009 15:09:01 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 104AB3A67AF for ; Tue, 24 Nov 2009 15:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259104137; x=1290640137; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Joe=20Touch=20|CC:=20=3D?iso-8859-1 ?Q?Michael_T=3DFCxen?=3D=20,=0D=0A=20=20=20=20=20=20=20=20William=20Herrin=20,=0D=0A=20=20=20=20=20=20=20=20"multipathtcp @ietf.org"=0D=0A=09|Date:=20Tue, =2024=20Nov=202009=2015:08:53=20-0800|Subject:=20RE:=20[m ultipathtcp]=20Multipath=20Address=20Family|Thread-Topic: =20[multipathtcp]=20Multipath=20Address=20Family |Thread-Index:=20AcptWf7TjHI3SaBvSI63YCuPXEvTKQAACg5g |Message-ID:=20|References:=20=0D=0A=09<3c3e3fca091109 0542h54e45784qbdbf1f338a4c3e90@mail.gmail.com>=0D=0A=09=0D=0A=09<2009 1123.092214.140617438.nishida@sfc.wide.ad.jp>=0D=0A=09<48 DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi>=0D=0A=09<3c3e3 fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com>=0D =0A=09=0D=0A=20=0D=0A=20<4B0C607A.6060503@i si.edu>=0D=0A=20=0D=0A=20<4B0C6590.9010000 @isi.edu>|In-Reply-To:=20<4B0C6590.9010000@isi.edu> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5812"=3B=20a=3D"28361850"; bh=bkDV/cH2/c6Bfo++7p6fzKFpuBOVlUYyjAXzMPOYGv8=; b=AdwliOEF2yrj0BwlzxRbdfNCdYnyNfJAliQeG3AXe97NVPs4AwwPAi0Q 9qOYBkLBF9mohlaqaTRUP7ubZUjc21oE4kBrTn1nnfvrBQu6o734tNO7y ++5exvZ7h8URieDe+wxOvrSjMgrmj7yP/zIsADVjjk4A2+0CvE16Yth0+ A=; X-IronPort-AV: E=McAfee;i="5400,1158,5812"; a="28361850" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 24 Nov 2009 15:08:56 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAON8uqP030552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2009 15:08:56 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAON8tMl021529 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Nov 2009 15:08:56 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 Nov 2009 15:08:55 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 24 Nov 2009 15:08:55 -0800 From: "Laganier, Julien" To: Joe Touch Date: Tue, 24 Nov 2009 15:08:53 -0800 Thread-Topic: [multipathtcp] Multipath Address Family Thread-Index: AcptWf7TjHI3SaBvSI63YCuPXEvTKQAACg5g Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> In-Reply-To: <4B0C6590.9010000@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:09:02 -0000 Joe Touch wrote: > Laganier, Julien wrote: > > Hi, Joe, > >> Laganier, Julien wrote: > >>> Stuart Cheshire had a nice talk at IETF 72 on the drawbacks of the > >>> current getaddrinfo() + connect() model w.r.t. to IPv6 transition, > >>> see http://www.stuartcheshire.org/IETF72/. (Somebody already mentione= d > >>> that on the list I think.) > >>> > >>> A connect_to_name() calls that hides all of the address family > >>> subtleties under the hood > >>> does not have such drawbacks. So if we're going to change the API > >>> anyway, this looks like a good occasion to fix that issue too, no? > >> > >> I like this idea, but there needs to be a returned primary IP > >> address if this is intended to support TCP. I.e., you can ask the syst= em > >> to call a name, but it ends up establishing a TCP connection to a sock= et > >> pair (src IP, dst IP, src port, dst port). > >> > >> I'm still not sure what that means for multipath. There could be > >> secondary socket pairs of course, and they can vary over the life of > >> the connection, but I still feel that if the primary disappears the > >> connection MUST disappear *IF* this is TCP. > >> > >> Of course, if it's not TCP, this could be easily defined in other > >> more useful ways. > > > > Without taking position with respect to fate-sharing between the > > MPTCP connection and the original address-port pair, whether the MPTCP > > connection is torn down when the original address-port pair fails is, > > I think, an issue orthogonal to the specifics of how an application > > connects to a peer. > > > > In both case we can introduce the connect_to_name() call in the new > > API. > > > > Orthogonal to that, if we decide we want to treat the initial address > > pair() that got used to establish the MPTCP connection in a special > > fashion, e.g., fate-sharing, we can still do so by defining the > > behavior in the protocol specification. > > > > Makes sense? >=20 > Sure, but either way you need to return at least the primary IP > address/port pair as results of the connect_to_name() call. >=20 > It's not sufficient to return an undistinguished set of such pairs, nor > is it sufficient to not return any such pairs. Unless the socket has been bind()'ed earlier, connect() doesn't return to t= he caller any information about the address/port that was picked as a resul= t of the connect(). The application would need to call getsockname() to kno= w what address/port pair was used.=20 If an application is modified to use the new API, it will have to use getpe= ername() in addition to getsockname() to know what initial address pair has= been connected. --julien From touch@ISI.EDU Tue Nov 24 15:29:11 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383313A6891 for ; Tue, 24 Nov 2009 15:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAYwt+5UrR9Y for ; Tue, 24 Nov 2009 15:29:10 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3A0593A67C1 for ; Tue, 24 Nov 2009 15:29:10 -0800 (PST) Received: from [75.212.132.192] (192.sub-75-212-132.myvzw.com [75.212.132.192]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAONSKaP020330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2009 15:28:23 -0800 (PST) Message-ID: <4B0C6C13.2060103@isi.edu> Date: Tue, 24 Nov 2009 15:28:19 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:29:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laganier, Julien wrote: > Joe Touch wrote: >> Laganier, Julien wrote: >>> Hi, Joe, >>>> Laganier, Julien wrote: >>>>> Stuart Cheshire had a nice talk at IETF 72 on the drawbacks of the >>>>> current getaddrinfo() + connect() model w.r.t. to IPv6 transition, >>>>> see http://www.stuartcheshire.org/IETF72/. (Somebody already mentioned >>>>> that on the list I think.) >>>>> >>>>> A connect_to_name() calls that hides all of the address family >>>>> subtleties under the hood >>>>> does not have such drawbacks. So if we're going to change the API >>>>> anyway, this looks like a good occasion to fix that issue too, no? >>>> I like this idea, but there needs to be a returned primary IP >>>> address if this is intended to support TCP. I.e., you can ask the system >>>> to call a name, but it ends up establishing a TCP connection to a socket >>>> pair (src IP, dst IP, src port, dst port). >>>> >>>> I'm still not sure what that means for multipath. There could be >>>> secondary socket pairs of course, and they can vary over the life of >>>> the connection, but I still feel that if the primary disappears the >>>> connection MUST disappear *IF* this is TCP. >>>> >>>> Of course, if it's not TCP, this could be easily defined in other >>>> more useful ways. >>> Without taking position with respect to fate-sharing between the >>> MPTCP connection and the original address-port pair, whether the MPTCP >>> connection is torn down when the original address-port pair fails is, >>> I think, an issue orthogonal to the specifics of how an application >>> connects to a peer. >>> >>> In both case we can introduce the connect_to_name() call in the new >>> API. >>> >>> Orthogonal to that, if we decide we want to treat the initial address >>> pair() that got used to establish the MPTCP connection in a special >>> fashion, e.g., fate-sharing, we can still do so by defining the >>> behavior in the protocol specification. >>> >>> Makes sense? >> Sure, but either way you need to return at least the primary IP >> address/port pair as results of the connect_to_name() call. >> >> It's not sufficient to return an undistinguished set of such pairs, nor >> is it sufficient to not return any such pairs. > > Unless the socket has been bind()'ed earlier, connect() doesn't > return > to the caller any information about the address/port that was picked as > a result of the connect(). The application would need to call > getsockname() to know what address/port pair was used. Sure. I was speaking in a general sense. > If an application is modified to use the new API, it will have to use > getpeername() in addition to getsockname() to know what initial address > pair has been connected. That basically kills legacy apps. You want getsockname to return the initial, and some other call to return the full list (or supplemental socket pairs). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksMbBMACgkQE5f5cImnZrsVswCgoFpCKQa8jx5gpDG2Re01s6ic elcAoLDKy6KCjJDGgcxKL95tjlmuAKz3 =hbq9 -----END PGP SIGNATURE----- From julienl@qualcomm.com Tue Nov 24 15:34:58 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F6C3A6993 for ; Tue, 24 Nov 2009 15:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.612 X-Spam-Level: X-Spam-Status: No, score=-105.612 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH0YyhJPLU3w for ; Tue, 24 Nov 2009 15:34:57 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 34D953A67C1 for ; Tue, 24 Nov 2009 15:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259105693; x=1290641693; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Joe=20Touch=20|CC:=20=3D?iso-8859-1 ?Q?Michael_T=3DFCxen?=3D=20,=0D=0A=20=20=20=20=20=20=20=20William=20Herrin=20,=0D=0A=20=20=20=20=20=20=20=20"multipathtcp @ietf.org"=0D=0A=09|Date:=20Tue, =2024=20Nov=202009=2015:34:45=20-0800|Subject:=20RE:=20[m ultipathtcp]=20Multipath=20Address=20Family|Thread-Topic: =20[multipathtcp]=20Multipath=20Address=20Family |Thread-Index:=20AcptXe5jV9C2R3qlSbu1WcTX1kajTgAABkVw |Message-ID:=20|References:=20=0D=0A=09<3c3e3fca091109 0542h54e45784qbdbf1f338a4c3e90@mail.gmail.com>=0D=0A=09=0D=0A=09<2009 1123.092214.140617438.nishida@sfc.wide.ad.jp>=0D=0A=09<48 DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi>=0D=0A=09<3c3e3 fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com>=0D =0A=09=0D=0A=20=0D=0A=20<4B0C607A.6060503@i si.edu>=0D=0A=20=0D=0A=20<4B0C6590.9010000 @isi.edu>=0D=0A=20=0D=0A=20<4B0C6C13.20601 03@isi.edu>|In-Reply-To:=20<4B0C6C13.2060103@isi.edu> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5812"=3B=20a=3D"28363321"; bh=68jlNhXANL3k05Q5KbB4qNt0/5aoqXGuiJWkKv9DtYo=; b=iQCn/mwathK7NT/+XPu2nvSJyW7AZEH/zRdA4e3s8d8cxhxG/osy+rKg pG6GNLcMh9owdM9ZLo9MAlEvorOv9dl+FVgANGVEkLSLMDNKcblhi85Bs 12wqnKU3utOOylT7bjKPueEvyCGgQ7YNkk4LCb4OJk+zXTxlubdrD3ixd Q=; X-IronPort-AV: E=McAfee;i="5400,1158,5812"; a="28363321" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 24 Nov 2009 15:34:52 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAONYqFO006750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2009 15:34:52 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAONYlBR017328 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Nov 2009 15:34:52 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 Nov 2009 15:34:48 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Tue, 24 Nov 2009 15:34:48 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 24 Nov 2009 15:34:47 -0800 From: "Laganier, Julien" To: Joe Touch Date: Tue, 24 Nov 2009 15:34:45 -0800 Thread-Topic: [multipathtcp] Multipath Address Family Thread-Index: AcptXe5jV9C2R3qlSbu1WcTX1kajTgAABkVw Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> In-Reply-To: <4B0C6C13.2060103@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:34:58 -0000 Joe Touch wrote: > Laganier, Julien wrote: > > Joe Touch wrote: > >> [...] > >> Sure, but either way you need to return at least the primary IP > >> address/port pair as results of the connect_to_name() call. > >> > >> It's not sufficient to return an undistinguished set of such pairs, > >> nor is it sufficient to not return any such pairs. > > > > Unless the socket has been bind()'ed earlier, connect() doesn't > > return to the caller any information about the address/port that > > was picked as a result of the connect(). The application would need > > to call getsockname() to know what address/port pair was used. >=20 > Sure. I was speaking in a general sense. >=20 > > If an application is modified to use the new API, it will have to use > > getpeername() in addition to getsockname() to know what initial > > address pair has been connected. >=20 > That basically kills legacy apps. You want getsockname to return the > initial, and some other call to return the full list (or supplemental > socket pairs). Hmm... Not sure I understand your statement about legacy apps.=20 We've been talking about an app using a new connect_to_name() API call, so = it's no longer entirely legacy -- If it wants to use the new connect_to_nam= e() API call, it has to use getpeername() to get its peer address, that's i= t.=20 I do not see how that is related to legacy apps, nor while it would be kill= ing them :) --julien From pasi.sarolahti@iki.fi Tue Nov 24 15:38:02 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB3A3A67AF for ; Tue, 24 Nov 2009 15:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNFAfyJAVwZO for ; Tue, 24 Nov 2009 15:38:01 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 984AC3A672E for ; Tue, 24 Nov 2009 15:38:01 -0800 (PST) Received: from wifi172.ICSI.Berkeley.EDU (wifi172.ICSI.Berkeley.EDU [192.150.187.172]) by argo.otaverkko.fi (Postfix) with ESMTP id D15CE25ED06; Wed, 25 Nov 2009 01:37:55 +0200 (EET) Message-Id: <6C8C1D51-70E5-4545-8661-196A94CDEA37@iki.fi> From: Pasi Sarolahti To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <4B0BB35E.207@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Nov 2009 15:37:53 -0800 References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <4B0BB35E.207@uclouvain.be> X-Mailer: Apple Mail (2.936) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:38:02 -0000 On Nov 24, 2009, at 2:20 AM, Olivier Bonaventure wrote: > This could be interesting, but if we change de socket API, why don't > we > define a new structure that can handle DNS names in addition to IPv4 > and > IPv6 addresses. This would allow some applications to simply call > connect with a DNS name and let the transport protocol figure out > whether single path IPv4, single path IPv6, multipath whatever ... > should be used to reach this DNS name. I agree that connecting by names would eventually be the right way to go for Internet protocols, but am not sure if that fits within the authority of this WG anymore. It may be something that needs to be discussed by a wider community. My proposal was less ambitious and more short-sighted: fix the shortcoming in the API that claims the socket is using only one address when it is in fact using many. Another question is that even if we had an connect-by-name API, would we still need to be able express which address(es) are bound to the socket in the API? - Pasi From touch@ISI.EDU Tue Nov 24 15:44:26 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1453A67E5 for ; Tue, 24 Nov 2009 15:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XL0Ie1Nm+of for ; Tue, 24 Nov 2009 15:44:25 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D0E063A67C1 for ; Tue, 24 Nov 2009 15:44:25 -0800 (PST) Received: from [75.212.132.192] (192.sub-75-212-132.myvzw.com [75.212.132.192]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAONhxj9024540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2009 15:44:02 -0800 (PST) Message-ID: <4B0C6FBE.40003@isi.edu> Date: Tue, 24 Nov 2009 15:43:58 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:44:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laganier, Julien wrote: > Joe Touch wrote: >> Laganier, Julien wrote: >>> Joe Touch wrote: >>>> [...] >>>> Sure, but either way you need to return at least the primary IP >>>> address/port pair as results of the connect_to_name() call. >>>> >>>> It's not sufficient to return an undistinguished set of such pairs, >>>> nor is it sufficient to not return any such pairs. >>> Unless the socket has been bind()'ed earlier, connect() doesn't >>> return to the caller any information about the address/port that >>> was picked as a result of the connect(). The application would need >>> to call getsockname() to know what address/port pair was used. >> Sure. I was speaking in a general sense. >> >>> If an application is modified to use the new API, it will have to use >>> getpeername() in addition to getsockname() to know what initial >>> address pair has been connected. >> That basically kills legacy apps. You want getsockname to return the >> initial, and some other call to return the full list (or supplemental >> socket pairs). > > Hmm... Not sure I understand your statement about legacy apps. > > We've been talking about an app using a new connect_to_name() API call, so it's no longer entirely legacy -- If it wants to use the new connect_to_name() API call, it has to use getpeername() to get its peer address, that's it. > > I do not see how that is related to legacy apps, nor while it would be killing them :) Agreed. But I can port a legacy app easier if these interfaces augment, but don't change, the semantics. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksMb74ACgkQE5f5cImnZrtaTQCgtYi1XsM/MqwjuZ3pvLADCDGo 3CkAoNvREr371TwMJ3FEceoiW8cKYJCA =Tnab -----END PGP SIGNATURE----- From nishida@sfc.wide.ad.jp Tue Nov 24 16:05:29 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40E83A6848 for ; Tue, 24 Nov 2009 16:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.337 X-Spam-Level: * X-Spam-Status: No, score=1.337 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqKg3Gw1cwU0 for ; Tue, 24 Nov 2009 16:05:28 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 941093A67C1 for ; Tue, 24 Nov 2009 16:05:28 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6D4FF4C0D0; Wed, 25 Nov 2009 09:05:19 +0900 (JST) Date: Wed, 25 Nov 2009 09:05:19 +0900 (JST) Message-Id: <20091125.090519.241397361.nishida@sfc.wide.ad.jp> To: pasi.sarolahti@iki.fi From: Yoshifumi Nishida In-Reply-To: <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> References: <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:05:29 -0000 Hello Pasi, Thanks for your response. From: Pasi Sarolahti Subject: Multipath Address Family Date: Mon, 23 Nov 2009 13:40:02 -0800 Message-ID: <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> > > But I have several questions. I think there might be an alternative: > > having > > SOCK_MULTISTREAM or using a combination socket type like SOCK_STREAM | > > SOCK_MULTIPATH > > from the following reasons. > > I have thought the 'type' parameter in the socket call to specify the > semantics of the socket functions such as read and write. To my > understanding the purpose of the MPTCP exercise is to maintain similar > read/write semantics to TCP, so if successful in this goal, the socket > behavior should be equal to SOCK_STREAM. Or to put it differently, > MPTCP is not a new protocol, it is just a (fairly large) modification > to TCP. I would say that the socket type indicates the semantics of communication. (as 'man socket' says.) If communication style has been changed, we might need new one. If the transport service is completely the same from the API's point of view even if multipath is used or not, I think you're right. But, if you want to add extentions to streaming service, it can be a different communication semantic. > > SCTP socket can be created with AF_INET or AF_INET6, but the socket > > can > > support multiple addresses. It's a bit orthgonal behavior from > > AF_MULTIPATH > > Yes, earlier protocols have done something different for their > API. But I'd be interested to learn if there is something why the > earlier protocols couldn't begin using something like multipath > address family. Yep, if SCTP supports this kind of AF, things might be easier.. Actually, in WIDE project, we tried to propose new AF called AF_BUNDLE for sctp, which has very similar concept of AF_MULTIPATH. An experimental code existed, but somehow it was not integrated into KAME's code... Anyway, we already have a standardized multipath stream protocol. it would not be very perferable if the API for two multipath stream protocols are very different. I'm not sure how this is important yet, but that's one point I care. > > we might support one-ended approach with the same API. > Yep, and that should be possible with AF_MULTIPATH, by having just one > address in the address list. I think there might be cases where even > single-homed TCP connections might benefit from multiaddress API, even > if they ended up using just one of the given addresses at both ends Yes. it's possible. but, I'm not very sure if it's intuitive... > > Also, in my feeling, we will need new bind(), connect() to specify > > multiple > > addresses. just like sctp_bindx(), sctp_connectx(). > > I think that adding completely new operations to the good old socket > API might be problematic, and would lead to a more updating / > maintenance burden in different systems and applications than a new > address family would do. But I might be missing something in the > required complexity of adding a new address family. Hmm, in your proposal, it seems to me that you want to update the return value for bind() and connect(), which might break the syntax of these calls. If we want to keep the same syntax as the current one, we will need to have a new function that will get true return code for these functions. But, in my feeling, this might be almost the same as creating new bind() and connect(). Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From julienl@qualcomm.com Tue Nov 24 16:13:20 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E965D3A680E for ; Tue, 24 Nov 2009 16:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.662 X-Spam-Level: X-Spam-Status: No, score=-105.662 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF04JJj+BOjs for ; Tue, 24 Nov 2009 16:13:17 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 410143A672E for ; Tue, 24 Nov 2009 16:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259107993; x=1290643993; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Joe=20Touch=20|CC:=20=3D?iso-8859-1 ?Q?Michael_T=3DFCxen?=3D=20,=0D=0A=20=20=20=20=20=20=20=20William=20Herrin=20,=0D=0A=20=20=20=20=20=20=20=20"multipathtcp @ietf.org"=0D=0A=09|Date:=20Tue, =2024=20Nov=202009=2016:13:03=20-0800|Subject:=20RE:=20[m ultipathtcp]=20Multipath=20Address=20Family|Thread-Topic: =20[multipathtcp]=20Multipath=20Address=20Family |Thread-Index:=20AcptYA7hswK/ZlYASkKibVPpNceRhAAA7OTA |Message-ID:=20|References:=20=0D=0A=09<3c3e3fca091109 0542h54e45784qbdbf1f338a4c3e90@mail.gmail.com>=0D=0A=09=0D=0A=09<2009 1123.092214.140617438.nishida@sfc.wide.ad.jp>=0D=0A=09<48 DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi>=0D=0A=09<3c3e3 fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com>=0D =0A=09=0D=0A=20=0D=0A=20<4B0C607A.6060503@i si.edu>=0D=0A=20=0D=0A=20<4B0C6590.9010000 @isi.edu>=0D=0A=20=0D=0A=20<4B0C6C13.20601 03@isi.edu>=0D=0A=20=0D=0A=20<4B0C6FBE.400 03@isi.edu>|In-Reply-To:=20<4B0C6FBE.40003@isi.edu> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5812"=3B=20a=3D"28365887"; bh=/Owur5z77kWgBUchjLuvOGrmTHXSjMZIoih0BNzuyIE=; b=j4YTZUjGzhiM97Vcl4qIxkdVwkTI/25YHp8YuKfYoWuRjeEfID7Zt3G4 Ek59B56Zl03sTKo/+FEO+3XyHIpLqORsR3YcFAAsShXKrVI8T9/5YV2FV i1aL2lMoyBJvbPm6ua7OtQzpIvsjFvFpLz3mgcY55DRBgJJ97PKCQZtbc c=; X-IronPort-AV: E=McAfee;i="5400,1158,5812"; a="28365887" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 24 Nov 2009 16:13:12 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAP0DCX9010884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2009 16:13:12 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAP0D4pE004745 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Nov 2009 16:13:12 -0800 (PST) Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 Nov 2009 16:13:04 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Tue, 24 Nov 2009 16:13:04 -0800 From: "Laganier, Julien" To: Joe Touch Date: Tue, 24 Nov 2009 16:13:03 -0800 Thread-Topic: [multipathtcp] Multipath Address Family Thread-Index: AcptYA7hswK/ZlYASkKibVPpNceRhAAA7OTA Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> In-Reply-To: <4B0C6FBE.40003@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:13:22 -0000 Joe Touch wrote:=20 > Laganier, Julien wrote: > > Joe Touch wrote: > >> Laganier, Julien wrote: > >>> Joe Touch wrote: > >>>> [...] > >>>> Sure, but either way you need to return at least the primary IP > >>>> address/port pair as results of the connect_to_name() call. > >>>> > >>>> It's not sufficient to return an undistinguished set of such pairs, > >>>> nor is it sufficient to not return any such pairs. > >>> Unless the socket has been bind()'ed earlier, connect() doesn't > >>> return to the caller any information about the address/port that > >>> was picked as a result of the connect(). The application would need > >>> to call getsockname() to know what address/port pair was used. > >> Sure. I was speaking in a general sense. > >> > >>> If an application is modified to use the new API, it will have to > >>> use getpeername() in addition to getsockname() to know what initial > >>> address pair has been connected. > >> > >> That basically kills legacy apps. You want getsockname to return the > >> initial, and some other call to return the full list (or > >> supplemental socket pairs). > > > > Hmm... Not sure I understand your statement about legacy apps. > > > > We've been talking about an app using a new connect_to_name() API > > call, so it's no longer entirely legacy -- If it wants to use the new > > connect_to_name() API call, it has to use getpeername() to get its peer > > address, that's it. > > > > I do not see how that is related to legacy apps, nor while it would > > be killing them :) >=20 > Agreed. But I can port a legacy app easier if these interfaces augment, > but don't change, the semantics. As I said earlier, the fate sharing semantics between the original address/= port pair and the connection is IMHO a protocol matter. Whatever decision w= e take there, we can implement it in the existing and new APIs. --julien From nishida@sfc.wide.ad.jp Tue Nov 24 16:14:22 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93403A67C1 for ; Tue, 24 Nov 2009 16:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxRKB5HKCkC1 for ; Tue, 24 Nov 2009 16:14:22 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id F25F43A680E for ; Tue, 24 Nov 2009 16:14:21 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 68BD04C0D8; Wed, 25 Nov 2009 09:14:14 +0900 (JST) Date: Wed, 25 Nov 2009 09:14:14 +0900 (JST) Message-Id: <20091125.091414.57515028.nishida@sfc.wide.ad.jp> To: Michael.Tuexen@lurchi.franken.de From: Yoshifumi Nishida In-Reply-To: References: <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:14:22 -0000 From: Michael T=FCxen Subject: Re: [multipathtcp] Multipath Address Family Date: Tue, 24 Nov 2009 22:07:36 +0100 Message-ID: > just one note: > In SCTP we use sctp_connectx() to connect to multiple addresses. > Kacheong pointed a couple of years ago out that a more generic > connectx() would make sense to other protocols supporting multihomin= g > as well (but there were no). Just curiosity, do you know the reason why generic connectx() doesn't e= xist? = it make sense to me since the call looks independent from sctp. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From pasi.sarolahti@iki.fi Tue Nov 24 17:52:16 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A973A691B for ; Tue, 24 Nov 2009 17:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR-RuLgl-Lsa for ; Tue, 24 Nov 2009 17:52:15 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 5F53E3A6897 for ; Tue, 24 Nov 2009 17:52:15 -0800 (PST) Received: from wifi172.ICSI.Berkeley.EDU (wifi172.ICSI.Berkeley.EDU [192.150.187.172]) by argo.otaverkko.fi (Postfix) with ESMTP id 6DCDD25ED06; Wed, 25 Nov 2009 03:52:09 +0200 (EET) Message-Id: <809D0BC9-83EC-4E42-85DC-BCAB2905F403@iki.fi> From: Pasi Sarolahti To: William Herrin In-Reply-To: <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Nov 2009 17:52:06 -0800 References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 01:52:16 -0000 On Nov 24, 2009, at 4:34 AM, William Herrin wrote: > It seems like you want to preserve the connect() call's parameters by > altering the definition of sockaddr so that it can contain multiple > addresses. > > But functionally, what we really want to do is pass an array of > sockaddrs to connect(). > > Stupid question time: what makes redefining sockaddr superior to an > extended API call that supplants connect() and accepts an array of > sockaddrs? Another question: is it better to have a compile-time error (or segmentation fault) or run-time error code, if application was built with multi-address support, but system was not? Even if we had a new mptcp_connectx, bindx, etc. calls, the problem still remains what to do with the old socket operations that assume only single address per endpoint. A new address family would be one (unfortunately non-backwards compatible) way to address that problem (possibly with the cost of introducing new problems). I think there is a certain elegancy in having a minimal socket API with just a small basic set of operations. Until now the same socket API has provided to be flexible enough to support many uses over time (Unix domain sockets that take pathname as sockaddr, IPsec PF_KEY sockets, netlink sockets, ...). I'm not yet ready to buy it that we have come to a point that the old API is not sufficient anymore, if the same functionality could be implemented by specifying a couple of new socket parameters for a feature that is supported by just some of the protocols under the API. > Poking around linux's include files (netinet/in.h, bits/socket.h) I > notice that they go to a lot of trouble to make all sockaddrs come out > to exactly the same number of bytes. Won't a variable length sockaddr > that holds a variable number of addresses make a mess of that? I guess the question is whether the length of sockaddr is a Linux implementation issue that can be fixed, or whether there is some deeper reason for having the sockaddrs to be of same length. In Unix domain sockets the pathnames in sockaddr can be variable length and quite long, to my understanding, certainly worth of several IP addresses. But it would be interesting to know what, if anything, would break in legacy systems with a new sockaddr variant. I'm assuming that the TCP stack needs to go through fairly significant change anyway because of MPTCP. > Found a quote I think bears on the topic at > http://lkml.indiana.edu/hypermail/linux/net/9904.2/0091.html : > >> The AF_ prefix stands for "address family" and the PF_prefix stands >> for >> "protocol family". Historicly, the intent was that a single >> protocol family >> might support multiple address families and that the PF_ value was >> used to >> create the socket and the AF_ value was used in socket address >> structures. >> But in actuality, a protocol family supporting multiple address >> families has >> never been supported and the header defines the PF_ >> value >> for a given protocol to be equal to the AF_ value for that protocol. > > I think when we discuss allowing multipath TCP to use IPv4 and IPv6 > addresses interchangeably, we're talking about one protocol family > using multiple address families, are we not? I have been curious about this PF/AF dependence that seems like a long- standing "bug" in some systems. Have you ever investigated this deeper? Why would it be so hard to fix it so that you could have several address families in one protocol family? - Pasi From ayourtch@cisco.com Tue Nov 24 18:16:28 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269E83A697F for ; Tue, 24 Nov 2009 18:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRhUJDgEgNtB for ; Tue, 24 Nov 2009 18:16:27 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id E96BC3A68BC for ; Tue, 24 Nov 2009 18:16:26 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAP2CZ26023118; Wed, 25 Nov 2009 03:12:35 +0100 (CET) Received: from dhcp-bru-peg2-vl25-144-254-8-244.cisco.com (dhcp-bru-peg2-vl25-144-254-8-244.cisco.com [144.254.8.244]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAP2CZix007363; Wed, 25 Nov 2009 03:12:35 +0100 (CET) Date: Wed, 25 Nov 2009 03:12:35 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx.stdio.be To: Joe Touch In-Reply-To: <4B0C6FBE.40003@isi.edu> Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 02:16:28 -0000 On Tue, 24 Nov 2009, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Laganier, Julien wrote: >> Joe Touch wrote: >>> Laganier, Julien wrote: >>>> Joe Touch wrote: >>>>> [...] >>>>> Sure, but either way you need to return at least the primary IP >>>>> address/port pair as results of the connect_to_name() call. >>>>> >>>>> It's not sufficient to return an undistinguished set of such pairs, >>>>> nor is it sufficient to not return any such pairs. >>>> Unless the socket has been bind()'ed earlier, connect() doesn't >>>> return to the caller any information about the address/port that >>>> was picked as a result of the connect(). The application would need >>>> to call getsockname() to know what address/port pair was used. >>> Sure. I was speaking in a general sense. >>> >>>> If an application is modified to use the new API, it will have to use >>>> getpeername() in addition to getsockname() to know what initial >>>> address pair has been connected. >>> That basically kills legacy apps. You want getsockname to return the >>> initial, and some other call to return the full list (or supplemental >>> socket pairs). >> >> Hmm... Not sure I understand your statement about legacy apps. >> >> We've been talking about an app using a new connect_to_name() API call, so it's no longer entirely legacy -- If it wants to use the new connect_to_name() API call, it has to use getpeername() to get its peer address, that's it. >> >> I do not see how that is related to legacy apps, nor while it would be killing them :) > > Agreed. But I can port a legacy app easier if these interfaces augment, > but don't change, the semantics. FWIW (apologies to get in the middle of the conversation) - I had looked at a couple of browser apps when working on the prototype code for the "happy eyeballs" draft - my code was implementing the connect_by_name() semantics, with two threads racing in the background for IPv4 and IPv6 host lookup and connect attempts. I saw the biggest difficulty with porting the apps to use the connect_to_name() API in the work required to refactor the code that deals with the blocking resolver in a non-blocking manner (along with giving the user the visual clues of "Resolving host for hostname.example.com..."), selects in some application-specific way the sockaddr to use and passes it to the non-blocking socket code, and deals with the various recoverable error conditions (like retrying with other address). But, that said, I think with the right hooks for very specific cases where the application needs the fine-grained control over what exactly the "remote hostname" should boil down to, connect_by_name() could save quite a lot of "boilerplate coding" for the future. thanks, andrew From pasi.sarolahti@iki.fi Tue Nov 24 18:51:14 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1F928C1A8 for ; Tue, 24 Nov 2009 18:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbd6Nz3R+9T3 for ; Tue, 24 Nov 2009 18:51:13 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 7E60A28C1A3 for ; Tue, 24 Nov 2009 18:51:13 -0800 (PST) Received: from [192.168.1.66] (adsl-99-169-80-11.dsl.pltn13.sbcglobal.net [99.169.80.11]) by argo.otaverkko.fi (Postfix) with ESMTP id 294F625ED06; Wed, 25 Nov 2009 04:51:07 +0200 (EET) Message-Id: <94FFE70B-3CF6-47A7-B29D-40342135E08E@iki.fi> From: Pasi Sarolahti To: William Herrin In-Reply-To: <809D0BC9-83EC-4E42-85DC-BCAB2905F403@iki.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Nov 2009 18:51:04 -0800 References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <809D0BC9-83EC-4E42-85DC-BCAB2905F403@iki.fi> X-Mailer: Apple Mail (2.936) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 02:51:14 -0000 On Nov 24, 2009, at 5:52 PM, Pasi Sarolahti wrote: >> Stupid question time: what makes redefining sockaddr superior to an >> extended API call that supplants connect() and accepts an array of >> sockaddrs? > > Another question: is it better to have a compile-time error (or > segmentation fault) or run-time error code, if application was built > with multi-address support, but system was not? Uh.. forget what I said about compile-time errors... But I would think not changing the API would allow for more elegant error handling when multi-address apps are run on old systems that do not support the feature. - Pasi From ayourtch@cisco.com Tue Nov 24 19:35:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B935D28C1C1 for ; Tue, 24 Nov 2009 19:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utWDnhcajxrq for ; Tue, 24 Nov 2009 19:35:39 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9EE3228C177 for ; Tue, 24 Nov 2009 19:35:39 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAP3Vn1o022792; Wed, 25 Nov 2009 04:31:49 +0100 (CET) Received: from dhcp-bru-peg2-vl25-144-254-8-244.cisco.com (dhcp-bru-peg2-vl25-144-254-8-244.cisco.com [144.254.8.244]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAP3Vk37022180; Wed, 25 Nov 2009 04:31:46 +0100 (CET) Date: Wed, 25 Nov 2009 04:31:47 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx.stdio.be To: Joe Touch In-Reply-To: Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 03:35:40 -0000 On Wed, 25 Nov 2009, Andrew Yourtchenko wrote: > On Tue, 24 Nov 2009, Joe Touch wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> Laganier, Julien wrote: >>> Joe Touch wrote: >>>> Laganier, Julien wrote: >>>>> Joe Touch wrote: >>>>>> [...] >>>>>> Sure, but either way you need to return at least the primary IP >>>>>> address/port pair as results of the connect_to_name() call. >>>>>> >>>>>> It's not sufficient to return an undistinguished set of such pairs, >>>>>> nor is it sufficient to not return any such pairs. >>>>> Unless the socket has been bind()'ed earlier, connect() doesn't >>>>> return to the caller any information about the address/port that >>>>> was picked as a result of the connect(). The application would need >>>>> to call getsockname() to know what address/port pair was used. >>>> Sure. I was speaking in a general sense. >>>> >>>>> If an application is modified to use the new API, it will have to use >>>>> getpeername() in addition to getsockname() to know what initial >>>>> address pair has been connected. >>>> That basically kills legacy apps. You want getsockname to return the >>>> initial, and some other call to return the full list (or supplemental >>>> socket pairs). >>> >>> Hmm... Not sure I understand your statement about legacy apps. >>> >>> We've been talking about an app using a new connect_to_name() API call, so >>> it's no longer entirely legacy -- If it wants to use the new >>> connect_to_name() API call, it has to use getpeername() to get its peer >>> address, that's it. >>> >>> I do not see how that is related to legacy apps, nor while it would be >>> killing them :) >> >> Agreed. But I can port a legacy app easier if these interfaces augment, >> but don't change, the semantics. > > FWIW (apologies to get in the middle of the conversation) - I had looked at a > couple of browser apps when working on the prototype code for the "happy > eyeballs" draft - my code was implementing the connect_by_name() semantics, > with two threads racing in the background for IPv4 and IPv6 host lookup and > connect attempts. And to correct/clarify myself: I was working with the connect_by_name(hostname,servicename) - similar to getaddrinfo() > I saw the biggest difficulty with porting the apps to use the > connect_to_name() API in the work required to refactor the code that deals > with the blocking resolver in a non-blocking manner (along with giving the > user the visual clues of "Resolving host for hostname.example.com..."), > selects in some application-specific way the sockaddr to use and passes it to > the non-blocking socket code, and deals with the various recoverable error > conditions (like retrying with other address). > > But, that said, I think with the right hooks for very specific cases where > the application needs the fine-grained control over what exactly the "remote > hostname" should boil down to, connect_by_name() could save quite a lot of > "boilerplate coding" for the future. thanks, andrew From c.raiciu@cs.ucl.ac.uk Wed Nov 25 02:39:09 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683653A69BF for ; Wed, 25 Nov 2009 02:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jujU0JVTigy3 for ; Wed, 25 Nov 2009 02:39:08 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 605FD3A6811 for ; Wed, 25 Nov 2009 02:39:07 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1NDFAJ-000Fvk-BJ for multipathtcp@ietf.org; Wed, 25 Nov 2009 10:32:03 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Costin Raiciu In-Reply-To: Date: Wed, 25 Nov 2009 10:39:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> To: "multipathtcp@ietf.org List" X-Mailer: Apple Mail (2.1077) Subject: [multipathtcp] Multipath deployment and fate sharing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 10:39:09 -0000 Hi, I have been thinking about this for a bit now, and have chatted with = various people from different OSes.=20 Murari (from Microsoft) said that they will probably not turn multipath = on by default at first release; apps wll be able to use it, but will = need to opt in. This will give app writers a chance to update their apps = for multipath - since the apps that break are likely a small subset, it = seems it will be possible to upgrade these given the time window between = OS releases. I would guess most other OSes would do the same in the = initial release. So, by default, client hosts will not have multipath = "on". Let's consider mobiles. This is where multipath is badly needed for = supporting connection handover between interfaces. Here most of the apps = typically run as high level managed code - mostly for security reasons; = I bet one can change the stack without breaking these apps even if = multipath is on by default. The low level apps that would break are = already written mostly by the company running the OS - hence will be = natural to upgrade.=20 In short, I think multipath could be turned on by default for mobiles, = if the mobile providers want this. Finally, servers: Linux currently has ecn turned on by default for = servers, and off on clients. I would assume the same could hold for = multipath. This would ensure that initially mobiles can talk multipath = to servers, but standard client-server communication is unipath.=20 This deployment model seems natural to me, as it gives the much needed = benefits to mobiles immediately, and allows the more mature desktop = market to slowly sink in multipath. Coming back to fate sharing of multipath connection and initial subflow: = I would assume fate sharing will be a sysctl flag on the host, telling = the stack whether the connection should go down or not with the first = subflow. I imagine three settings here: a) connection doesn't go down with first subflow b) connection dies when local interface dies c) connection dies when subflow times out (this implies b) As long as the protocol itself does not make assumptions about fate = sharing, the endpoints can do whatever local policy says. I would = imagine mobiles will do policy a), servers can probably do policy b), = and clients c) - assuming it is hardest to tell what apps break on = client hosts (the apps that use TCP to test path properties will break = so they would like c). I think the combination of these two choices (multipath on/off + fate = sharing policy) allows everyone to get what they want, when they want. Thoughts? Costin= From touch@ISI.EDU Wed Nov 25 07:54:34 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3DFA28C235 for ; Wed, 25 Nov 2009 07:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueT0p2AOL91j for ; Wed, 25 Nov 2009 07:54:34 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id EF60728C1F4 for ; Wed, 25 Nov 2009 07:54:33 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nAPFqrUk004542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2009 07:52:54 -0800 (PST) Message-ID: <4B0D52D5.9090403@isi.edu> Date: Wed, 25 Nov 2009 07:52:53 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Costin Raiciu References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nAPFqrUk004542 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org List" Subject: Re: [multipathtcp] Multipath deployment and fate sharing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:54:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Costin Raiciu wrote: ... > Coming back to fate sharing of multipath connection and initial > subflow: I would assume fate sharing will be a sysctl flag on the host, > telling the stack whether the connection should go down or not with the > first subflow. I imagine three settings here: > > a) connection doesn't go down with first subflow > b) connection dies when local interface dies > c) connection dies when subflow times out (this implies b) These are interesting configuration parameters from an implementation view, but from a protocol view, if we're talking about TCP, there are only two cases: a) connection goes down when the whole set of subflows goes down b) connection goes down when the first subflow goes down What makes a subflow go down shouldn't be defined separately; it's exactly whatever would make that connection go down if it were a single, stand-alone TCP connection. The remaining question will be whether (a) is still TCP, or more specifically how to make (b) look more like (a). One way is to say "first subflow packets are tunneled over other subflows". If that is actually how things are done, then you can claim that the original subflow is actually still up, and make progress. However, anything that would cause the original subflow to fail even when tunneled over other interfaces still, IMO, needs to cause the whole set to go down. The key example is loss of the IP address associated with the original flow - either when the interface goes down, or when it's lost via failed DHCP renewals, or when it's otherwise explicitly reconfigured. Provided this latter case is defined clearly enough, this might be a way to proceed. However, if you start a connection with an address you're given by an ISP, you can't continue that after the address is revoked. If you do, you could interfere with other connections from other hosts to which that address is (re)assigned. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksNUtUACgkQE5f5cImnZrtUmACgqpgS4b3rQcKNxJDujaFtA8dk /GQAnAqzdrCrydyRFz40fiNb6DKx4hoa =Ybic -----END PGP SIGNATURE----- From julienl@qualcomm.com Wed Nov 25 08:31:49 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69BF43A6A13 for ; Wed, 25 Nov 2009 08:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.706 X-Spam-Level: X-Spam-Status: No, score=-103.706 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIIK4WD1ihkr for ; Wed, 25 Nov 2009 08:31:48 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 1E6E63A6AA3 for ; Wed, 25 Nov 2009 08:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259166703; x=1290702703; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Pasi=20Sarolahti=20,=20Will iam=20Herrin=20|CC:=20"multipathtcp@ietf. org"=20|Date:=20Wed,=2025=20Nov=20 2009=2008:31:26=20-0800|Subject:=20RE:=20[multipathtcp] =20Multipath=20Address=20Family|Thread-Topic:=20[multipat htcp]=20Multipath=20Address=20Family|Thread-Index:=20Acpt cfP9piGcxwa8SYGEiKKif1liCgAAu33A|Message-ID:=20|References:=20=0D=0A=09<3c3e3fca0911090542h54e45784qbdbf1f338a4 c3e90@mail.gmail.com>=0D=0A=09=0D=0A=09<20091123.092214.140617438.nis hida@sfc.wide.ad.jp>=0D=0A=09<48DA092B-F3BC-432E-A199-B26 5DDED39DA@iki.fi>=0D=0A=09<3c3e3fca0911240434p4d95ec7an34 615ae218faa4f@mail.gmail.com>=0D=0A=20<809D0BC9-83EC-4E42 -85DC-BCAB2905F403@iki.fi>|In-Reply-To:=20<809D0BC9-83EC- 4E42-85DC-BCAB2905F403@iki.fi>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5813"=3B=20a=3D"28417791"; bh=23R5Z2VmcxE0itIPxV+IZO8rjcePMo9CUeUPTuyo5eY=; b=vfyiF65XF3x95RqG7JpitJ0kvoeg+tqw8pIetg5exLJIuo7JnfBzsvWc cmY5OCqf+q1OvjpErYzlkxpmElkgwouQd+PfViepq8cyiWOgG/NlyRfJr URx7ukoOVasS83t9FioJJQVK1l679+uaT7oHnuf4FktHJaSH4x68RC7jJ E=; X-IronPort-AV: E=McAfee;i="5400,1158,5813"; a="28417791" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 25 Nov 2009 08:31:34 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAPGVXeZ023683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2009 08:31:34 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAPGVTVl005112 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Nov 2009 08:31:29 -0800 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 Nov 2009 08:31:28 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Wed, 25 Nov 2009 08:31:28 -0800 From: "Laganier, Julien" To: Pasi Sarolahti , William Herrin Date: Wed, 25 Nov 2009 08:31:26 -0800 Thread-Topic: [multipathtcp] Multipath Address Family Thread-Index: AcptcfP9piGcxwa8SYGEiKKif1liCgAAu33A Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <809D0BC9-83EC-4E42-85DC-BCAB2905F403@iki.fi> In-Reply-To: <809D0BC9-83EC-4E42-85DC-BCAB2905F403@iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:31:49 -0000 Pasi Sarolahti wrote: >=20 > On Nov 24, 2009, at 4:34 AM, William Herrin wrote: >=20 > > It seems like you want to preserve the connect() call's parameters by > > altering the definition of sockaddr so that it can contain multiple > > addresses. > > > > But functionally, what we really want to do is pass an array of > > sockaddrs to connect(). > > > > Stupid question time: what makes redefining sockaddr superior to an > > extended API call that supplants connect() and accepts an array of > > sockaddrs? >=20 > Another question: is it better to have a compile-time error (or > segmentation fault) or run-time error code, if application was built > with multi-address support, but system was not? Hmm. Neither =3D) I think if we want to bind or connect an MPTCP connection to multiple addre= sses, we want to have new systems calls, in a fashion similar to what was d= one with sctp_connectx(). =20 > Even if we had a new mptcp_connectx, bindx, etc. calls, the problem > still remains what to do with the old socket operations that assume > only single address per endpoint. A new address family would be one > (unfortunately non-backwards compatible) way to address that problem > (possibly with the cost of introducing new problems). The "old" socket can have its semantic preserved by exposing through it onl= y the initial address-port pair in use.=20 - connect() will connect to one address-port - bind() will bind to one address:port - getsockname() will return the address-port to which the socket was fir= st bound - getpeername() will return the address-port from which the connection w= ith the peer was initially established.=20 =20 > I think there is a certain elegancy in having a minimal socket API > with just a small basic set of operations. Until now the same socket > API has provided to be flexible enough to support many uses over time > (Unix domain sockets that take pathname as sockaddr, IPsec PF_KEY > sockets, netlink sockets, ...). I'm not yet ready to buy it that we > have come to a point that the old API is not sufficient anymore, if > the same functionality could be implemented by specifying a couple of > new socket parameters for a feature that is supported by just some of > the protocols under the API. AFAICS all uses of the socket API so far had the property that a socket is = bound to a _single_ and _constant_ name (e.g., address, pathname), or in ot= her words, there's no more than one name, and the name doesn't change.=20 This property is no longer true with MPTCP because a socket can be bound to= multiple and changing addresses. So if we're to design an API that exposes= that, extending an API that assumed exactly the contrary is IMHO the wrong= way to go. --julien From Michael.Tuexen@lurchi.franken.de Wed Nov 25 10:21:20 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D25A3A6870 for ; Wed, 25 Nov 2009 10:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw21oUrfZZAp for ; Wed, 25 Nov 2009 10:21:20 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 8147D3A67B1 for ; Wed, 25 Nov 2009 10:21:19 -0800 (PST) Received: from [192.168.20.2] (tmo-099-214.customers.d1-online.com [80.187.99.214]) by mail-n.franken.de (Postfix) with ESMTP id 1C8371C0B461B; Wed, 25 Nov 2009 19:21:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20091125.091414.57515028.nishida@sfc.wide.ad.jp> Date: Wed, 25 Nov 2009 19:20:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <20091125.091414.57515028.nishida@sfc.wide.ad.jp> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1077) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:21:20 -0000 On Nov 25, 2009, at 1:14 AM, Yoshifumi Nishida wrote: >=20 > From: Michael T=FCxen > Subject: Re: [multipathtcp] Multipath Address Family > Date: Tue, 24 Nov 2009 22:07:36 +0100 > Message-ID: >=20 >> just one note: >> In SCTP we use sctp_connectx() to connect to multiple addresses. >> Kacheong pointed a couple of years ago out that a more generic >> connectx() would make sense to other protocols supporting multihoming >> as well (but there were no). >=20 > Just curiosity, do you know the reason why generic connectx() doesn't = exist?=20 > it make sense to me since the call looks independent from sctp. Because we were not sure what the right semantic would be: 1. For SCTP (or other protocols supporting multihoming), we wanted = something like "establish a transport connection with the peer having *all* = given addresses. 2. For TCP (or other protocols not supporting multihoming), we though = something like "establish a transport connection with a peer having *one* of = the given addresses. This is very different. We also assume that if the user provides = multiple address, all the addresses belong the the *same* host. This makes it impossible = to use DNS for getting them... So we choose to use sctp_connectx() if if lateron a generic connectx() = is defined, we can easily provide an SCTP semantic, if possible. Best regards Michael > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp >=20 >=20 >=20 >=20 From Michael.Tuexen@lurchi.franken.de Wed Nov 25 10:26:37 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83D33A6944 for ; Wed, 25 Nov 2009 10:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jjid6jPvEPF for ; Wed, 25 Nov 2009 10:26:36 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 077E23A6914 for ; Wed, 25 Nov 2009 10:26:36 -0800 (PST) Received: from [192.168.20.2] (tmo-099-214.customers.d1-online.com [80.187.99.214]) by mail-n.franken.de (Postfix) with ESMTP id 0C19F1C0B461B; Wed, 25 Nov 2009 19:26:19 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Wed, 25 Nov 2009 19:26:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <50B8B7D8-A0D3-4BFC-9471-F0929A19569D@lurchi.franken.de> References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> To: "Laganier, Julien" X-Mailer: Apple Mail (2.1077) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:26:37 -0000 On Nov 24, 2009, at 11:32 PM, Laganier, Julien wrote: > Stuart Cheshire had a nice talk at IETF 72 on the drawbacks of the = current getaddrinfo() + connect() model w.r.t. to IPv6 transition,see = http://www.stuartcheshire.org/IETF72/. (Somebody already mentioned that = on the list I think.) >=20 > A connect_to_name() calls that hides all of the address family = subtleties under the hood > does not have such drawbacks. So if we're going to change the API = anyway, this looks like a good occasion to fix that issue too, no? I'm interested in the userland/kernel boundary, the system calls, not = any kind of library calls. So are you suggesting to do the DNS name lookups in the kernel? This = would mean that you want to implement DLS in the kernel. I'm not sure if I really like = that... We had^H^H^H have a feature in SCTP which also requires DNS lookups = right from the kernel and no-one implemented it.=20 I think Stuart was referring to some stuff in CoreFoundation, which are = library calls, I think. Best regards Michael >=20 > --julien=20 >=20 >> -----Original Message----- >> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- >> bounces@ietf.org] On Behalf Of Michael T=FCxen >> Sent: Tuesday, November 24, 2009 1:08 PM >> To: William Herrin >> Cc: multipathtcp@ietf.org >> Subject: Re: [multipathtcp] Multipath Address Family >>=20 >> Dear all, >>=20 >> just one note: >> In SCTP we use sctp_connectx() to connect to multiple addresses. >> Kacheong pointed a couple of years ago out that a more generic >> connectx() would make sense to other protocols supporting multihoming >> as well (but there were no). >>=20 >> So you might want to look at sctp_connectx() which the SCTP socket = API >> uses to handle the problem. >>=20 >> Best regards >> Michael >>=20 >> On Nov 24, 2009, at 1:34 PM, William Herrin wrote: >>=20 >>> On Mon, Nov 23, 2009 at 4:40 PM, Pasi Sarolahti >> wrote: >>>> I think a new address family would be a minimal needed change to = the >> current >>>> socket API, without extending the API with new operations, but yet >> provide >>>> an interface to handle multiple addresses in a socket. One >> potentially >>>> useful characteristic would be that this would allow name resolver >> to return >>>> multiple IPv4 and/or IPv6 addresses from the name server as a = single >>>> sockaddr structure, that could be directly given as a parameter to = a >> connect >>>> call, which would lead to trying which of the addresses are >> reachable for >>>> the MPTCP session. >>>=20 >>> Hi Pasi, >>>=20 >>> It seems like you want to preserve the connect() call's parameters = by >>> altering the definition of sockaddr so that it can contain multiple >>> addresses. >>>=20 >>> But functionally, what we really want to do is pass an array of >>> sockaddrs to connect(). >>>=20 >>> Stupid question time: what makes redefining sockaddr superior to an >>> extended API call that supplants connect() and accepts an array of >>> sockaddrs? >>>=20 >>> Poking around linux's include files (netinet/in.h, bits/socket.h) I >>> notice that they go to a lot of trouble to make all sockaddrs come >> out >>> to exactly the same number of bytes. Won't a variable length = sockaddr >>> that holds a variable number of addresses make a mess of that? >>>=20 >>>=20 >>>>> SOCK_MULTISTREAM or using a combination socket type like >> SOCK_STREAM | >>>>> SOCK_MULTIPATH >>>>> from the following reasons. >>>=20 >>> Found a quote I think bears on the topic at >>> http://lkml.indiana.edu/hypermail/linux/net/9904.2/0091.html : >>>=20 >>>> The AF_ prefix stands for "address family" and the PF_prefix stands >> for >>>> "protocol family". Historicly, the intent was that a single = protocol >> family >>>> might support multiple address families and that the PF_ value was >> used to >>>> create the socket and the AF_ value was used in socket address >> structures. >>>> But in actuality, a protocol family supporting multiple address >> families has >>>> never been supported and the header defines the PF_ >> value >>>> for a given protocol to be equal to the AF_ value for that = protocol. >>>=20 >>> I think when we discuss allowing multipath TCP to use IPv4 and IPv6 >>> addresses interchangeably, we're talking about one protocol family >>> using multiple address families, are we not? >>>=20 >>> Regards, >>> Bill Herrin >>>=20 >>>=20 >>>=20 >>> -- >>> William D. Herrin ................ herrin@dirtside.com >> bill@herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>=20 >>=20 >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >=20 From julienl@qualcomm.com Wed Nov 25 10:38:26 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0894A3A67F4 for ; Wed, 25 Nov 2009 10:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.506 X-Spam-Level: X-Spam-Status: No, score=-105.506 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AtEdgRU06tV for ; Wed, 25 Nov 2009 10:38:24 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B04523A6359 for ; Wed, 25 Nov 2009 10:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259174300; x=1290710300; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20=3D?iso-8859-1?Q?Michael_T=3DFCxen?=3D=20|CC:=20William=20Herrin=20,=0D=0A=20=20=20=20=20=20=20=20"multipathtcp@ie tf.org"=0D=0A=09|Date:=20Wed,=2025 =20Nov=202009=2010:38:14=20-0800|Subject:=20RE:=20[multip athtcp]=20Multipath=20Address=20Family|Thread-Topic:=20[m ultipathtcp]=20Multipath=20Address=20Family|Thread-Index: =20Acpt/NcNyYzyiJ5PQT2G/jP0RcVvuwAAC/dw|Message-ID:=20|References:=20=0D=0A=20<3c3e3fca0911090542h54e45784qbdbf 1f338a4c3e90@mail.gmail.com>=0D=0A=20=0D=0A=20<20091123.092214.140617 438.nishida@sfc.wide.ad.jp>=0D=0A=20<48DA092B-F3BC-432E-A 199-B265DDED39DA@iki.fi>=0D=0A=20<3c3e3fca0911240434p4d95 ec7an34615ae218faa4f@mail.gmail.com>=0D=0A=20=0D=0A=20=0D=0A=20<50B8B7D8-A0D3-4BFC-9471-F0929A19569D @lurchi.franken.de>|In-Reply-To:=20<50B8B7D8-A0D3-4BFC-94 71-F0929A19569D@lurchi.franken.de>|Accept-Language:=20en- US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5813"=3B=20a=3D"28424351"; bh=353/hMsR9DWcU/xOHP6J/qrfDWeKBtQ5ziwm5/Yratw=; b=jjElRJ5Ryko3QDD0rgwnd/B50WlzuNNa1huT4d0jhE68uMxh148+jPMY I3AVRwBe6B+qXr6i1l9FdHeYj1xzvOWT6p7HXgJL1D1Iskd5Fnyw6ctYq Bk7NOSA6stTS7MZhdDTjKTel750LvRHhYb+duXrvMeHzk4W6rHhrTEXlq 0=; X-IronPort-AV: E=McAfee;i="5400,1158,5813"; a="28424351" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 25 Nov 2009 10:38:19 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAPIcJd5014405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2009 10:38:19 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAPIcHjU023385 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Nov 2009 10:38:19 -0800 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 Nov 2009 10:38:16 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Wed, 25 Nov 2009 10:38:16 -0800 From: "Laganier, Julien" To: =?iso-8859-1?Q?Michael_T=FCxen?= Date: Wed, 25 Nov 2009 10:38:14 -0800 Thread-Topic: [multipathtcp] Multipath Address Family Thread-Index: Acpt/NcNyYzyiJ5PQT2G/jP0RcVvuwAAC/dw Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <50B8B7D8-A0D3-4BFC-9471-F0929A19569D@lurchi.franken.de> In-Reply-To: <50B8B7D8-A0D3-4BFC-9471-F0929A19569D@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:38:26 -0000 Michael T=FCxen wrote: >=20 > On Nov 24, 2009, at 11:32 PM, Laganier, Julien wrote: >=20 > > Stuart Cheshire had a nice talk at IETF 72 on the drawbacks of the > > current getaddrinfo() + connect() model w.r.t. to IPv6 transition,see > > http://www.stuartcheshire.org/IETF72/. (Somebody already mentioned that > > on the list I think.) > > > > A connect_to_name() calls that hides all of the address family > > subtleties under the hood does not have such drawbacks. So if we're > > going to change the API anyway, this looks like a good occasion to=20 > > fix that issue too, no? > > I'm interested in the userland/kernel boundary, the system calls, not > any kind of library calls. Good for you. I'm not talking about any kind of library call, I'm talking about an API, w= hich is what I think the WG is chartered to work on.=20 > So are you suggesting to do the DNS name lookups in the kernel? This > would mean that you want to implement DLS in the kernel. I'm not sure if = I really like > that... > We had^H^H^H have a feature in SCTP which also requires DNS lookups > right from the > kernel and no-one implemented it. I'm suggesting to do DNS lookups as a result of the connect_to_name() API c= all, nothing more. --julien > I think Stuart was referring to some stuff in CoreFoundation, which are > library calls, I think. >=20 > Best regards > Michael > > > > --julien > > > >> -----Original Message----- > >> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > >> bounces@ietf.org] On Behalf Of Michael T=FCxen > >> Sent: Tuesday, November 24, 2009 1:08 PM > >> To: William Herrin > >> Cc: multipathtcp@ietf.org > >> Subject: Re: [multipathtcp] Multipath Address Family > >> > >> Dear all, > >> > >> just one note: > >> In SCTP we use sctp_connectx() to connect to multiple addresses. > >> Kacheong pointed a couple of years ago out that a more generic > >> connectx() would make sense to other protocols supporting > multihoming > >> as well (but there were no). > >> > >> So you might want to look at sctp_connectx() which the SCTP socket > API > >> uses to handle the problem. > >> > >> Best regards > >> Michael > >> > >> On Nov 24, 2009, at 1:34 PM, William Herrin wrote: > >> > >>> On Mon, Nov 23, 2009 at 4:40 PM, Pasi Sarolahti > >> wrote: > >>>> I think a new address family would be a minimal needed change to > the > >> current > >>>> socket API, without extending the API with new operations, but yet > >> provide > >>>> an interface to handle multiple addresses in a socket. One > >> potentially > >>>> useful characteristic would be that this would allow name resolver > >> to return > >>>> multiple IPv4 and/or IPv6 addresses from the name server as a > single > >>>> sockaddr structure, that could be directly given as a parameter to > a > >> connect > >>>> call, which would lead to trying which of the addresses are > >> reachable for > >>>> the MPTCP session. > >>> > >>> Hi Pasi, > >>> > >>> It seems like you want to preserve the connect() call's parameters > by > >>> altering the definition of sockaddr so that it can contain multiple > >>> addresses. > >>> > >>> But functionally, what we really want to do is pass an array of > >>> sockaddrs to connect(). > >>> > >>> Stupid question time: what makes redefining sockaddr superior to an > >>> extended API call that supplants connect() and accepts an array of > >>> sockaddrs? > >>> > >>> Poking around linux's include files (netinet/in.h, bits/socket.h) I > >>> notice that they go to a lot of trouble to make all sockaddrs come > >> out > >>> to exactly the same number of bytes. Won't a variable length > sockaddr > >>> that holds a variable number of addresses make a mess of that? > >>> > >>> > >>>>> SOCK_MULTISTREAM or using a combination socket type like > >> SOCK_STREAM | > >>>>> SOCK_MULTIPATH > >>>>> from the following reasons. > >>> > >>> Found a quote I think bears on the topic at > >>> http://lkml.indiana.edu/hypermail/linux/net/9904.2/0091.html : > >>> > >>>> The AF_ prefix stands for "address family" and the PF_prefix > stands > >> for > >>>> "protocol family". Historicly, the intent was that a single > protocol > >> family > >>>> might support multiple address families and that the PF_ value was > >> used to > >>>> create the socket and the AF_ value was used in socket address > >> structures. > >>>> But in actuality, a protocol family supporting multiple address > >> families has > >>>> never been supported and the header defines the PF_ > >> value > >>>> for a given protocol to be equal to the AF_ value for that > protocol. > >>> > >>> I think when we discuss allowing multipath TCP to use IPv4 and IPv6 > >>> addresses interchangeably, we're talking about one protocol family > >>> using multiple address families, are we not? > >>> > >>> Regards, > >>> Bill Herrin > >>> > >>> > >>> > >>> -- > >>> William D. Herrin ................ herrin@dirtside.com > >> bill@herrin.us > >>> 3005 Crane Dr. ...................... Web: > >>> Falls Church, VA 22042-3004 > >>> _______________________________________________ > >>> multipathtcp mailing list > >>> multipathtcp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/multipathtcp > >>> > >> > >> _______________________________________________ > >> multipathtcp mailing list > >> multipathtcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/multipathtcp > > From nishida@sfc.wide.ad.jp Wed Nov 25 11:15:24 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EFCE3A6B24 for ; Wed, 25 Nov 2009 11:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g8AY-Vi7KbN for ; Wed, 25 Nov 2009 11:15:23 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 647673A6B1E for ; Wed, 25 Nov 2009 11:15:23 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 345124C0DE; Thu, 26 Nov 2009 04:15:14 +0900 (JST) Date: Thu, 26 Nov 2009 04:15:14 +0900 (JST) Message-Id: <20091126.041514.183027096.nishida@sfc.wide.ad.jp> To: Michael.Tuexen@lurchi.franken.de From: Yoshifumi Nishida In-Reply-To: References: <20091125.091414.57515028.nishida@sfc.wide.ad.jp> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 19:15:24 -0000 Hello Michael, = From: Michael T=FCxen Subject: Re: [multipathtcp] Multipath Address Family Date: Wed, 25 Nov 2009 19:20:56 +0100 Message-ID: > >> just one note: > >> In SCTP we use sctp_connectx() to connect to multiple addresses. > >> Kacheong pointed a couple of years ago out that a more generic > >> connectx() would make sense to other protocols supporting multiho= ming > >> as well (but there were no). > > = > > Just curiosity, do you know the reason why generic connectx() does= n't exist? = > > it make sense to me since the call looks independent from sctp. > Because we were not sure what the right semantic would be: > 1. For SCTP (or other protocols supporting multihoming), we wanted s= omething > like "establish a transport connection with the peer having *all*= given addresses. > 2. For TCP (or other protocols not supporting multihoming), we thoug= h something > like "establish a transport connection with a peer having *one* o= f the given addresses. > This is very different. We also assume that if the user provides mul= tiple address, > all the addresses belong the the *same* host. This makes it impossib= le to use > DNS for getting them... Thanks for the clarification. But, I still have a question... Do we hav= e to connect all given addresses? If connectx() sends multiple SYNs simultaneously to the multiple destin= ations, it will be problematic. But, if connectx() has the following logic, it tries to send a SYN one-by-one to each destination it gets SYN-ACK, it stops to send a SYN and return. I don't see a big issue in the logic. It may be slow in some cases, tho= ugh. = I mean, connectx() is used only to find one primary destination. Other = destinations will be found during negotiations in the transport protocol. Not from c= onnectx(). -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From pasi.sarolahti@iki.fi Wed Nov 25 22:55:45 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1493A684F for ; Wed, 25 Nov 2009 22:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmbTzUy9mCfl for ; Wed, 25 Nov 2009 22:55:44 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 0B6EB3A677E for ; Wed, 25 Nov 2009 22:55:44 -0800 (PST) Received: from [192.168.1.66] (adsl-99-179-46-50.dsl.pltn13.sbcglobal.net [99.179.46.50]) by argo.otaverkko.fi (Postfix) with ESMTP id 2CB2D25ED06; Thu, 26 Nov 2009 08:55:36 +0200 (EET) Message-Id: From: Pasi Sarolahti To: "Laganier, Julien" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Nov 2009 22:55:34 -0800 References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <809D0BC9-83EC-4E42-85DC-BCAB2905F403@iki.fi> X-Mailer: Apple Mail (2.936) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 06:55:45 -0000 On Nov 25, 2009, at 8:31 AM, Laganier, Julien wrote: >> Even if we had a new mptcp_connectx, bindx, etc. calls, the problem >> still remains what to do with the old socket operations that assume >> only single address per endpoint. A new address family would be one >> (unfortunately non-backwards compatible) way to address that problem >> (possibly with the cost of introducing new problems). > > The "old" socket can have its semantic preserved by exposing through > it only the initial address-port pair in use. > > - connect() will connect to one address-port > - bind() will bind to one address:port > - getsockname() will return the address-port to which the socket > was first bound > - getpeername() will return the address-port from which the > connection with the peer was initially established. Ok, so the confusion is about whether get*name really refers to a stable "name" that misleadingly looks very much like an address/port, or whether it should point to a current address. Posix spec says about getpeername that "The getpeername() function shall retrieve the peer address of the specified socket", which hints towards the latter interpretation, but there may be other references (such as man pages) that spell this differently. Man page for getsockname says "Getsockname() returns the current address for the specified socket", but getpeername talks about names. If the connection was to survive over the loss of the first address, getsockname or getpeername could return an address that has not been used by that host for a while, and the returned address might as well be already allocated to a different host. This may be a problem for applications that have assumed the "current address" interpretation. I agree that there needs to be a mode that is backwards compatible with the old AF_INET sockets for legacy apps, but if new applications were implemented to be multipath-aware with new or extended API, then also these calls should return reasonable values that correspond with reality. A different question is how many applications really need to be aware of the underlying addresses -- probably a small minority (with apologies to people who are fed up with this discussion thread by now). >> I think there is a certain elegancy in having a minimal socket API >> with just a small basic set of operations. Until now the same socket >> API has provided to be flexible enough to support many uses over time >> (Unix domain sockets that take pathname as sockaddr, IPsec PF_KEY >> sockets, netlink sockets, ...). I'm not yet ready to buy it that we >> have come to a point that the old API is not sufficient anymore, if >> the same functionality could be implemented by specifying a couple of >> new socket parameters for a feature that is supported by just some of >> the protocols under the API. > > AFAICS all uses of the socket API so far had the property that a > socket is bound to a _single_ and _constant_ name (e.g., address, > pathname), or in other words, there's no more than one name, and the > name doesn't change. > > This property is no longer true with MPTCP because a socket can be > bound to multiple and changing addresses. So if we're to design an > API that exposes that, extending an API that assumed exactly the > contrary is IMHO the wrong way to go. I agree that this is different from earlier uses, but why is this a problem, if both the application and the protocol implementation have a common understanding (indicated by the address family) how the new form of sockaddress works? The socket API itself should be transparent about the structure of sockaddr, right? Connected socket has a property that it has a local and a remote endpoint, but now we have a case that an endpoint may have multiple "aliases" to represent it. - Pasi From lars.eggert@nokia.com Fri Nov 27 01:09:43 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111263A68C2 for ; Fri, 27 Nov 2009 01:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E12v8FnOGBJ7 for ; Fri, 27 Nov 2009 01:09:42 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:708:40:fff1::2]) by core3.amsl.com (Postfix) with ESMTP id 887743A677D for ; Fri, 27 Nov 2009 01:09:41 -0800 (PST) Received: from wlan-226.fit.nokia.com (wlan-226.fit.nokia.com [195.148.124.226]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nAR99Qob016881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Nov 2009 11:09:27 +0200 (EET) (envelope-from lars.eggert@nokia.com) From: Lars Eggert Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-25--314591658; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 27 Nov 2009 11:09:26 +0200 References: To: "multipathtcp@ietf.org List" Message-Id: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Fri, 27 Nov 2009 11:09:27 +0200 (EET) Cc: Christian Vogt Subject: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 09:09:43 -0000 --Apple-Mail-25--314591658 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, since a similar idea was just discussed here. Begin forwarded message: > From: Christian Vogt > Date: November 10, 2009 11:37:56 GMT+02:00 > To: Routing Research Group Mailing List > Subject: [rrg] New Paper On Name-Oriented Sockets Interface >=20 > Dear all - >=20 > A few meetings ago, we had an interesting discussion on evolving the > traditional sockets interface towards one that is name-oriented. A > significant part of the research group deemed this idea a candidate > solution to the routing scalability problem, since the resulting > identifier-locator separation would enable multi-homing and reduce the > cost of network renumbering. I would like to point you to a paper = that > elaborates on the name-oriented sockets interface, considering the > comments from the discussion we had: >=20 > = http://christianvogt.mailup.net/pub/2009/vogt-2009-name-oriented-sockets.p= df >=20 > Your comments are welcome as usual. Although the paper is yet to be > completed, it contains all major aspects of the solution proposed. >=20 > - Christian >=20 >=20 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg --Apple-Mail-25--314591658 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEyNzA5MDkyNlowIwYJKoZIhvcNAQkEMRYEFLgoqUI8S+Ot4QDtKpItEXYIthQkMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQA+DLqK15QyvSoOECp3eqdkVJRkOAotFlNmNS8gl8B+Y4aLQoQUrxlykIyRfmHLi7PdZJJZ sBC1N1hRhmZcGOE/btEPt6vzm2reZl1d9Lu6EvwAOPYm9IgT6OsDLtHc1IrtRYGPf7Z4blPytJI7 osZDjccYqOS1EeZsLh1/Qj7YBusr5r3Cw6DkSbANh9N37AG65CxDSLgloNbOB+TzjJUJiH/ZTN5T K4+Z8BKJJK0JEBgIhGrOoSu14yR8A7Lgvcf08rCh1SfxqSBXgxoTa0gh+oxAhmIXiXX0otcVKvBC kvY9HHLfWQlDabydMjiLUONbJK2OQ9IE+1UuaRIMiaD5AAAAAAAA --Apple-Mail-25--314591658-- From scott.brim@gmail.com Fri Nov 27 02:58:01 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5551F3A6810 for ; Fri, 27 Nov 2009 02:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os3BMcJ9WrCi for ; Fri, 27 Nov 2009 02:58:00 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 3BEE33A62C1 for ; Fri, 27 Nov 2009 02:58:00 -0800 (PST) Received: by qyk41 with SMTP id 41so591617qyk.29 for ; Fri, 27 Nov 2009 02:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=dihGkJcBuDxfZ+DQT7WzV//0+ktGhZpNPp6lel0T4vw=; b=Apjce9u/CtPxcBaMIq3ej2PVLDNE0HRVfbBT0NCfndRk6+he5+Qh3w9GiSzVeMKKav 7AvMcfRbmaprnfM5aV593ISxLUbBn6au+6aNcCPC3lw074HuNT4fjgrQtkZLhGbmTYTw +Kk1mTjCGur4fXYTD7+IEvtbxIUV0LOf419Fw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Z4i5mhDrQtO89SpA+hCHlN8nKYPT/pgQeC4cobdz+HUvrd3XR/e/UbpD6hdifd4KEg 4/c0lqvj4CobrvLfy0hx9L3eNGAy5W6HfBS2MdQAOlTblVJfDrbXpxg6KWtngN3AdLC8 wtdSpFCMyuQk2qCY1vA9xIXAn9hQADjtd3TiI= Received: by 10.224.36.157 with SMTP id t29mr420088qad.65.1259319469722; Fri, 27 Nov 2009 02:57:49 -0800 (PST) Received: from sbrim-mbp.local (ool-45780ddc.dyn.optonline.net [69.120.13.220]) by mx.google.com with ESMTPS id 2sm4148509qwi.57.2009.11.27.02.57.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 02:57:48 -0800 (PST) Message-ID: <4B0FB0AA.2060303@gmail.com> Date: Fri, 27 Nov 2009 05:57:46 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Lars Eggert References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> In-Reply-To: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "multipathtcp@ietf.org List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 10:58:01 -0000 IIRC in Christian's idea the transport layer itself works on names. It's more than a proposal for a name-based API. Scott Lars Eggert allegedly wrote on 11/27/2009 4:09 AM: > FYI, since a similar idea was just discussed here. > > Begin forwarded message: > >> From: Christian Vogt >> Date: November 10, 2009 11:37:56 GMT+02:00 >> To: Routing Research Group Mailing List >> Subject: [rrg] New Paper On Name-Oriented Sockets Interface >> >> Dear all - >> >> A few meetings ago, we had an interesting discussion on evolving the >> traditional sockets interface towards one that is name-oriented. A >> significant part of the research group deemed this idea a candidate >> solution to the routing scalability problem, since the resulting >> identifier-locator separation would enable multi-homing and reduce the >> cost of network renumbering. I would like to point you to a paper that >> elaborates on the name-oriented sockets interface, considering the >> comments from the discussion we had: >> >> http://christianvogt.mailup.net/pub/2009/vogt-2009-name-oriented-sockets.pdf >> >> Your comments are welcome as usual. Although the paper is yet to be >> completed, it contains all major aspects of the solution proposed. >> >> - Christian >> >> >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg > > > ------------------------------------------------------------------------ > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From Michael.Tuexen@lurchi.franken.de Fri Nov 27 08:58:39 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752A73A6924 for ; Fri, 27 Nov 2009 08:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.038 X-Spam-Level: ** X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbFLXz5UaRIp for ; Fri, 27 Nov 2009 08:58:38 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 62A9B3A684C for ; Fri, 27 Nov 2009 08:58:37 -0800 (PST) Received: from [192.168.1.100] (p508FDA12.dip.t-dialin.net [80.143.218.18]) by mail-n.franken.de (Postfix) with ESMTP id 442BC1C0B4049; Fri, 27 Nov 2009 17:58:28 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Fri, 27 Nov 2009 17:58:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <50B8B7D8-A0D3-4BFC-9471-F0929A19569D@lurchi.franken.de> To: "Laganier, Julien" X-Mailer: Apple Mail (2.1077) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:58:39 -0000 On Nov 25, 2009, at 7:38 PM, Laganier, Julien wrote: > Michael T=FCxen wrote: >>=20 >> On Nov 24, 2009, at 11:32 PM, Laganier, Julien wrote: >>=20 >>> Stuart Cheshire had a nice talk at IETF 72 on the drawbacks of the >>> current getaddrinfo() + connect() model w.r.t. to IPv6 = transition,see >>> http://www.stuartcheshire.org/IETF72/. (Somebody already mentioned = that >>> on the list I think.) >>>=20 >>> A connect_to_name() calls that hides all of the address family >>> subtleties under the hood does not have such drawbacks. So if we're >>> going to change the API anyway, this looks like a good occasion to=20= >>> fix that issue too, no? >>=20 >> I'm interested in the userland/kernel boundary, the system calls, not >> any kind of library calls. >=20 > Good for you. >=20 > I'm not talking about any kind of library call, I'm talking about an = API, which is what I think the WG is chartered to work on.=20 Sorry, I was not clear enough. What I meant was that it is important = where the API you are thinking about should be implemented. If it is at the kernel/userland boundary, like the socket calls, there = might be other restrictions as when you are considering library calls. The point I wanted to make is that doing DNS lookups in a userland = library is simple, doing it in the kernel is a different story. That is why I wanted to = figure out where you think you API is located at. >=20 >> So are you suggesting to do the DNS name lookups in the kernel? This >> would mean that you want to implement DLS in the kernel. I'm not sure = if I really like >> that... >> We had^H^H^H have a feature in SCTP which also requires DNS lookups >> right from the >> kernel and no-one implemented it. >=20 > I'm suggesting to do DNS lookups as a result of the connect_to_name() = API call, nothing more. But my point is if it will be in the kernel (if you think your = connect_to_name() call is a system call) or if it is in a library. If it is in the library you = still must be able to implement it using existing system calls. >=20 > --julien >=20 >> I think Stuart was referring to some stuff in CoreFoundation, which = are >> library calls, I think. >>=20 >> Best regards >> Michael >>>=20 >>> --julien >>>=20 >>>> -----Original Message----- >>>> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- >>>> bounces@ietf.org] On Behalf Of Michael T=FCxen >>>> Sent: Tuesday, November 24, 2009 1:08 PM >>>> To: William Herrin >>>> Cc: multipathtcp@ietf.org >>>> Subject: Re: [multipathtcp] Multipath Address Family >>>>=20 >>>> Dear all, >>>>=20 >>>> just one note: >>>> In SCTP we use sctp_connectx() to connect to multiple addresses. >>>> Kacheong pointed a couple of years ago out that a more generic >>>> connectx() would make sense to other protocols supporting >> multihoming >>>> as well (but there were no). >>>>=20 >>>> So you might want to look at sctp_connectx() which the SCTP socket >> API >>>> uses to handle the problem. >>>>=20 >>>> Best regards >>>> Michael >>>>=20 >>>> On Nov 24, 2009, at 1:34 PM, William Herrin wrote: >>>>=20 >>>>> On Mon, Nov 23, 2009 at 4:40 PM, Pasi Sarolahti >>>> wrote: >>>>>> I think a new address family would be a minimal needed change to >> the >>>> current >>>>>> socket API, without extending the API with new operations, but = yet >>>> provide >>>>>> an interface to handle multiple addresses in a socket. One >>>> potentially >>>>>> useful characteristic would be that this would allow name = resolver >>>> to return >>>>>> multiple IPv4 and/or IPv6 addresses from the name server as a >> single >>>>>> sockaddr structure, that could be directly given as a parameter = to >> a >>>> connect >>>>>> call, which would lead to trying which of the addresses are >>>> reachable for >>>>>> the MPTCP session. >>>>>=20 >>>>> Hi Pasi, >>>>>=20 >>>>> It seems like you want to preserve the connect() call's parameters >> by >>>>> altering the definition of sockaddr so that it can contain = multiple >>>>> addresses. >>>>>=20 >>>>> But functionally, what we really want to do is pass an array of >>>>> sockaddrs to connect(). >>>>>=20 >>>>> Stupid question time: what makes redefining sockaddr superior to = an >>>>> extended API call that supplants connect() and accepts an array of >>>>> sockaddrs? >>>>>=20 >>>>> Poking around linux's include files (netinet/in.h, bits/socket.h) = I >>>>> notice that they go to a lot of trouble to make all sockaddrs come >>>> out >>>>> to exactly the same number of bytes. Won't a variable length >> sockaddr >>>>> that holds a variable number of addresses make a mess of that? >>>>>=20 >>>>>=20 >>>>>>> SOCK_MULTISTREAM or using a combination socket type like >>>> SOCK_STREAM | >>>>>>> SOCK_MULTIPATH >>>>>>> from the following reasons. >>>>>=20 >>>>> Found a quote I think bears on the topic at >>>>> http://lkml.indiana.edu/hypermail/linux/net/9904.2/0091.html : >>>>>=20 >>>>>> The AF_ prefix stands for "address family" and the PF_prefix >> stands >>>> for >>>>>> "protocol family". Historicly, the intent was that a single >> protocol >>>> family >>>>>> might support multiple address families and that the PF_ value = was >>>> used to >>>>>> create the socket and the AF_ value was used in socket address >>>> structures. >>>>>> But in actuality, a protocol family supporting multiple address >>>> families has >>>>>> never been supported and the header defines the = PF_ >>>> value >>>>>> for a given protocol to be equal to the AF_ value for that >> protocol. >>>>>=20 >>>>> I think when we discuss allowing multipath TCP to use IPv4 and = IPv6 >>>>> addresses interchangeably, we're talking about one protocol family >>>>> using multiple address families, are we not? >>>>>=20 >>>>> Regards, >>>>> Bill Herrin >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> William D. Herrin ................ herrin@dirtside.com >>>> bill@herrin.us >>>>> 3005 Crane Dr. ...................... Web: = >>>>> Falls Church, VA 22042-3004 >>>>> _______________________________________________ >>>>> multipathtcp mailing list >>>>> multipathtcp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> multipathtcp mailing list >>>> multipathtcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>=20 >=20 >=20 From Michael.Tuexen@lurchi.franken.de Fri Nov 27 09:07:01 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680DC3A69C3 for ; Fri, 27 Nov 2009 09:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.038 X-Spam-Level: ** X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX2gJGrH9sow for ; Fri, 27 Nov 2009 09:07:00 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 29D033A6978 for ; Fri, 27 Nov 2009 09:07:00 -0800 (PST) Received: from [192.168.1.100] (p508FDA12.dip.t-dialin.net [80.143.218.18]) by mail-n.franken.de (Postfix) with ESMTP id B4FA21C0B4044; Fri, 27 Nov 2009 18:06:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20091126.041514.183027096.nishida@sfc.wide.ad.jp> Date: Fri, 27 Nov 2009 18:06:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4DA55308-08B9-442D-AA0B-37975B816E47@lurchi.franken.de> References: <20091125.091414.57515028.nishida@sfc.wide.ad.jp> <20091126.041514.183027096.nishida@sfc.wide.ad.jp> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1077) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 17:07:01 -0000 On Nov 25, 2009, at 8:15 PM, Yoshifumi Nishida wrote: >=20 > Hello Michael,=20 >=20 > From: Michael T=FCxen > Subject: Re: [multipathtcp] Multipath Address Family > Date: Wed, 25 Nov 2009 19:20:56 +0100 > Message-ID: >=20 >>>> just one note: >>>> In SCTP we use sctp_connectx() to connect to multiple addresses. >>>> Kacheong pointed a couple of years ago out that a more generic >>>> connectx() would make sense to other protocols supporting = multihoming >>>> as well (but there were no). >>>=20 >>> Just curiosity, do you know the reason why generic connectx() = doesn't exist?=20 >>> it make sense to me since the call looks independent from sctp. >> Because we were not sure what the right semantic would be: >> 1. For SCTP (or other protocols supporting multihoming), we wanted = something >> like "establish a transport connection with the peer having *all* = given addresses. >> 2. For TCP (or other protocols not supporting multihoming), we though = something >> like "establish a transport connection with a peer having *one* of = the given addresses. >> This is very different. We also assume that if the user provides = multiple address, >> all the addresses belong the the *same* host. This makes it = impossible to use >> DNS for getting them... >=20 > Thanks for the clarification. But, I still have a question... Do we = have to > connect all given addresses? You do not have to do anything right now, since it is not defined yet. The situation for us was the following: We know the peer has addr1, ... , addrn and we want to establish an SCTP = association. We do not want to test addr1 first, wait until the setup fails and then = test addr2, and so on. We want to setup an association in a fast way not being = delayed because addr1 currently fails. We have not specified if you send INITs to all = addresses simultaneously or send the first INIT to addr1 and the retransmission to = addr2, or in an other way. That is implementation specific. But do no want to wait = for the association setup to addr1 to fail (after several retransmissions) = before trying alternate addresses. We can not do this with the existing system calls and introduced = therefore the sctp_connectx() system call.=20 > If connectx() sends multiple SYNs simultaneously to the multiple = destinations, > it will be problematic. But, if connectx() has the following logic, > it tries to send a SYN one-by-one to each destination > it gets SYN-ACK, it stops to send a SYN and return. But then it can take long until you setup you transport connection. The application could just run a loop over the peer addresses and call = connect() to it, see if it works. If it fails try the next. This might take a long = time you you have a lot of addresses to try and some of them are not working. > I don't see a big issue in the logic. It may be slow in some cases, = though.=20 > I mean, connectx() is used only to find one primary destination. Other = destinations > will be found during negotiations in the transport protocol. Not from = connectx(). > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp >=20 From christian.vogt@ericsson.com Fri Nov 27 21:36:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F7C3A6846 for ; Fri, 27 Nov 2009 21:36:40 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBiSQA5L5T44 for ; Fri, 27 Nov 2009 21:36:40 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1FD203A67C1 for ; Fri, 27 Nov 2009 21:36:39 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nAS5ZSv3021475; Fri, 27 Nov 2009 23:36:31 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sat, 28 Nov 2009 00:35:35 -0500 From: Christian Vogt To: Scott Brim Date: Sat, 28 Nov 2009 00:36:45 -0500 Thread-Topic: [multipathtcp] New Paper On Name-Oriented Sockets Interface Thread-Index: Acpv7Ju5hukurp5VSQifrxxfdPBTCg== Message-ID: <9B21FA46-9827-4A12-B80A-FC1CE82A1192@ericsson.com> References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> In-Reply-To: <4B0FB0AA.2060303@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org List" Subject: Re: [multipathtcp] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 05:36:40 -0000 On Nov 27, 2009, Scott Brim wrote: > IIRC in Christian's idea the transport layer itself works on names. It's > more than a proposal for a name-based API. Scott - The use of names at the transport layer is a concept to enable session continuity across IP address changes. It doesn't have to be implemented this way as long as the transport layer can provide session continuity otherwise. As a matter of fact, I am more and more endorsing the idea of using multi-path TCP below the proposed name-based sockets interface. I think this combination would be powerful and elegant. - Christian From christian.vogt@ericsson.com Sat Nov 28 00:16:29 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60AF3A6927 for ; Sat, 28 Nov 2009 00:16:29 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw5IgMXPEv02 for ; Sat, 28 Nov 2009 00:16:29 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 13DEC3A690E for ; Sat, 28 Nov 2009 00:16:28 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nAS8GHRq019618; Sat, 28 Nov 2009 02:16:17 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sat, 28 Nov 2009 03:15:56 -0500 From: Christian Vogt To: Multipath TCP Mailing List Date: Sat, 28 Nov 2009 03:16:53 -0500 Thread-Topic: [multipathtcp] Multipath Address Family Thread-Index: AcpwAwIoGNJczyVzRZOI1co+R3rvXg== Message-ID: <98475C3E-8395-468F-84C3-6F639D6FF822@ericsson.com> References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <4B0BB35E.207@uclouvain.be> <6C8C1D51-70E5-4545-8661-196A94CDEA37@iki.fi> In-Reply-To: <6C8C1D51-70E5-4545-8661-196A94CDEA37@iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Olivier Bonaventure Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 08:16:30 -0000 On Nov 24, 2009, Pasi Sarolahti wrote: > I agree that connecting by names would eventually be the right way to > go for Internet protocols, but am not sure if that fits within the > authority of this WG anymore. It may be something that needs to be > discussed by a wider community. After my presentation [1] of name-based sockets at the RRG meeting in Hiroshima, several RRG participants suggested such a wider discussion.=20 The idea was to initiate the discussion with a presentation on name- based sockets at the Applications area, Transport area, or Internet area open meeting in March. Would folks in this working group support such a presentation? - Christian [1] http://www.ietf.org/proceedings/09nov/slides/RRG-2.pdf From christian.vogt@ericsson.com Sat Nov 28 00:35:25 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F89A3A6979 for ; Sat, 28 Nov 2009 00:35:25 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBq6hD54Lb3l for ; Sat, 28 Nov 2009 00:35:24 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C4D7E3A6974 for ; Sat, 28 Nov 2009 00:35:23 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nAS8ZF9c023879; Sat, 28 Nov 2009 02:35:15 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 28 Nov 2009 03:35:15 -0500 From: Christian Vogt To: Pasi Sarolahti Date: Sat, 28 Nov 2009 03:36:29 -0500 Thread-Topic: [multipathtcp] Multipath Address Family Thread-Index: AcpwBbTFCF5MKLzGQ0yBf6RN7naL4Q== Message-ID: <6DBE5C9B-1710-4E53-923A-701322A59AF4@ericsson.com> References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <4B0BB35E.207@uclouvain.be> <6C8C1D51-70E5-4545-8661-196A94CDEA37@iki.fi> In-Reply-To: <6C8C1D51-70E5-4545-8661-196A94CDEA37@iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" , "Olivier.Bonaventure@uclouvain.be" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 08:35:25 -0000 On Nov 24, 2009, Pasi Sarolahti wrote: > Another question is that even if we had an connect-by-name API, would we > still need to be able express which address(es) are bound to the socket > in the API? Yes. Whereas the average application using name-based sockets would not need any information about IP addresses, special applications may. Hence even a name-based sockets interface will have to provide hooks through=20 which IP address information can be obtained. - Christian From remi.despres@free.fr Mon Nov 30 04:48:50 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09EE33A6809 for ; Mon, 30 Nov 2009 04:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVDgub3pUqBM for ; Mon, 30 Nov 2009 04:48:49 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id C9B9E3A677D for ; Mon, 30 Nov 2009 04:48:46 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6AEAEE081C0; Mon, 30 Nov 2009 13:48:34 +0100 (CET) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6CDA3E08194; Mon, 30 Nov 2009 13:48:31 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4B0FB0AA.2060303@gmail.com> Date: Mon, 30 Nov 2009 13:48:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> To: Scott Brim X-Mailer: Apple Mail (2.1077) Cc: "multipathtcp@ietf.org List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 12:48:50 -0000 Le 27 nov. 2009 =E0 11:57, Scott Brim a =E9crit : > IIRC in Christian's idea the transport layer itself works on names. > It's more than a proposal for a name-based API. Agreed. I haven't studied all details of Christian's proposal, but I fully = support that: - A name-capable API is an essential objective. - Extending TCP (and MPTCP etc.) to convey some name information, e.g. = in some ad hoc option, is a logical complement. If the transport layer of a connection-acceptor, not only receives the = address of the connection initiator, but also receives its name, it can = check by a DNS query that the received address is a valid address for = the received name. This doesn't depend on any reverse mapping being available in the DNS, = and is therefore compatible with DNS dynamic updates, and even with = DNSSEC. =20 Once the validity of the name-address couple is checked, the name of the = initiator can be safely communicated, across the name-capable API, to = the called application. Properly designed, the complete name-capable API can be a backward = compatible extension of current address-based APIs. Regards, RD >=20 > Scott >=20 > Lars Eggert allegedly wrote on 11/27/2009 4:09 AM: >> FYI, since a similar idea was just discussed here. >>=20 >> Begin forwarded message: >>=20 >>> From: Christian Vogt >>> Date: November 10, 2009 11:37:56 GMT+02:00 >>> To: Routing Research Group Mailing List >>> Subject: [rrg] New Paper On Name-Oriented Sockets Interface >>>=20 >>> Dear all - >>>=20 >>> A few meetings ago, we had an interesting discussion on evolving the >>> traditional sockets interface towards one that is name-oriented. A >>> significant part of the research group deemed this idea a candidate >>> solution to the routing scalability problem, since the resulting >>> identifier-locator separation would enable multi-homing and reduce = the >>> cost of network renumbering. I would like to point you to a paper = that >>> elaborates on the name-oriented sockets interface, considering the >>> comments from the discussion we had: >>>=20 >>> = http://christianvogt.mailup.net/pub/2009/vogt-2009-name-oriented-sockets.p= df >>>=20 >>> Your comments are welcome as usual. Although the paper is yet to be >>> completed, it contains all major aspects of the solution proposed. >>>=20 >>> - Christian >>>=20 >>>=20 >>> _______________________________________________ >>> rrg mailing list >>> rrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/rrg >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From Michael.Tuexen@lurchi.franken.de Mon Nov 30 09:29:06 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7F83A6359 for ; Mon, 30 Nov 2009 09:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE+uzcfW3LrG for ; Mon, 30 Nov 2009 09:29:05 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 320103A6AD4 for ; Mon, 30 Nov 2009 09:29:05 -0800 (PST) Received: from [IPv6:2002:508f:ce17::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:ce17:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 97EDE1C0B4048; Mon, 30 Nov 2009 18:28:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Mon, 30 Nov 2009 18:28:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <151407D2-293C-4B4A-845C-0DAE958CD347@lurchi.franken.de> To: Bryan Ford X-Mailer: Apple Mail (2.1077) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:29:06 -0000 On Nov 30, 2009, at 4:59 PM, Bryan Ford wrote: > On Nov 24, 2009, at 4:04 PM, Michael T=FCxen wrote: >> On Nov 23, 2009, at 10:40 PM, Pasi Sarolahti wrote: >>> I wrote down some further thinking about the idea of multipath = address family in the form of Internet-Draft, which I thought to be = better than a long Email to the list. The draft is available at = http://tools.ietf.org/html/draft-sarolahti-mptcp-af-multipath-00 and I'd = be happy to hear further comments about it. >>>=20 >>> I think a new address family would be a minimal needed change to the = current socket API, without extending the API with new operations, but = yet provide an interface to handle multiple addresses in a socket. One = potentially useful characteristic would be that this would allow name = resolver to return multiple IPv4 and/or IPv6 addresses from the name = server as a single sockaddr structure, that could be directly given as a = parameter to a connect call, which would lead to trying which of the = addresses are reachable for the MPTCP session. Traditionally this has = been done in the applications, by cycling through the returned addresses = from resolver one by one, until connect is successful. Especially = dual-stack IPv6/IPv4 hosts should find such feature useful. >> There is one thing that I do not understand. Currently there is no = way a DNS >> server resolves a name indicating that all addresses belong to the = same host. >> You just get a list of addresses. They might belong to one host or = not. >=20 > You may not know whether all those addresses belong to the same host, = but that doesn't necessarily mean they're not useful. Just for other = security reasons, MPTCP will have to have a fairly strong mechanism to = verify that whoever is at a given alternate destination address(/port) = really is the same host we hold the logical connection with, before = starting to use a new subflow to that alternate address(/port). This is = especially true in today's heavily NATted world, where a huge number of = endpoints all through the network have highly non-unique IP addresses = like '10.1.1.x'; if one MPTCP endpoint says it has an alternate address = 10.1.1.5 but is on a different private network from the other endpoint, = it's VERY likely that the remote host's attempt to connect to 10.1.1.5 = actually WILL reach some host, but the wrong host - even without any = malicious attackers anywhere. >=20 > Thus, if we are given a bundle of DNS-resolved addresses, successfully = open an initial MPTCP connection to one of them, and then want to try = using those other addresses as alternate subflow targets, I don't see an = inherent problem with just doing that as long as MPTCP's verification is = working right, which it has to anyway. If the bundle contains addresses = of other hosts, those hosts will fail the verification check and subflow = creation to them will fail - a few network and host resources get = burned, but that can be limited with reasonable policies on attempting = new subflows. So when you connect to (IP1, ..., IPn) you want to connect to one of = them. That is fine. So if your server has n addresses but has no listening scoket, you will = exchange n SYS/RST pairs. (In SCTP we would use only one INIT/ABORT exchange and terminate = the association). >=20 > A separate issue is HOW the application "names" a bundle of addresses = to the OS. One option is to add an AF_MULTI or somesuch that takes a = bundle of already-resolved addresses, and have the application resolve = the DNS name itself to a bundle of addresses and then pass the bundle to = the sockets layer using the new AF. Another option is just to add a new = connect_by_name API, or alternately a new AF_NAME address family that = embeds a name in its sockaddr struct, and transfer the job of name = resolution into the sockets layer. The latter seems like the cleaner = approach to me: as Stuart Cheshire and Christian Vogt and others have = pointed out, connect_by_name functions are already getting added to a = lot of higher-level networking APIs and thus used by applications: this = seems to be the way the industry is going, so all we really need to do = is add a way to preserve the naming-based abstraction all the way down = to the transport interface (i.e., through the Unix sockets API). >=20 > Cheers, > Bryan >=20 >=20 From nishida@sfc.wide.ad.jp Mon Nov 30 11:56:42 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0F23A68F1 for ; Mon, 30 Nov 2009 11:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.121 X-Spam-Level: * X-Spam-Status: No, score=1.121 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIZ+b66JvKI0 for ; Mon, 30 Nov 2009 11:56:41 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id C961E3A68C9 for ; Mon, 30 Nov 2009 11:56:41 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 023004C725; Tue, 1 Dec 2009 04:56:30 +0900 (JST) Date: Tue, 01 Dec 2009 04:56:29 +0900 (JST) Message-Id: <20091201.045629.189665195.nishida@sfc.wide.ad.jp> To: christian.vogt@ericsson.com From: Yoshifumi Nishida In-Reply-To: <98475C3E-8395-468F-84C3-6F639D6FF822@ericsson.com> References: <4B0BB35E.207@uclouvain.be> <6C8C1D51-70E5-4545-8661-196A94CDEA37@iki.fi> <98475C3E-8395-468F-84C3-6F639D6FF822@ericsson.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 19:56:42 -0000 From: Christian Vogt Subject: Re: [multipathtcp] Multipath Address Family Date: Sat, 28 Nov 2009 03:16:53 -0500 Message-ID: <98475C3E-8395-468F-84C3-6F639D6FF822@ericsson.com> > On Nov 24, 2009, Pasi Sarolahti wrote: > > > I agree that connecting by names would eventually be the right way to > > go for Internet protocols, but am not sure if that fits within the > > authority of this WG anymore. It may be something that needs to be > > discussed by a wider community. > > After my presentation [1] of name-based sockets at the RRG meeting in > Hiroshima, several RRG participants suggested such a wider discussion. > The idea was to initiate the discussion with a presentation on name- > based sockets at the Applications area, Transport area, or Internet area > open meeting in March. Would folks in this working group support such a > presentation? > > - Christian > > [1] http://www.ietf.org/proceedings/09nov/slides/RRG-2.pdf With this API, is it possible for applications to specify something like "stream service" instead of specifying trasnport protocol? I mean, doesn't application have to have fallback codes for multiple transport protocols by using this API? I would like to know if we might be able to utilize this idea for gradual transitions of new trasnport protocols. -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From jnc@mercury.lcs.mit.edu Mon Nov 30 14:15:18 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13D13A68D5 for ; Mon, 30 Nov 2009 14:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiT+By75w1+Y for ; Mon, 30 Nov 2009 14:15:18 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id F26A93A68D3 for ; Mon, 30 Nov 2009 14:15:17 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9D1726BE566; Mon, 30 Nov 2009 17:15:10 -0500 (EST) To: multipathtcp@ietf.org Message-Id: <20091130221510.9D1726BE566@mercury.lcs.mit.edu> Date: Mon, 30 Nov 2009 17:15:10 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 22:15:18 -0000 > From: Yoshifumi Nishida > With this API, is it possible for applications to specify something > like "stream service" instead of specifying trasnport protocol? I mean, > doesn't application have to have fallback codes for multiple transport > protocols by using this API? Interesting idea. IIRC, the LISP Machine software had something similar (back in the days when NCP, TCP and CHAOS were all options, along with 'gateways' among same), so that's one place to look to see how such an interface might actually look/work. Noel From christian.vogt@ericsson.com Mon Nov 30 16:12:27 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDBC3A6842 for ; Mon, 30 Nov 2009 16:12:26 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZXskYP9rKiM for ; Mon, 30 Nov 2009 16:12:22 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 049F43A6358 for ; Mon, 30 Nov 2009 16:12:21 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nB10CCNO025772; Mon, 30 Nov 2009 18:12:13 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 30 Nov 2009 19:12:10 -0500 From: Christian Vogt To: Yoshifumi Nishida Date: Mon, 30 Nov 2009 19:13:30 -0500 Thread-Topic: [multipathtcp] Multipath Address Family Thread-Index: AcpyGu0RgMZyVk3mQQKoyAj5jmEKHg== Message-ID: References: <4B0BB35E.207@uclouvain.be> <6C8C1D51-70E5-4545-8661-196A94CDEA37@iki.fi> <98475C3E-8395-468F-84C3-6F639D6FF822@ericsson.com> <20091201.045629.189665195.nishida@sfc.wide.ad.jp> In-Reply-To: <20091201.045629.189665195.nishida@sfc.wide.ad.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 00:12:27 -0000 On Nov 30, 2009, Yoshifumi Nishida wrote: >> After my presentation [1] of name-based sockets at the RRG meeting in >> Hiroshima, several RRG participants suggested such a wider discussion.=20 >> The idea was to initiate the discussion with a presentation on name- >> based sockets at the Applications area, Transport area, or Internet area >> open meeting in March. Would folks in this working group support such a >> presentation? >>=20 >> - Christian >>=20 >> [1] http://www.ietf.org/proceedings/09nov/slides/RRG-2.pdf >=20 > With this API, is it possible for applications to specify something > like "stream service" instead of specifying trasnport protocol?=20 Indeed, Yoshifumi. And there is flexibility regarding which such "transport services" applications should be able to explicitly select. The current version of the paper defines only one service: stream-=20 orientation as opposed to datagram-orientation. This could be extended to enable the explicit selection of additional services, such as reliability or even congestion control. The current limitation to one service is a pragmatic choice, which is based on today's small choice of transport protocols. But I agree that an ability to define more services could foster the deployment of new transport protocols. - Christian From christian.vogt@ericsson.com Mon Nov 30 19:13:02 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF34D28C199 for ; Mon, 30 Nov 2009 19:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNNbveor4YE0 for ; Mon, 30 Nov 2009 19:13:00 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 472E43A67E4 for ; Mon, 30 Nov 2009 19:13:00 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nB13CbRe028452; Mon, 30 Nov 2009 21:12:49 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 30 Nov 2009 22:12:39 -0500 From: Christian Vogt To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Mon, 30 Nov 2009 22:13:59 -0500 Thread-Topic: [multipathtcp] New Paper On Name-Oriented Sockets Interface Thread-Index: AcpyNCM6Wx8UwCeHTfC8HII1wde5kw== Message-ID: <2EA9DEC2-D23E-40CA-A420-89A0EA355440@ericsson.com> References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Multipath TCP Mailing List , Scott Brim Subject: Re: [multipathtcp] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 03:13:02 -0000 [Resending this email, since it didn't make it to the list.] On Nov 30, 2009, R=E9mi Despr=E9s wrote: > I haven't studied all details of Christian's proposal, but I fully=20 > support that: >=20 > - A name-capable API is an essential objective. > - Extending TCP (and MPTCP etc.) to convey some name information, e.g.=20 > in some ad hoc option, is a logical complement. >=20 > If the transport layer of a connection-acceptor, not only receives the > address of the connection initiator, but also receives its name, it can > check by a DNS query that the received address is a valid address for > the received name. This doesn't depend on any reverse mapping being > available in the DNS, and is therefore compatible with DNS dynamic > updates, and even with DNSSEC. Once the validity of the name-address > couple is checked, the name of the initiator can be safely communicated, > across the name-capable API, to the called application. >=20 > Properly designed, the complete name-capable API can be a backward > compatible extension of current address-based APIs. Exactly, R=E9mi. In fact, your reflections on security and backwards compatibility are both included in the paper at: http://christianvogt.mailup.net/pub/2009/vogt-2009-name-oriented-sockets.pd= f - Christian