From nobody Mon Dec 1 10:33:41 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B7B1A6EFF for ; Mon, 1 Dec 2014 10:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Tc0DpgoCHoa for ; Mon, 1 Dec 2014 10:33:35 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7261A6EE8 for ; Mon, 1 Dec 2014 10:33:34 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 1 Dec 2014 18:33:33 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 1 Dec 2014 18:33:32 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Mon, 1 Dec 2014 18:33:31 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.12.165]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sB1IXTI8013598; Mon, 1 Dec 2014 18:33:29 GMT Message-ID: <201412011833.sB1IXTI8013598@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 1 Dec 2014 18:33:27 +0000 To: , Yoshifumi Nishida From: Bob Briscoe In-Reply-To: <547B8744.7070007@uclouvain.be> References: <201411281245.sASCjrKM021852@bagheera.jungle.bt.co.uk> <547B8744.7070007@uclouvain.be> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/N3t5CYfTANtEFoHUeP_IP8-VE-Y Cc: Costin RAICIU , draft-ietf-mptcp-rfc6824bis@tools.ietf.org, Olivier Bonaventure , multipathtcp@ietf.org, "HANDLEY, Mark" Subject: Re: [multipathtcp] RFC6824bis: knowing if a Data ACK should have been received? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 18:33:38 -0000 Olivier, Yoshifumi [I've pasted your reply into Olivier's below], At 21:08 30/11/2014, Olivier Bonaventure wrote: >Bob, >> >>I am trying to determine how an MPTCP endpoint will know if TCP options >>start to be stripped part-way through a subflow (e.g. due to a mobile IP >>handover that MPTCP is not aware of, which brings a new middlebox into >>the path). > >This could indeed be a problem. For simplicity, let us assume that >the new middlebox removes all MPTCP options from all segments (it >seems safe to assume that this middlebox is not MPTCP aware and thus >should treat all MPTCP options in the same way). Then, we have to >considered two different cases : > >1- The MPTCP connection uses two subflows, one affected by the >middlebox and the other not > >2- The MPTCP connection uses a single subflow, affected by the middlebox > >In case 1, the Data_ack will not arrive anymore on the affected >subflow and after some time the data (at the MPTCP level) will be >retransmitted on the other subflow. Data flow will continue on one >subflow after a slowdown. This is what we already see with some FTP >ALG as described in >http://inl.info.ucl.ac.be/publications/are-tcp-extensions-middlebox-proof > >In case 2, the problem is different. The data cannot be >retransmitted over another subflow. Maybe an implementation could >detect this problem after N attemtps to retransmit the data. I may be missing sth (I admit I only have partial knowledge of MPTCP), but why does suddenly starting to strip options prevent data being sent? I imagine that stripping options would only prevent data being acknowledged at the Data ACK level. Each subflow will still ACK data, so why will there be any retransmission needed? >Since MPTCP options are stripped, mp_fail and infinite mappings >cannot be exchanged to solve the problem. Maybe one option could be >to close the subflow and restablish another one. Before we get to solutions, the first problem to get over is how to detect there is a problem - per subflow. That's why I thought some degree of deterministic Data ACK behaviour would be useful. More.. >>I guess the best way to tell would be absence of DATA ACKs, however the >>RFC6842bis draft does not encourage an implementation to send DATA ACKs >>unless the cumulative Data ACK has advanced (see the para quoted below). >> >>* Question: If all the cumulative ACKs of all the subflows have >>advanced, can an implementation be sure that the Data ACK should have >>advanced and therefore be certain that it should have received a Data ACK? >> >>* Edit request: While reading RFC6842bis I noticed a MUST seems to be >>missing... >> >> >>3.3.2. Data Acknowledgments >>CURRENT: >> The Data ACK MAY be included in all segments; however, optimizations >> SHOULD be considered in more advanced implementations, where the Data >> ACK is present in segments only when the Data ACK value advances, and >> this behavior MUST be treated as valid. This behavior ensures the >> sender buffer is freed, while reducing overhead when the data >> transfer is unidirectional. >>SUGGESTED: >> The Data ACK MUST be included when the Data ACK value advances. It MAY >> be included in all segments; however, optimizations SHOULD be >>considered >> in more advanced implementations, where the Data ACK is present only >>when >> it advances, and this behavior MUST be treated as valid. This >>behavior ensures the >> sender buffer is freed, while reducing overhead when the data >> transfer is unidirectional. At 20:50 30/11/2014, Yoshifumi Nishida wrote: >What if there is no enough option space to put MPTCP option? OK, a MUST would be too strong. [Alternatively we could use one of the option space schemes being proposed in tcpm (hint: if you need to pick one, Inner Space is really cool ;) ] >I'm not in favor of forcing a data_ack each time the data ack >advances because this would prevent the utilisation of delayed acks >that are useful to reduce the cpu consumption. If we go in this >direction, we should at least agree to not send more data_ack than >subflow level tcp acks That's understood. The wording was only a suggestion. The underlying needs are: - determinism in at least one MPTCP option, so that the endpoints can tell if they stop; - clarity that Data ACKs do have to be sent eventually, most probably by specifying how much they can be deferred by. Bob >Olivier > >-- >INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be ________________________________________________________________ Bob Briscoe, BT From nobody Mon Dec 1 23:12:56 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5958A1A0103 for ; Mon, 1 Dec 2014 23:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xC48YfN0-ZJ for ; Mon, 1 Dec 2014 23:12:50 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEF01A00A8 for ; Mon, 1 Dec 2014 23:12:50 -0800 (PST) Received: from mbpobo-2.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 1BC9319C07D; Tue, 2 Dec 2014 08:11:28 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 1BC9319C07D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1417504288; bh=F+qURo3qI9JgiOGIke1dQajuvpETRA0AdIcjP65/pKE=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XPZjlNjMogOnvAdEm2UlJ1LdVJLL62CfR9EtuAHiRnnEITRHZciDurm5/1nM9KxUO YuWT1x30nYjc3b16yZqMWAVfOpdM2H9YuWErUIv5K3FBaYDV8ffOCufGp99sk4IUW/ l3QaaD1D5xwW0h+mhYmj2zJ67GthlbAHcBWs9+2k= Message-ID: <547D6620.4010901@uclouvain.be> Date: Tue, 02 Dec 2014 08:11:28 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe , Yoshifumi Nishida References: <201411281245.sASCjrKM021852@bagheera.jungle.bt.co.uk> <547B8744.7070007@uclouvain.be> <201412011833.sB1IXTI8013598@bagheera.jungle.bt.co.uk> In-Reply-To: <201412011833.sB1IXTI8013598@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1BC9319C07D.A72F7 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/huOxeESqO9FKroWZZM1Sae8w8Eo Cc: multipathtcp@ietf.org, Costin RAICIU , draft-ietf-mptcp-rfc6824bis@tools.ietf.org, "HANDLEY, Mark" Subject: Re: [multipathtcp] RFC6824bis: knowing if a Data ACK should have been received? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 07:12:53 -0000 Bob, >>> >>> I am trying to determine how an MPTCP endpoint will know if TCP options >>> start to be stripped part-way through a subflow (e.g. due to a mobile IP >>> handover that MPTCP is not aware of, which brings a new middlebox into >>> the path). >> >> This could indeed be a problem. For simplicity, let us assume that the >> new middlebox removes all MPTCP options from all segments (it seems >> safe to assume that this middlebox is not MPTCP aware and thus should >> treat all MPTCP options in the same way). Then, we have to considered >> two different cases : >> >> 1- The MPTCP connection uses two subflows, one affected by the >> middlebox and the other not >> >> 2- The MPTCP connection uses a single subflow, affected by the middlebox >> >> In case 1, the Data_ack will not arrive anymore on the affected >> subflow and after some time the data (at the MPTCP level) will be >> retransmitted on the other subflow. Data flow will continue on one >> subflow after a slowdown. This is what we already see with some FTP >> ALG as described in >> http://inl.info.ucl.ac.be/publications/are-tcp-extensions-middlebox-proof >> >> In case 2, the problem is different. The data cannot be retransmitted >> over another subflow. Maybe an implementation could detect this >> problem after N attemtps to retransmit the data. > > I may be missing sth (I admit I only have partial knowledge of MPTCP), > but why does suddenly starting to strip options prevent data being sent? Data is sent and acked at the subflow level but not acked at the MPTCP level since the new middlebox strips all MPTCP options. > I imagine that stripping options would only prevent data being > acknowledged at the Data ACK level. Each subflow will still ACK data, so > why will there be any retransmission needed? The MPTCP-level retransmissions are included in MPTCP to cope notably with problems due to middlebox interference. >> Since MPTCP options are stripped, mp_fail and infinite mappings cannot >> be exchanged to solve the problem. Maybe one option could be to close >> the subflow and restablish another one. > > Before we get to solutions, the first problem to get over is how to > detect there is a problem - per subflow. That's why I thought some > degree of deterministic Data ACK behaviour would be useful. More.. Basically if a subflow suddenly strips all MPTCP options, then there is nothing useful that MPTCP can do with this subflow. If the DSS option does not pass through anymore, then MPTCP cannot send data over this subflow. > >> I'm not in favor of forcing a data_ack each time the data ack advances >> because this would prevent the utilisation of delayed acks that are >> useful to reduce the cpu consumption. If we go in this direction, we >> should at least agree to not send more data_ack than subflow level tcp >> acks > > That's understood. The wording was only a suggestion. The underlying > needs are: > - determinism in at least one MPTCP option, so that the endpoints can > tell if they stop; My concern is that if all MPTCP options that passed through are suddenly stripped, then I don't see what can be done > - clarity that Data ACKs do have to be sent eventually, most probably by > specifying how much they can be deferred by. The Data ACKs should be sent when both : - a subflow level ACK is sent according to the TCP rules - and the Data_ack advances The wording that we use should be compatible with large DSS mappings that could be used by hosts that support TSO/GRO. Olivier Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Tue Dec 2 04:42:59 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD82C1A1B3D; Tue, 2 Dec 2014 04:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTXC-z6LNMpi; Tue, 2 Dec 2014 04:42:52 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9488D1A1B12; Tue, 2 Dec 2014 04:42:52 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so16743247wgh.23 for ; Tue, 02 Dec 2014 04:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dxR6jsChQi6T/tWB1dEV71z6F88XXbKMrKeOC4lz8F8=; b=Bb71zhlV0t4dLiy+HpNhUSW80VMiSl3FqEgpzQo1ToDPyGP4upH2TVOa7Qzy0M0fqT 9Qz6gigoVDhLQYZvql9RQGEGzChcaP0jtSb/bR9XdY6jI3zgsk4EOBaMZ2Ua3XNDh34q i6E43SJ7bBncoO+SAETG7briQPe+UM4fAHGpSgqoAMyC85fddne0s5B/pcY9CjO6xadf zB71MsfWvLX2mg/Dzp19vNStZsZvQbC7e1xdeJAbS662+LHUI3qzyOH6YmW8HrHC6NRu WHDPt4c2+rW8rbF9X6cSA76BKGNlR80BvUaAjegcysYeBW4alX0kHRNO7wHrOAbdSj4q ba2A== MIME-Version: 1.0 X-Received: by 10.180.98.100 with SMTP id eh4mr5016915wib.54.1417524171178; Tue, 02 Dec 2014 04:42:51 -0800 (PST) Received: by 10.194.76.237 with HTTP; Tue, 2 Dec 2014 04:42:51 -0800 (PST) Date: Tue, 2 Dec 2014 13:42:51 +0100 Message-ID: From: Daniel Migault To: "mif@ietf.org" , "multipathtcp@ietf.org Mailing List" Content-Type: multipart/alternative; boundary=f46d04428cd2af0a0105093b1098 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/fg_g9R-7IOwD5cVsVsQYnCXmDuw Cc: Yaron Sheffer , Valery Smyslov , Paul Hoffman Subject: [multipathtcp] Securing Multiple Interfaces with IPsec X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 12:42:58 -0000 --f46d04428cd2af0a0105093b1098 Content-Type: text/plain; charset=UTF-8 Hi, We would like to inform you that the ipsecme WG has started an survey of interest [1] for the draft-mglt-ipsecme-clone-ike-sa [2]. This draft details how to set IPsec Security Associations with multiple Interfaces. If you think this topic should or should not be addressed please respond to this mail by December 8. If you have any question regarding the document, feel free to let us know. BR Daniel and Valery (authors of the draft) *I. Area that may benefit from this optimization:* The main scenarios we envisioned IPsec with multiple interfaces were: - Offload from RAN to WLAN network - Resilience - Multiple Path TCP: I believe this is the optimal way to have IPsec with multiple Path TCP for example. *II. Scenarios that motivated the document* Initial motivation for the document was to optimize setting IPsec associations with devices that have more than one interface. Briefly speaking, currently, setting an IPsec association with multiple interfaces requires one authentication per interface. This introduces multiple delays, especially when authentication requires multiple round trip. With the optimization, we make it possible to configure it with a single authentication. Authentication is performed on a single interface, and for the other interfaces, IPsec authentication and settings is "replicated". Another scenario that motivated us was load sharing between different security gateways (each of them has its own IP addresses). In this case client creates IKE SA with any of these security gateways and then could be moved to another without re-authentication. Of course this assumes that security gateways can communicate between each other and exchange IKE & IPsec SA states. [1] http://www.ietf.org/mail-archive/web/ipsec/current/msg09442.html [2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/ -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d04428cd2af0a0105093b1098 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We would like to inform = you that the ipsecme WG has started an survey of interest [1] for the= draft-mglt-ipsecme-clone-ike-sa [2].= This draft details how to set IPsec Security Associations with multiple In= terfaces. If you think this topic should or should not be addressed please = respond to this mail by December 8.

If you have any question regard= ing the document, feel free to let us know.

BR

Daniel and Val= ery (authors of the draft)

I. Area that may benefit from this= optimization:

The main scenarios we envisioned IPsec with m= ultiple interfaces were:
=C2=A0=C2=A0=C2=A0 - Offload from RA= N to WLAN network
=C2=A0=C2=A0=C2=A0 - Resilience
=C2=A0=C2=A0=C2=A0 - Multiple Path TCP: I believe this is the opt= imal way to have IPsec with multiple Path TCP for example.


II. Sce= narios that motivated the document
=C2=A0=C2=A0=C2=A0
=
Initial motivation for the document was to optimize setting IPsec=20 associations with devices that have more than one interface. Briefly=20 speaking, currently, setting an IPsec association with multiple=20 interfaces requires one authentication per interface. This introduces=20 multiple delays, especially when authentication requires multiple round=20 trip. With the optimization, we make it possible to configure it with a=20 single authentication. Authentication is performed on a single=20 interface, and for the other interfaces, IPsec authentication and=20 settings is "replicated".

Another scenario that= =20 motivated us was load sharing between different security gateways (each=20 of them has its own IP addresses). In this=20 case client creates IKE SA with any of these security gateways= and then could be moved to another without re-authentication. Of course this assumes that=20 security gateways can communicate between each other and exchange IKE & IPsec SA states.


[1] http:= //www.ietf.org/mail-archive/web/ipsec/current/msg09442.html
[2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-= ike-sa/

--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
--f46d04428cd2af0a0105093b1098-- From nobody Thu Dec 11 13:50:44 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12EA1A0387 for ; Thu, 11 Dec 2014 13:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ikk3GfRXmLC for ; Thu, 11 Dec 2014 13:50:40 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2D61A036B for ; Thu, 11 Dec 2014 13:50:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418334640; x=2282248240; h=From:Sender:Reply-To:Subject:Date:Message-Id:To:Cc:Mime-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+ijiavfySg7wAB8tcqX12BGehlk8WYOmlo+zncm6mao=; b=T9vZRrZwO+s0dP6gBWINSU5ssUiCKs+Z8kJVvLXbFxNOcu021ZWtkBObJdUp0TMn zcO/70ala2Zand0HQSsy3KJVDaC4Xrwl3ZfVYwk/Feoam6ld5EkCUg6v0De9g/7Y pNF5iqnMwkyvMxe9MfiNXMg6yKF/BkwnJcJSJNaENmqSnz5mKTpIR3eE0AhuVQxM 8o4SzflBRvAA2/jZuHnWGvW7DYohTLcBkroIrZp+K4HcW8s/lMXMxyrbnkrxVLWv 1PClwl8T90sSTDbSfy7S+ayoiaYrxA+fUy9i5R/bmCo6z4Uxte/ESD9nRc/8g/kj 1ynGDX6cHmBWClhkZyZptw==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 31.03.26546.0B11A845; Thu, 11 Dec 2014 13:50:40 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-34-548a11b05b73 Received: from ba0301a-dhcp15.apple.com (ba0301a-dhcp15.apple.com [17.193.14.143]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 46.76.05439.5B11A845; Thu, 11 Dec 2014 13:50:46 -0800 (PST) From: Anumita Biswas Content-Type: multipart/alternative; boundary="Apple-Mail=_2F99BEBA-E965-48AB-A461-86C3831F8CA4" Message-Id: Date: Thu, 11 Dec 2014 13:50:39 -0800 To: Olivier.Bonaventure@uclouvain.be, alanford@cisco.com, m.handley@cs.ucl.ac.uk, Costin Raiciu , multipathtcp@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUi2FAYrLtBsCvEYOMaLot7z1axWMx4tILN 4u7vaSwWn1dfZ7O40fCDxYHVY8rvjawez46vZfJYsuQnk8erY99ZAliiuGxSUnMyy1KL9O0S uDLOzPrJWjDds2JF3wvGBsbrNl2MnBwSAiYSv+f3MUPYYhIX7q1n62Lk4hAS2Mso8fbrFSa4 ohcn2CESK5gknjzdwg6SYBPQlzj66AZQNwcHs0CCRPehOpCwsICqxOyGn6wgNq+AjcSMRz/B 5rAAxY/u7wSbIyIwjVFi09PnYL28AnoSVzu1IHbJSvy7eAasRkKgh01iQ8dBtgmMfLMQVsxC 6JgF1MEsoC2xbOFrZghbU2J/93IWTHENic5vE1kXMLKtYhTKTczM0c3MM9JLLCjISdVLzs/d xAgK7Ol2gjsYj6+yOsQowMGoxMMrENsZIsSaWFZcmXuIUZqDRUmc1/sHUEggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVAOjT5rx0QMvYxfrPVnB7FtT/OL1JrWU0z/eOHy1E2OVvDWjMVfSuKTt 3sKanTo5XbMFt4oY8Dbw6/HPmm/o5BGkl2Rsf/34bT/BbcIzPr1nfiguxBlxrXeh5UU/M93l P5ZZsJV+Ved7xCbNdtawaPm0BKW4vVrvPwb/a1HVFTiw6EbGm6+HplQpsRRnJBpqMRcVJwIA KPgDX00CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUieJCvX3ebYFeIQe8PJot7z1axWMx4tILN 4u7vaSwWn1dfZ7O40fCDxYHVY8rvjawez46vZfJYsuQnk8erY99ZAliiuGxSUnMyy1KL9O0S uDLOzPrJWjDds2JF3wvGBsbrNl2MnBwSAiYSv1+cYIewxSQu3FvP1sXIxSEksIJJ4snTLWAJ NgF9iaOPbjB3MXJwMAskSHQfqgMJCwuoSsxu+MkKYvMK2EjMePSTCcRmAYof3d/JDjJHRGAa o8Smp8/BenkF9CSudmpB7JKV+HfxDPsERu5ZCFNnIRTNAipiFtCWWLbwNTOErSmxv3s5C6a4 hkTnt4msCxjZVjEKFKXmJFYa6yUWFOSk6iXn525iBAViQ2HwDsY/y6wOMQpwMCrx8ArEdoYI sSaWFVfmHmKU4GBWEuF99B0oxJuSWFmVWpQfX1Sak1p8iFGag0VJnLfiXWOIkEB6Yklqdmpq QWoRTJaJg1OqgVGkfuenHe/P5fAEzm88lD8lKbQ46MINT/dZkVt+PDr+Iu2dk+HPW/8O2PZt TOjZHpfRe4H9nYS+QvOqNjGvfo0TirdWBj1X//9I93vi6W8nsvy3reZ2uL4j69ntODfJiS8z CnZkci4+PmPfBKP045LWsX/ZykorOvj3TD9vcF1SN2GXjP4a4UwlluKMREMt5qLiRABayW3Y QAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/Ded3C_P4DpVXvdZNCL9K4KzeQJU Subject: [multipathtcp] MPTCP Versioning in RFC 6824 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 21:50:43 -0000 --Apple-Mail=_2F99BEBA-E965-48AB-A461-86C3831F8CA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, MPTCP Version 0 should include a solution for the backward compatibility = problem that will exist once MPTCP has a version number higher than 0.=20= The MPTCP header used in the MP_CAPABLE option has a 4bit field for the = Version. The existing MPTCP spec RFC 6824 does not specify how clients = and servers are to behave upon receiving a non-zero number in that = field.=20 "The first 4 bits of the first octet in the MP_CAPABLE option (Figure 4) define the MPTCP option subtype (see Section 8 = ; for MP_CAPABLE, this is 0), and the remaining 4 bits of this octet specify the MPTCP version in use (for this specification, this is 0). =E2=80=9C Current implementations fall back to a regular TCP handshake when a = non-zero version number is received. These implementations of version 0 = should be modified to include a way to support higher versions of MPTCP. = Otherwise we will be stuck with version 0 for future revs of the MPTCP = standard. Proposal: When initiating a connection, a client requests a version number of its = choice in the SYN + MP_CAPABLE segment.=20 The server can accept by replying with that version number in the = MP_CAPABLE response in SYN/ACK, OR The server can decline by replying = with a version number lower than the version advertised by the client in = its SYN. The version negotiation is completed by having both client and server = fall to the version that is the minimum of the versions advertised by = the parties. This version is sent by the client in the ACK of the 3-way = handshake.=20 The client should also be able to fallback to regular TCP after the = receipt of the SYN/ACK+MP_CAPABLE with lower version number, if it does = not support the lower version or chooses to not use the lower version. So for example, the client requests version number 1 in SYN+MP_CAPABLE. = If the server supports only version 0, it replies with version 0. Client = then falls back to the version 0 implementation thereby still having the = benefits of using MPTCP version 0 for that connection rather than = regular TCP. Secondly, it would be fantastic if the support for experimental work was = added to the bis spec as follows: The standard allocates one version number for =E2=80=9Cexperimental=E2=80=9D= purposes. Lets say we allocate 15, which is the highest allocatable = version number in the MPTCP header. With this, both client and server = can still fall back to version 0 if the server does not support version = 15. However, if the server does support version 15, then both client and = server are free to use extensions or additions to the base MPTCP spec = with no guarantees given to either party that things will work as = expected. But this allows room for experimentation on the Internet and = if/when some extension proves to be useful and working well in the = field, that extension can be ported back to a non experimental version = like version 1 for instance.=20 For all this to work, the current MPTCP implementers will have to add = the following support in their version 0 implementation:=20 a. A server must accept a SYN with any version number. b. The server must reply with the version number it supports or wishes = to use, provided it is equal to or lower than the client=E2=80=99s = version number, and not fall back to a regular TCP handshake in SYN/ACK. c. The client must echo the minimum of the versions advertised by the = client and server in the ACK of the 3-way handshake or fallback to = regular TCP if it does not support the server=E2=80=99s version.=20 Please let me know your thoughts on this, Thanks, Anumita Biswas --Apple-Mail=_2F99BEBA-E965-48AB-A461-86C3831F8CA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

MPTCP Version 0 should include a = solution for the backward compatibility problem that will exist once = MPTCP has a version number higher than 0. 

The MPTCP header used in the MP_CAPABLE = option has a 4bit field for the Version. The existing MPTCP spec RFC = 6824 does not specify how clients and servers are to behave upon = receiving a non-zero number in that field. 

"The first 4 bits of the first octet in the =
MP_CAPABLE option
   (Figure 4) define the MPTCP option subtype (see Section =
8; for
   MP_CAPABLE, this is 0), and the remaining 4 bits of this octet
   specify the MPTCP version in use (for this specification, this is =
0).
=E2=80=9C

Current implementations fall back = to a regular TCP handshake when a non-zero version number is received. = These implementations of version 0 should be modified to include a way = to support higher versions of MPTCP. Otherwise we will be stuck with = version 0 for future revs of the MPTCP standard.

Proposal:

When initiating a = connection, a client requests a version number of its choice in the SYN = + MP_CAPABLE segment. 

The server can accept by replying with that version number = in the MP_CAPABLE response in SYN/ACK, OR The server can decline by = replying with a version number lower than the version advertised by the = client in its SYN.

The version negotiation is completed by having both client = and server fall to the version that is the minimum of the versions = advertised by the parties. This version is sent by the client in the ACK = of the 3-way handshake. 

The client should also be able to = fallback to regular TCP after the receipt of the SYN/ACK+MP_CAPABLE with = lower version number, if it does not support the lower version or = chooses to not use the lower version.

So for example, the client requests = version number 1 in SYN+MP_CAPABLE. If the server supports only version = 0, it replies with version 0. Client then falls back to the version 0 = implementation thereby still having the benefits of using MPTCP version = 0 for that connection rather than regular TCP.

Secondly, it would be fantastic if the = support for experimental work was added to the bis spec as = follows:

The = standard allocates one version number for =E2=80=9Cexperimental=E2=80=9D = purposes. Lets say we allocate 15, which is the highest allocatable = version number in the MPTCP header. With this, both client and server = can still fall back to version 0 if the server does not support version = 15. However, if the server does support version 15, then both client and = server are free to use extensions or additions to the base MPTCP spec = with no guarantees given to either party that things will work as = expected. But this allows room for experimentation on the Internet and = if/when some extension proves to be useful and working well in the = field, that extension can be ported back to a non experimental version = like version 1 for instance. 

For all this to work, the current MPTCP = implementers will have to add the following support in their version 0 = implementation: 

a. A server must accept a SYN with any version = number.
b. The server must reply with the version = number it supports or wishes to use, provided it is equal to or lower = than the client=E2=80=99s version number, and not fall back to a regular = TCP handshake in SYN/ACK.
c. The client must = echo the minimum of the versions advertised by the client and server in = the ACK of the 3-way handshake or fallback to regular TCP if it does not = support the server=E2=80=99s version. 

Please let me know your thoughts on = this,

Thanks,
Anumita Biswas

= --Apple-Mail=_2F99BEBA-E965-48AB-A461-86C3831F8CA4-- From nobody Fri Dec 12 09:29:40 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D54B1A6FB5 for ; Fri, 12 Dec 2014 09:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0aJUGtEzGrZ for ; Fri, 12 Dec 2014 09:29:37 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBE81A1A9C for ; Fri, 12 Dec 2014 09:29:37 -0800 (PST) Received: from mbpobo-2.dhcp.info.ucl.ac.be (mbpobo-2.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id F0CD9198024; Fri, 12 Dec 2014 18:29:31 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be F0CD9198024 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1418405372; bh=FCit34f9IIZve5u141+VKipmVAWdu5s+v4zHftxvO50=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ny43FrXLb2854FqK7Ugv//ma3Dh0uscs2YW5fn7CyCTTp+hqrVTzox4mqtDW4Y0zo ztZAjcXwKFrywv+DCTGrOcZr9mpIlH7Deed7u5JoTZHPy4WY9+YOmDqCyZFaVeLJDN GVTWTxxD5L56bRP/zz9A6mwvOHspVbL+1XGqYDBc= Message-ID: <548B25FC.3060200@uclouvain.be> Date: Fri, 12 Dec 2014 18:29:32 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Anumita Biswas , multipathtcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: F0CD9198024.A1848 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/VEl9rna6FFGIvVXi8GasSS_Ux_0 Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 17:29:39 -0000 Anumita, > > a. A server must accept a SYN with any version number. > b. The server must reply with the version number it supports or wishes > to use, provided it is equal to or lower than the client’s version > number, and not fall back to a regular TCP handshake in SYN/ACK. > c. The client must echo the minimum of the versions advertised by the > client and server in the ACK of the 3-way handshake or fallback to > regular TCP if it does not support the server’s version. > Your proposal looks really good to me Olivier From nobody Mon Dec 15 00:33:22 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C99B1A0A85 for ; Mon, 15 Dec 2014 00:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfRh-MHLW-zR for ; Mon, 15 Dec 2014 00:33:17 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA5D1A1A6D for ; Mon, 15 Dec 2014 00:33:17 -0800 (PST) Received: from mbpobo-2.dhcp.info.ucl.ac.be (mbpobo-2.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 683CE18346D; Mon, 15 Dec 2014 09:33:10 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 683CE18346D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1418632390; bh=oXeTAcwe+vnzWKzSSbcr6Tiqyjg5pdbW2QAONXU4AoA=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Dz24dOc5ECo55EPErFauPFGV5CkxJ3NLmH8ZOtKhAeViVDuXEwb4GCaFSAh1Xjns7 qLnAgqYecS5JmahisnzjVeKqS7q4GlbU5A3lOaQ8cQa9+FqT/tGn1QF74lGocHk3gr 0thpx24QUMVJvPr0UKXVM3zEa6c3dX0+J1u970Do= Message-ID: <548E9CC6.9080601@uclouvain.be> Date: Mon, 15 Dec 2014 09:33:10 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Anumita Biswas , multipathtcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 683CE18346D.A19C0 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/9Xi1qB8KX47-59smVih8rkMAxok Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 08:33:19 -0000 Anumita, > > Secondly, it would be fantastic if the support for experimental work was > added to the bis spec as follows: > > The standard allocates one version number for “experimental” purposes. > Lets say we allocate 15, which is the highest allocatable version number > in the MPTCP header. With this, both client and server can still fall > back to version 0 if the server does not support version 15. However, if > the server does support version 15, then both client and server are free > to use extensions or additions to the base MPTCP spec with no guarantees > given to either party that things will work as expected. But this allows > room for experimentation on the Internet and if/when some extension > proves to be useful and working well in the field, that extension can be > ported back to a non experimental version like version 1 for instance. This is also a very good idea. I'd suggest to encourage the implementors to document any planned usage of version 15 with an IETF draft published before the start of the experiment and report later about the results of the experiments. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Mon Dec 15 09:50:08 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158D31A86E9 for ; Mon, 15 Dec 2014 09:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 710T_nVFsM_k for ; Mon, 15 Dec 2014 09:50:05 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4851A86EB for ; Mon, 15 Dec 2014 09:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418665804; x=2282579404; h=From:Sender:Reply-To:Subject:Date:Message-Id:To:Cc:Mime-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QjTBUPd3BVrlgu4pgOZWHO3lT7leOW/aIdDcQQkBVcM=; b=ZYWEWdGK6zMBM9riWlrL2nI9oSH0FzPI0yVh/+DwOeSJI6czFEt41k/ck5Qagf9H XKTQNV1JIAfuyiVNHBC4C8VuUe34sSEbaxroppsCCmY7eJkfXqAEddpp+zM61QO0 0tmCZjZlxiv789Jsz3eFlDr9slIBG6BQjICm3fzao781iLWIfNxCg7Fn+2TL15vD svsNc9MyYWARYOVe1WzvesPk8yLCw8ae+7vszG7z4vHbS2C6a7bqic3NiopY5/ht YxGFjJc87qeK1p9/SX5ETjiEtBu8BVRJH5jQBFXumauMOfUGNXyLAzj/BTJ8ep+2 jkjcl9eJy4msJU5ENO7zEA==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 2F.52.07917.C4F1F845; Mon, 15 Dec 2014 09:50:04 -0800 (PST) X-AuditID: 11973e13-f794a6d000001eed-b6-548f1f4c1e07 Received: from ba0301a-dhcp15.apple.com (ba0301a-dhcp15.apple.com [17.193.14.143]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 3B.F4.05439.25F1F845; Mon, 15 Dec 2014 09:50:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anumita Biswas In-Reply-To: <548E9CC6.9080601@uclouvain.be> Date: Mon, 15 Dec 2014 09:50:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <43C27241-37C5-4551-A224-A19BC525EEA1@apple.com> References: <548E9CC6.9080601@uclouvain.be> To: Olivier.Bonaventure@uclouvain.be X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUi2FAYrOsj3x9isPCihsXn1dfZLG40/GBx YPJYsuQnk8erY99ZApiiuGxSUnMyy1KL9O0SuDLeta9kLNjKXXHrwAvGBsZuzi5GTg4JAROJ JwdXsUPYYhIX7q1n62Lk4hAS2MsocfzECjaYoqdrzrJAJFYwSTya+gkswSygLvFn3iXmLkYO Dl4BPYmrnVogYWEBTYm2GRdYQWw2AX2Jo49uMIPYnAI6Ek3nNzOB2CwCqhKvpx1ihRgjKbHi 7ycoW1ti2cLXYPW8AjYS8699AFslJBAj8f3uVTBbREBFYnLfc2aI22Ql/l08ww5ym4TAV1aJ P0vnME9gFJqF5LxZCOfNQrJiASPzKkah3MTMHN3MPFO9xIKCnFS95PzcTYygAJ5uJ7yD8fQq q0OMAhyMSjy8EYx9IUKsiWXFlbmHGKU5WJTEeZe5dYcICaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYCxz7//VeKJvIrfhSXGhSdU54nwXjFf+mfenKmF9vpb9c9mwp0cfCnDq9194/CN1hfa+ W9nhB+oWxDqybVW0mhZ1Pz939/2cSIO70zRrFB7OO+wf/EBEa439j51vN5jdlWTnWCn9+LZS dbli5Y+V10+KSId+rZ9lNyllw/JT/IuCF6jEf3DeckeJpTgj0VCLuag4EQAIWTYwQQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUieJCvXzdIvj/E4O1vZYvPq6+zWdxo+MHi wOSxZMlPJo9Xx76zBDBFcdmkpOZklqUW6dslcGW8a1/JWLCVu+LWgReMDYzdnF2MnBwSAiYS T9ecZYGwxSQu3FvP1sXIxSEksIJJ4tHUT2wgCWYBdYk/8y4xdzFycPAK6Elc7dQCCQsLaEq0 zbjACmKzCehLHH10gxnE5hTQkWg6v5kJxGYRUJV4Pe0QK8QYSYkVfz9B2doSyxa+BqvnFbCR mH/tA9gqIYEYie93r4LZIgIqEpP7njND3CYr8e/iGfYJjPyzkFw0C+GiWUimLmBkXsUoUJSa k1hprJdYUJCTqpecn7uJERRwDYXBOxj/LLM6xCjAwajEwxvB2BcixJpYVlyZe4hRgoNZSYTX XaY/RIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvxbvGECGB9MSS1OzU1ILUIpgsEwenVANjVVPX NLVrISp3pxRN3eTYvn37VtYLTC4dv9VPnPs5P5uP8WdgPp9v/5VpHed1/q2YuETcRj01YMuu CX8Yd4nlLv38eIPIW866ZbyHFVx79bQ42/yv/WFy+ckjdsFpzw3uwxElbhMMZ34Lvf7sbJr+ 0s6gpwv+uPx7fGpmGHPl/UILl9uB19kdlFiKMxINtZiLihMBKNrKczQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/I_h0X82PR1k-PjeT4ABGXImTc5g Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 17:50:07 -0000 Olivier, > On Dec 15, 2014, at 12:33 AM, Olivier Bonaventure = wrote: >=20 > Anumita, >>=20 >> Secondly, it would be fantastic if the support for experimental work = was >> added to the bis spec as follows: >>=20 >> The standard allocates one version number for =E2=80=9Cexperimental=E2=80= =9D purposes. >> Lets say we allocate 15, which is the highest allocatable version = number >> in the MPTCP header. With this, both client and server can still fall >> back to version 0 if the server does not support version 15. However, = if >> the server does support version 15, then both client and server are = free >> to use extensions or additions to the base MPTCP spec with no = guarantees >> given to either party that things will work as expected. But this = allows >> room for experimentation on the Internet and if/when some extension >> proves to be useful and working well in the field, that extension can = be >> ported back to a non experimental version like version 1 for = instance. >=20 > This is also a very good idea. I'd suggest to encourage the = implementors to document any planned usage of version 15 with an IETF = draft published before the start of the experiment and report later = about the results of the experiments. That makes sense. Thanks! Anumita >=20 >=20 > Olivier >=20 >=20 > --=20 > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Wed Dec 17 10:07:00 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E5D1A6F40 for ; Wed, 17 Dec 2014 10:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG5JFsjg7Xmc for ; Wed, 17 Dec 2014 10:06:48 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5771A1A047A for ; Wed, 17 Dec 2014 10:06:36 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 17 Dec 2014 18:06:33 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 17 Dec 2014 18:06:33 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 17 Dec 2014 18:06:32 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.40.205]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sBHI6L4I009494; Wed, 17 Dec 2014 18:06:29 GMT Message-ID: <201412171806.sBHI6L4I009494@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Dec 2014 17:33:35 +0000 To: From: Bob Briscoe In-Reply-To: <547D6620.4010901@uclouvain.be> References: <201411281245.sASCjrKM021852@bagheera.jungle.bt.co.uk> <547B8744.7070007@uclouvain.be> <201412011833.sB1IXTI8013598@bagheera.jungle.bt.co.uk> <547D6620.4010901@uclouvain.be> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/m5qPs8h5K872BCAvapYsXbLllW4 Cc: Costin RAICIU , draft-ietf-mptcp-rfc6824bis@tools.ietf.org, multipathtcp@ietf.org, "HANDLEY, Mark" Subject: Re: [multipathtcp] RFC6824bis: knowing if a Data ACK should have been received? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:06:55 -0000 Olivier, At 07:11 02/12/2014, Olivier Bonaventure wrote: >Bob, >>>> >>>>I am trying to determine how an MPTCP endpoint will know if TCP options >>>>start to be stripped part-way through a subflow (e.g. due to a mobile IP >>>>handover that MPTCP is not aware of, which brings a new middlebox into >>>>the path). >>> >>>This could indeed be a problem. For simplicity, let us assume that the >>>new middlebox removes all MPTCP options from all segments (it seems >>>safe to assume that this middlebox is not MPTCP aware and thus should >>>treat all MPTCP options in the same way). Then, we have to considered >>>two different cases : >>> >>>1- The MPTCP connection uses two subflows, one affected by the >>>middlebox and the other not >>> >>>2- The MPTCP connection uses a single subflow, affected by the middlebox >>> >>>In case 1, the Data_ack will not arrive anymore on the affected >>>subflow and after some time the data (at the MPTCP level) will be >>>retransmitted on the other subflow. Data flow will continue on one >>>subflow after a slowdown. This is what we already see with some FTP >>>ALG as described in >>>http://inl.info.ucl.ac.be/publications/are-tcp-extensions-middlebox-proof >>> >>>In case 2, the problem is different. The data cannot be retransmitted >>>over another subflow. Maybe an implementation could detect this >>>problem after N attemtps to retransmit the data. >> >>I may be missing sth (I admit I only have partial knowledge of MPTCP), >>but why does suddenly starting to strip options prevent data being sent? > >Data is sent and acked at the subflow level but not acked at the >MPTCP level since the new middlebox strips all MPTCP options. That was my point. The sender can still /send/ data until the sender's flow-control window reduces to zero due to the Data ACKs being stripped. So we can specify how the receiver detects lack of MPTCP options on this 'dying gasp' of data. >>I imagine that stripping options would only prevent data being >>acknowledged at the Data ACK level. Each subflow will still ACK data, so >>why will there be any retransmission needed? > >The MPTCP-level retransmissions are included in MPTCP to cope >notably with problems due to middlebox interference. Understood. Thx >>>Since MPTCP options are stripped, mp_fail and infinite mappings cannot >>>be exchanged to solve the problem. Maybe one option could be to close >>>the subflow and restablish another one. >> >>Before we get to solutions, the first problem to get over is how to >>detect there is a problem - per subflow. That's why I thought some >>degree of deterministic Data ACK behaviour would be useful. More.. > >Basically if a subflow suddenly strips all MPTCP options, then there >is nothing useful that MPTCP can do with this subflow. If the DSS >option does not pass through anymore, then MPTCP cannot send data >over this subflow. If case 1, other combinations of interfaces could be tried. (I don't think we should add the ability to close one subflow over a different subflow - adds an unnecessary new vulnerability.) If case 2, an error can at least be thrown up to the app and the subflow closed at the TCP level. Whatever, you keep jumping to solution mode. But I'm trying to keep the focus on problem detection first. The reason I sent the email originally was because the MPTCP spec is not deterministic enough to even determine when there is a problem. On one hand, an MPTCP session doesn't need a solution if it is not yet certain there is a problem. On the other, once both ends of a session can deterministically know the subflow's dead, they can at least stop trying to be alive. Both ends can shut themselves down with a timeout if data has been / is being sent, but no MPTCP options are getting through and no Data ACKs are getting back. >>>I'm not in favor of forcing a data_ack each time the data ack advances >>>because this would prevent the utilisation of delayed acks that are >>>useful to reduce the cpu consumption. If we go in this direction, we >>>should at least agree to not send more data_ack than subflow level tcp >>>acks >> >>That's understood. The wording was only a suggestion. The underlying >>needs are: >>- determinism in at least one MPTCP option, so that the endpoints can >>tell if they stop; > >My concern is that if all MPTCP options that passed through are >suddenly stripped, then I don't see what can be done > >>- clarity that Data ACKs do have to be sent eventually, most probably by >>specifying how much they can be deferred by. > >The Data ACKs should be sent when both : > > - a subflow level ACK is sent according to the TCP rules > - and the Data_ack advances > >The wording that we use should be compatible with large DSS mappings >that could be used by hosts that support TSO/GRO. Someone needs to propose the precise wording (I'm not expert enough on MPTCP), and failure detection will need to be implemented against the wording. Cheers Bob >Olivier > > > >Olivier > >-- >INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be ________________________________________________________________ Bob Briscoe, BT From nobody Wed Dec 17 13:52:47 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29E01A7021 for ; Wed, 17 Dec 2014 13:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY86yfIGQIoS for ; Wed, 17 Dec 2014 13:52:43 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 28DA81A86EC for ; Wed, 17 Dec 2014 13:52:43 -0800 (PST) Received: from mbpobo-2.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 95608198033; Wed, 17 Dec 2014 22:52:37 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 95608198033 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1418853157; bh=CVHfwkZlQZ2BS+zjvio5zDSY+k20AwyByApKK5hJw/g=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=srThCbpXNMckzw5FguzeudbKSpLGfS376EwaewnJI5Zg7ApbOiHNml3v9t9dwxHTO t7bvgh1agyEVPydcUX33HE+D6hB7T6+Doq0zFIIVZ/Ig9j9IcYT6W7LnrbcSe1JfgM /oO1VfDg77qy/7bMLi5x+8i4lLJ4yTW0xRJ53hc4= Message-ID: <5491FB25.1070200@uclouvain.be> Date: Wed, 17 Dec 2014 22:52:37 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <201411281245.sASCjrKM021852@bagheera.jungle.bt.co.uk> <547B8744.7070007@uclouvain.be> <201412011833.sB1IXTI8013598@bagheera.jungle.bt.co.uk> <547D6620.4010901@uclouvain.be> <201412171806.sBHI6L4I009494@bagheera.jungle.bt.co.uk> In-Reply-To: <201412171806.sBHI6L4I009494@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 95608198033.A0B72 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/RHEgSD3pCfBqdcMQwIWHdzneeDg Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] RFC6824bis: knowing if a Data ACK should have been received? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 17 Dec 2014 21:52:45 -0000 Bob, >>> Before we get to solutions, the first problem to get over is how to >>> detect there is a problem - per subflow. That's why I thought some >>> degree of deterministic Data ACK behaviour would be useful. More.. Let's go back to detection first as you suggest. For simplicity, I assume that data flows only in the A->B direction and there is a single subflow, which is the worst case. If there are two subflows, one affected by a middlebox that suddently strips MPTCP options and not the other, then MPTCP will eventually stop using the path where options are stripped. The connection has been running for some time and A sends data. A sends data with one DSS per segment for simplicity. The middlebox strips the MPTCP option from all TCP segments. B receives data in sequence at subflow level without DSS options. This data is acked at the subflow level. B includes a Data_ack that does not advance in each TCP ack, but this option is stripped by the middlebox. Given that the DSS option can only map up to 64 KBytes of data, B can be sure that there is a problem once it has received 64 KBytes of in-sequence data without any DSS. This cannot happen on a valid MPTCP connection. Host A could detect the problem earlier when it receives regular acks but no data_acks for the same data. To prevent false negatives, we'd probably need to wait for some number of mappings or some amount of data. If there are two or more subflows, the problem is more complex since data is not in sequence on each subflow and it is normal to receive regular acks that are decoupled from the data_acks Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be