From christoph.paasch@uclouvain.be Wed Aug 1 05:45:40 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749F511E8102 for ; Wed, 1 Aug 2012 05:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWIIPlDfjI0W for ; Wed, 1 Aug 2012 05:45:39 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 91F1311E8355 for ; Wed, 1 Aug 2012 05:45:30 -0700 (PDT) Received: from cpaasch-mac.localnet (wifi-secure1-263.sri.ucl.ac.be [130.104.121.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6579311E6DC; Wed, 1 Aug 2012 14:45:25 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 6579311E6DC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1343825125; bh=THBt2dMArG4a7BeGen1qef1m5v+YpJ0aExTB7fNNjlU=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=WsjQjPsaEi43R30H0C76E3Eu6OW+UeihvweaUihk3Sli54tyU3huQRad78wY984H3 eAbuEaBbzZpEYq720HouLgNSdRcMwD6W2FkK/LtSkP7vDT98M3qlhdF/Y5LARKqhYU Uw/3SW8ruAjSK/tq3h3DxqWjKnu+mAmrCzBn//ZY= From: Christoph Paasch To: Anumita Biswas Date: Wed, 01 Aug 2012 14:45:24 +0200 Message-ID: <1494798.q17lBF49r3@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic; KDE/4.8.4; x86_64; ; ) In-Reply-To: <66708DC5-FC75-4865-A361-4D407E248415@apple.com> References: <66708DC5-FC75-4865-A361-4D407E248415@apple.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6579311E6DC.AE882 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , Mahesh M , Ilpo =?ISO-8859-1?Q?J=E4rvinen?= Subject: Re: [multipathtcp] Number of DSS to store X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Christoph Paasch List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 12:45:40 -0000 Hi Anumita & Alan, On Tuesday 31 July 2012 21:44:35 Anumita Biswas wrote: > A DSS option may not be sent with corresponding data if there isn't = enough > tcp option space available such as due to the presence of SACK blocks= . Then the number of SACK-blocks could get reduced for the packet that ne= eds to=20 hold the DSS-option, or the SACK-blocks can be on a separate subflow-ac= k. SACK-blocks don't necessarily need to be sent reliably. However, the DS= S- option has to be sent reliably. That's why it is good to couple it toge= ther=20 with the data as delivery is thus guaranteed. Alan, in your slides yesterday you said: "A mapping for subflow seqno x MUST not be=20 sent before the mappings for subflow seqno=20 0 .. x-1 have been sent." This will still force receivers to be able to store an uncertain number= of=20 DSS-mappings. I believe we should say: "A mapping, covering the subflow seqno's x to y MUST be sent on one of = these=20 segments." That way the receiver only has to store one single DSS-mapping option p= er=20 subflow. Cheers, Christoph --=20 IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Universit=E9 Catholique de Louvain -- From christoph.paasch@uclouvain.be Wed Aug 1 08:22:42 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF8421F88F8 for ; Wed, 1 Aug 2012 08:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyBWG0-z9uIy for ; Wed, 1 Aug 2012 08:22:38 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id DB89621F88EC for ; Wed, 1 Aug 2012 08:22:37 -0700 (PDT) Received: from cpaasch-mac.localnet (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id ECD0411E731; Wed, 1 Aug 2012 17:22:32 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be ECD0411E731 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1343834552; bh=v6SY9bT+xtphJBNPzhqvYWpQg542IQYqn8vjcCP8DO8=; h=From:To:Reply-To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=yxAsA+88KBmGnPLEtab43sBo9+3chC3MEPG7FSJSTx6GBGTnb4GM+zfP9PL1bx0C/ VRnBQxbosPbFBjn9ytQiknRlqQD4yXDYYDIadSHO856Aa9Ip2tnu5K4N8aFeGySx4v RQKfZbODOTah2HL1SrM0MVZL2U8cM6Um41cv7Co0= From: Christoph Paasch To: alanford@cisco.com, multipathtcp@ietf.org Date: Wed, 01 Aug 2012 17:22:32 +0200 Message-ID: <2856617.9fWnaT0qcQ@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic; KDE/4.8.4; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: ECD0411E731.A032A X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Clarification concerning window-updates X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:22:42 -0000 Hello, the draft says in Section 3.3.5: The sender remembers receiver window advertisements from the receiver. It should only update its local receive window values whe= n the largest sequence number allowed (i.e. DATA_ACK + receive window= ) increases. This is important to allow using paths with different RTTs, and thus different feedback loops. However, it does not explicity say that it should only update the recei= ve- window if a DATA_ACK is in the packet. Because, if he would also accept= the=20 window-advertisement from packets without DATA_ACK (inferring the DATA_= ACK=20 from the SND.UNA), he might increase the window although he should not = have=20 done so. So, I think the draft should be more explicit here: The sender MUST NOT update the receive-window if the packet does not co= ntain a=20 DATA_ACK. Cheers, Christoph --=20 IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Universit=E9 Catholique de Louvain -- From iesg-secretary@ietf.org Wed Aug 1 09:43:20 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B2411E81D9; Wed, 1 Aug 2012 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp3v90VxLRBs; Wed, 1 Aug 2012 09:43:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC8811E81BC; Wed, 1 Aug 2012 09:43:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120801164318.14464.69318.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2012 09:43:18 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] Last Call: (TCP Extensions for Multipath Operation with Multiple Addresses) to Experimental RFC X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:43:20 -0000 The IESG has received a request from the Multipath TCP WG (mptcp) to consider the following document: - 'TCP Extensions for Multipath Operation with Multiple Addresses' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1842/ http://datatracker.ietf.org/ipr/1843/ From mglt.ietf@gmail.com Wed Aug 1 10:25:20 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F10211E822A; Wed, 1 Aug 2012 10:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=2.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJSmAF7m4uXQ; Wed, 1 Aug 2012 10:25:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B52F111E818B; Wed, 1 Aug 2012 10:25:00 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so14271091obb.31 for ; Wed, 01 Aug 2012 10:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jLMMtU6WhcaOoO+Otul4G8z59xVgMdiZ8DJyXOgWBkw=; b=Bq2lwCSq92DdDNju0xY09Oskb50YgDjZhY5bSfNN838z5HL9BLTPPUxkRmS8Bj63JI 3g6yjD76SA7+vDQRHO8g3YOvdIKt7xfUPYoMCe34zeXTvs5lAxNswPX30Pk+9TVwEmuW abTIdb7OblVyCWdDYnF0Va/BG9UZCBlcaELnR0BepWCegyA1gbHV/i8zYdB+I0N9cDJt vfvJFZHscbVWjyIQF0R8SMdYPFus90twTbTkcbbNrF9xhvmreggAsMQ9E1AkTbZ4FfOx IrsAgbkmA0D6O1HinyPapj/dxNnl+iXUNurGPhEyB8FKS9DrCYNMz0hMtm0lIxUEwXZ6 PwlQ== MIME-Version: 1.0 Received: by 10.182.2.233 with SMTP id 9mr30111943obx.11.1343841900346; Wed, 01 Aug 2012 10:25:00 -0700 (PDT) Received: by 10.182.111.34 with HTTP; Wed, 1 Aug 2012 10:25:00 -0700 (PDT) In-Reply-To: References: <20120730045037.978.65071.idtracker@ietfa.amsl.com> Date: Wed, 1 Aug 2012 19:25:00 +0200 Message-ID: From: Daniel Migault To: mif@ietf.org, ipsec@ietf.org, multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=f46d0444ea811abf3a04c6379351 Subject: Re: [multipathtcp] New Version Notification for draft-mglt-mif-security-requirements-02.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:25:20 -0000 --f46d0444ea811abf3a04c6379351 Content-Type: text/plain; charset=ISO-8859-1 Hi, We will be presenting MIF security requirements for IPsec at the mif meeting at 1pm. If you have free time, we would appreciate you come and participate in the discussion. BR, Daniel On Mon, Jul 30, 2012 at 6:59 AM, Daniel Migault wrote: > Please find the new version of IPsec security requirements with Multiple > Interfaces. > > Comments and suggestions are welcome > > BR > > Daniel > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jul 30, 2012 at 6:50 AM > Subject: New Version Notification for > draft-mglt-mif-security-requirements-02.txt > To: mglt.ietf@gmail.com > Cc: carlw@mcsr-labs.org > > > > A new version of I-D, draft-mglt-mif-security-requirements-02.txt > has been successfully submitted by Daniel Migault and posted to the > IETF repository. > > Filename: draft-mglt-mif-security-requirements > Revision: 02 > Title: IPsec Multiple Interfaces Requirements > Creation date: 2012-07-30 > WG ID: Individual Submission > Number of pages: 16 > URL: > http://www.ietf.org/internet-drafts/draft-mglt-mif-security-requirements-02.txt > Status: > http://datatracker.ietf.org/doc/draft-mglt-mif-security-requirements > Htmlized: > http://tools.ietf.org/html/draft-mglt-mif-security-requirements-02 > Diff: > http://tools.ietf.org/rfcdiff?url2=draft-mglt-mif-security-requirements-02 > > Abstract: > Multiple Interface Nodes (MIF Nodes) may use their Multiple > Interfaces to perform Mobility, Multihoming. Then, these MIF Nodes > may also manage traffic between these Multiple Interfaces. Because > IPsec has not been designed for Multiple Interfaces, MIF Nodes have > difficulties to benefit from MIF features with IPsec protected > communications. > > This document provides use cases where IPsec protected communications > would take advantage of MIF features. From these uses cases, we > identify the different IPsec features MIF Nodes would require. Then, > we expose the limitations of the IPsec related protocols IKEv2 and > MOBIKE regarding to these MIF features before listing the MIF IPsec > Security Requirements that should be address by a extension of IKEv2 > or MOBIKE. > > > > > The IETF Secretariat > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d0444ea811abf3a04c6379351 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

We will be presenting MIF security requirements for IPsec at th= e mif meeting at 1pm. If you have free time, we would appreciate you come a= nd participate in the discussion.

BR,
Daniel

On Mon, Jul 30, 2012 at 6:59 AM, Daniel Migault <mglt.ietf@gmail.com= > wrote:
Please find the new version of IPsec security requirements with Multiple In= terfaces.

Comments and suggestions are welcome

BR

Dani= el


---------- Forwarded message ----------
From: <internet-drafts@ietf.org<= /a>>
Date: Mon, Jul 30, 2012 at 6:50 AM
Subject: New Versio= n Notification for draft-mglt-mif-security-requirements-02.txt
To: mglt.ietf@gmai= l.com
Cc: c= arlw@mcsr-labs.org



A new version of I-D, draft-mglt-mif-security-requirements-02.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-mif-security-requirements
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 IPsec Multiple Interfaces Requirements
Creation date: =A0 2012-07-30
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 16
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.= ietf.org/internet-drafts/draft-mglt-mif-security-requirements-02.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.= org/doc/draft-mglt-mif-security-requirements
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/d= raft-mglt-mif-security-requirements-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://tools.= ietf.org/rfcdiff?url2=3Ddraft-mglt-mif-security-requirements-02

Abstract:
=A0 =A0Multiple Interface Nodes (MIF Nodes) may use their Multiple
=A0 =A0Interfaces to perform Mobility, Multihoming. =A0Then, these MIF Node= s
=A0 =A0may also manage traffic between these Multiple Interfaces. =A0Becaus= e
=A0 =A0IPsec has not been designed for Multiple Interfaces, MIF Nodes have<= br> =A0 =A0difficulties to benefit from MIF features with IPsec protected
=A0 =A0communications.

=A0 =A0This document provides use cases where IPsec protected communication= s
=A0 =A0would take advantage of MIF features. =A0From these uses cases, we =A0 =A0identify the different IPsec features MIF Nodes would require. =A0Th= en,
=A0 =A0we expose the limitations of the IPsec related protocols IKEv2 and =A0 =A0MOBIKE regarding to these MIF features before listing the MIF IPsec<= br> =A0 =A0Security Requirements that should be address by a extension of IKEv2=
=A0 =A0or MOBIKE.




The IETF Secretariat



--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58



--
Daniel Mi= gault
Orange Labs -- Security
+33 6 70 72 69 58
--f46d0444ea811abf3a04c6379351-- From ramin.khalili@epfl.ch Wed Aug 1 17:54:53 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745CC11E81F6 for ; Wed, 1 Aug 2012 17:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzbIq4LemFS6 for ; Wed, 1 Aug 2012 17:54:52 -0700 (PDT) Received: from smtp4.epfl.ch (smtp4.epfl.ch [128.178.224.218]) by ietfa.amsl.com (Postfix) with SMTP id 1580A11E81DD for ; Wed, 1 Aug 2012 17:54:51 -0700 (PDT) Received: (qmail 12451 invoked by uid 107); 2 Aug 2012 00:54:48 -0000 X-Virus-Scanned: ClamAV Received: from slb-nat-128-178-ace-064.epfl.ch (HELO EWA4.intranet.epfl.ch) (192.26.47.64) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTP; Thu, 02 Aug 2012 02:54:48 +0200 Received: from REXME.intranet.epfl.ch ([fe80::6554:d3e6:c514:2026]) by EWA4.intranet.epfl.ch ([2002:80b2:e040::80b2:e040]) with mapi id 14.02.0309.002; Thu, 2 Aug 2012 02:53:22 +0200 From: Khalili Ramin To: "multipathtcp@ietf.org" Thread-Topic: Technical report for draft-khalili-mptcp-performance-issues-00 Thread-Index: Ac1wRMO0OwYWwRfKQOiYiJCSbjMufg== Date: Thu, 2 Aug 2012 00:53:01 +0000 Message-ID: Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.71.125] Content-Type: multipart/alternative; boundary="_000_B20442DB7A739B4CB083DA0F24635C2F29EA5C56REXMEintranetep_" MIME-Version: 1.0 Subject: [multipathtcp] Technical report for draft-khalili-mptcp-performance-issues-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:54:53 -0000 --_000_B20442DB7A739B4CB083DA0F24635C2F29EA5C56REXMEintranetep_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, Following to my talk yesterday, please find our technical report at: http://infoscience.epfl.ch/record/177901/files/Khalili_mptcp-nonParetoOptim= ality.pdf In this report, we discuss more in detail about the performance problems we= identified with the current MPTCP implementation, as well as a possible so= lution. We would be very happy to receive your comments and feedbacks about= the work. Regards, Ramin. --_000_B20442DB7A739B4CB083DA0F24635C2F29EA5C56REXMEintranetep_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,

Following to my talk yesterday, please find our technical report at:

http://infoscience.epfl.ch/record/1= 77901/files/Khalili_mptcp-nonParetoOptimality.pdf

In this report, we discuss more in detail about the performance problems we= identified with the current MPTCP implementation, as well as a possible so= lution. We would be very happy to receive your comments and feedbacks about= the work.

Regards,
Ramin.



 
 
--_000_B20442DB7A739B4CB083DA0F24635C2F29EA5C56REXMEintranetep_-- From nishida@sfc.wide.ad.jp Sun Aug 5 23:09:43 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1301D21F850C for ; Sun, 5 Aug 2012 23:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.709 X-Spam-Level: X-Spam-Status: No, score=-101.709 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so9aknaJUieR for ; Sun, 5 Aug 2012 23:09:42 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 9192E21F8501 for ; Sun, 5 Aug 2012 23:09:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2AC4627807D for ; Mon, 6 Aug 2012 15:09:38 +0900 (JST) Received: by lbbgg6 with SMTP id gg6so225409lbb.31 for ; Sun, 05 Aug 2012 23:09:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.54.100 with SMTP id i4mr4063445lbp.97.1344233376692; Sun, 05 Aug 2012 23:09:36 -0700 (PDT) Received: by 10.112.131.39 with HTTP; Sun, 5 Aug 2012 23:09:36 -0700 (PDT) Date: Sun, 5 Aug 2012 23:09:36 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=bcaec55400eee9bac704c692b86e Subject: [multipathtcp] minutes for Vancouver meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 06:09:43 -0000 --bcaec55400eee9bac704c692b86e Content-Type: text/plain; charset=ISO-8859-1 Hello, I uploaded a draft minute for vancouver meeting on the following URL. If you have comments or corrections on this, please let us know. http://www.ietf.org/proceedings/84/minutes/minutes-84-mptcp We appreciate Pasi for note taking and Michael for jabber support. Thanks, -- Yoshifumi & Phil --bcaec55400eee9bac704c692b86e Content-Type: text/html; charset=ISO-8859-1 
Hello,

I uploaded a draft minute for vancouver meeting on the following URL.
If you have comments or corrections on this, please let us know.

http://www.ietf.org/proceedings/84/minutes/minutes-84-mptcp

We appreciate Pasi for note taking and Michael for jabber support.

Thanks,
--
Yoshifumi & Phil
--bcaec55400eee9bac704c692b86e-- From georg.hampel@alcatel-lucent.com Mon Aug 20 07:46:15 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D1521F86C9 for ; Mon, 20 Aug 2012 07:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3k53InQ7haT for ; Mon, 20 Aug 2012 07:46:14 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 32A1721F86BE for ; Mon, 20 Aug 2012 07:46:14 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7KEji3c013656 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 Aug 2012 16:45:53 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 Aug 2012 16:45:47 +0200 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.231]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 20 Aug 2012 10:45:42 -0400 From: "Hampel, K Georg (K Georg)" To: Christoph Paasch , Anumita Biswas Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1WI+Dp/haF4AVDRoS7OtIAVF6w+wA95giAAAyBLuD//6NNgP//+weAgAJz/YCAAF8iAIAACV+AgALaroCAABu7AIAAI/MAgAAE6YCAAYgQgIAAAf8AgBGDdYCAGB2hAIAAI4mAgACGVwD/4lR5kA== Date: Mon, 20 Aug 2012 14:45:41 +0000 Message-ID: References: <66708DC5-FC75-4865-A361-4D407E248415@apple.com> <1494798.q17lBF49r3@cpaasch-mac> In-Reply-To: <1494798.q17lBF49r3@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "multipathtcp@ietf.org" , Mahesh M , =?iso-8859-1?Q?Ilpo_J=E4rvinen?= Subject: Re: [multipathtcp] Number of DSS to store X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 14:46:15 -0000 Quite honestly, I think we are getting lost in details. There is very littl= e implementation and real-world experience with MPTCP. The simplest possibl= e implementation sends ONE DSS per packet and does NO buffering of payload-= w/o-mapping or mappings-w/o-payload and it may in fact provide proper opera= tion in the vast majority of use cases. Exceptions should be based on real-= world trials rather than speculation. I agree with Christoph that on sender side, DSS should have priority over S= ACK blocks. Georg -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Wednesday, August 01, 2012 8:45 AM To: Anumita Biswas Cc: Alan Ford (alanford); Hampel, K Georg (K Georg); multipathtcp@ietf.org;= Mahesh M; Ilpo J=E4rvinen Subject: Re: [multipathtcp] Number of DSS to store Hi Anumita & Alan, On Tuesday 31 July 2012 21:44:35 Anumita Biswas wrote: > A DSS option may not be sent with corresponding data if there isn't enou= gh > tcp option space available such as due to the presence of SACK blocks. Then the number of SACK-blocks could get reduced for the packet that needs = to=20 hold the DSS-option, or the SACK-blocks can be on a separate subflow-ack. SACK-blocks don't necessarily need to be sent reliably. However, the DSS- option has to be sent reliably. That's why it is good to couple it together= =20 with the data as delivery is thus guaranteed. Alan, in your slides yesterday you said: "A mapping for subflow seqno x MUST not be=20 sent before the mappings for subflow seqno=20 0 .. x-1 have been sent." This will still force receivers to be able to store an uncertain number of= =20 DSS-mappings. I believe we should say: "A mapping, covering the subflow seqno's x to y MUST be sent on one of thes= e=20 segments." That way the receiver only has to store one single DSS-mapping option per=20 subflow. Cheers, Christoph --=20 IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Universit=E9 Catholique de Louvain -- From anumita_biswas@apple.com Mon Aug 27 11:33:59 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AA621F8512 for ; Mon, 27 Aug 2012 11:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJmsPhTxfu3H for ; Mon, 27 Aug 2012 11:33:53 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id E494D21F84F7 for ; Mon, 27 Aug 2012 11:33:53 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lBtjTNAkh+fzkZ6BbSh8FQ)" Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M9F000XZFKGJDL1@mail-out.apple.com> for multipathtcp@ietf.org; Mon, 27 Aug 2012 11:33:52 -0700 (PDT) X-AuditID: 1180711d-b7f486d000003381-12-503bbd8f84bd Received: from panthera-tigris.apple.com (panthera-tigris.apple.com [17.193.13.99]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id BE.7D.13185.F8DBB305; Mon, 27 Aug 2012 11:33:51 -0700 (PDT) From: Anumita Biswas In-reply-to: Date: Mon, 27 Aug 2012 11:33:51 -0700 Message-id: References: <66708DC5-FC75-4865-A361-4D407E248415@apple.com> <1494798.q17lBF49r3@cpaasch-mac> To: "Hampel, K Georg (K Georg)" X-Mailer: Apple Mail (2.1472) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUieJA3Wbd/r3WAwaYNuhb3nq1isZh6ZjKL xes14hbbZ5xns2j7OYHd4vPq62wObB6tz/ayekz5vZHV4/XkCYwe/Sv3s3ssWfKTyePVse8s AWxRXDYpqTmZZalF+nYJXBmnfm9mLfjhW7Hz9yq2BsZtDl2MnBwSAiYSS1f+ZYawxSQu3FvP 1sXIxSEksJJJ4suM6WwgCWaBBInjt++CFfEK6EnMe/mHEcQWFjCSWHLiOZjNJqAvcfTRDbAa ToFoib2tS5i6GDk4WARUJe48tAaZySzwg1Hi2tVmFog5NhJPT05nhlh2nlFi9bxTYMtEBBwl ljSfZoe4SFbiwPrbzBMY+WYhuWMWkjsg4toSyxa+Zoaw9SReNr1jxxTXlbi4bhLjAka2VYyC Rak5iZWGxnqJBQU5qXrJ+bmbGEFh31Aou4Nx/0/+Q4wCHIxKPLw/tlsHCLEmlhVX5h5ilOBg VhLhvbYJKMSbklhZlVqUH19UmpNafIhRmoNFSZyXZwdQSiA9sSQ1OzW1ILUIJsvEwSnVwChZ WqUZEru2IzrkH6PhzRq1yjXSHZdm/2g99dxdtOpp6/kLYvk2/4/yTBa8OlvhprJlc4WMxzrB vrcScxfN+jVjTty9+U1X10+2mnrWKj+E59ld/gNCF5d1fBdR3qKltf/eI84n6tl1qb+myNz5 E+l5PXZvlsuKpGnxZ/sMrva+zbnn/1CnfacSS3FGoqEWc1FxIgClODPbdwIAAA== Cc: "multipathtcp@ietf.org" , Mahesh M , =?iso-8859-1?Q?Ilpo_J=E4rvinen?= Subject: Re: [multipathtcp] Number of DSS to store X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:33:59 -0000 --Boundary_(ID_lBtjTNAkh+fzkZ6BbSh8FQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Continuing on the topic of SACK and on Duplicate ACKs in general;=20 Seeking clarification on this statement in the draft: This changes the semantics of a duplicate ACK, these are usually only sent as a signal of a lost segment [9] in regular TCP. Therefore, an MPTCP implementation receiving a duplicate ACK which contains an MPTCP option MUST NOT treat it as a signal of congestion. Additionally, an MPTCP implementation SHOULD NOT send more than two duplicate ACKs in a row for signaling purposes, so as to ensure no middleboxes misinterpret this as a sign of congestion. An MPTCP connection is likely going to be sending DSS option, Data ACK = or Data ACK+DSS option in almost all packets. There is also sufficient = discussion in the draft that indicate that one or more SACK block can = fit in along with MPTCP options for most of the lower length DSS option = variants. Indicating that one can send loss information along with MPTCP = options. But the above statement seemed to indicate that an MPTCP = implementation receiving SACK in a packet along with MPTCP options must = not treat it as a signal of congestion? Even if SACK was not negotiated, = then the above statement indicates that Duplicate ACK should be sent as = a separate segment not tied with a packet containing MPTCP options. = There seems to be a contradiction between the above statement and say = the section that discussed comibining SACK with MPTCP "Appendix A. Notes = on use of TCP Options"? =20 Or is the draft saying that one must treat the ACK field in a segment = with MPTCP options not as a Duplicate ACK unless it contains SACK? I = guess not. SACK should only complement Duplicate ACKs for indicating = packet loss. Also, why would an implementation send more than two = duplicate ACKs in a row unless it received two out of order packets in a = row?=20 =20 Anumita. =20 On Aug 20, 2012, at 7:45 AM, "Hampel, K Georg (K Georg)" = wrote: > Quite honestly, I think we are getting lost in details. There is very = little implementation and real-world experience with MPTCP. The simplest = possible implementation sends ONE DSS per packet and does NO buffering = of payload-w/o-mapping or mappings-w/o-payload and it may in fact = provide proper operation in the vast majority of use cases. Exceptions = should be based on real-world trials rather than speculation. >=20 > I agree with Christoph that on sender side, DSS should have priority = over SACK blocks. >=20 > Georg >=20 >=20 > -----Original Message----- > From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 > Sent: Wednesday, August 01, 2012 8:45 AM > To: Anumita Biswas > Cc: Alan Ford (alanford); Hampel, K Georg (K Georg); = multipathtcp@ietf.org; Mahesh M; Ilpo J=E4rvinen > Subject: Re: [multipathtcp] Number of DSS to store >=20 > Hi Anumita & Alan, >=20 > On Tuesday 31 July 2012 21:44:35 Anumita Biswas wrote: >> A DSS option may not be sent with corresponding data if there isn't = enough >> tcp option space available such as due to the presence of SACK = blocks. >=20 > Then the number of SACK-blocks could get reduced for the packet that = needs to=20 > hold the DSS-option, or the SACK-blocks can be on a separate = subflow-ack. >=20 > SACK-blocks don't necessarily need to be sent reliably. However, the = DSS- > option has to be sent reliably. That's why it is good to couple it = together=20 > with the data as delivery is thus guaranteed. >=20 >=20 > Alan, in your slides yesterday you said: > "A mapping for subflow seqno x MUST not be=20 > sent before the mappings for subflow seqno=20 > 0 .. x-1 have been sent." >=20 > This will still force receivers to be able to store an uncertain = number of=20 > DSS-mappings. >=20 > I believe we should say: > "A mapping, covering the subflow seqno's x to y MUST be sent on one of = these=20 > segments." >=20 > That way the receiver only has to store one single DSS-mapping option = per=20 > subflow. >=20 >=20 > Cheers, > Christoph >=20 > --=20 > IP Networking Lab --- http://inl.info.ucl.ac.be > MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be > Universit=E9 Catholique de Louvain > -- --Boundary_(ID_lBtjTNAkh+fzkZ6BbSh8FQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable This changes the semantics of a duplicate ACK, these are usually only sent as a signal of a lost segment [9] in regular TCP. Therefore, an MPTCP implementation receiving a duplicate ACK which contains an MPTCP option MUST NOT treat it as a signal of congestion. Additionally, an MPTCP implementation SHOULD NOT send more than two duplicate ACKs in a row for signaling purposes, so as to ensure no middleboxes misinterpret this as a sign of = congestion.

An MPTCP connection is likely = going to be sending DSS option, Data ACK or Data ACK+DSS option in = almost all packets. There is also sufficient discussion in the draft = that indicate that one or more SACK block can fit in along with MPTCP = options for most of the lower length DSS option variants. Indicating = that one can send loss information along with MPTCP options.  But = the above statement seemed to indicate that an MPTCP implementation = receiving SACK in a packet along with MPTCP options must not treat it as = a signal of congestion? Even if SACK was not negotiated, then the above = statement indicates that Duplicate ACK should be sent as a separate = segment not tied with a packet containing MPTCP options. There seems to = be a contradiction between the above statement and say the section that = discussed comibining SACK with MPTCP "Appendix A. = Notes on use of TCP Options"?  

Or = is the draft saying that one must treat the ACK field in a segment with = MPTCP options not as a Duplicate ACK unless it contains SACK? I guess = not. SACK should only complement Duplicate ACKs for indicating packet = loss. Also, why would an implementation send more than two duplicate = ACKs in a row unless it received two out of order packets in a = row? 
 
Anumita.
 
=


On Aug 20, 2012, at 7:45 AM, "Hampel, = K Georg (K Georg)" <georg.hampel@alcatel-lucen= t.com> wrote:

Quite = honestly, I think we are getting lost in details. There is very little = implementation and real-world experience with MPTCP. The simplest = possible implementation sends ONE DSS per packet and does NO buffering = of payload-w/o-mapping or mappings-w/o-payload and it may in fact = provide proper operation in the vast majority of use cases. Exceptions = should be based on real-world trials rather than speculation.

I = agree with Christoph that on sender side, DSS should have priority over = SACK blocks.

Georg


-----Original Message-----
From: = Christoph Paasch [mailto:christoph.paasch@uclouvain.be]
Sent: Wednesday, = August 01, 2012 8:45 AM
To: Anumita Biswas
Cc: Alan Ford = (alanford); Hampel, K Georg (K Georg); multipathtcp@ietf.org; Mahesh = M; Ilpo J=E4rvinen
Subject: Re: [multipathtcp] Number of DSS to = store

Hi Anumita & Alan,

On Tuesday 31 July 2012 = 21:44:35 Anumita Biswas wrote:
A DSS option = may not be sent with corresponding data if there isn't =  enough
tcp option space available such as due to the presence = of SACK blocks.

Then the number of SACK-blocks could = get reduced for the packet that needs to
hold the DSS-option, or the = SACK-blocks can be on a separate subflow-ack.

SACK-blocks don't = necessarily need to be sent reliably. However, the DSS-
option has to = be sent reliably. That's why it is good to couple it together
with = the data as delivery is thus guaranteed.


Alan, in your slides = yesterday you said:
"A mapping for subflow seqno x MUST not be =
sent before the mappings for subflow seqno
0 .. x-1 have been = sent."

This will still force receivers to be able to store an = uncertain number of
DSS-mappings.

I believe we should = say:
"A mapping, covering the subflow seqno's x to y MUST be sent on = one of these
segments."

That way the receiver only has to = store one single DSS-mapping option per =
subflow.


Cheers,
Christoph

--
IP Networking = Lab --- http://inl.info.ucl.ac.be
MultiP= ath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
Un= iversit=E9 Catholique de = Louvain
--

= --Boundary_(ID_lBtjTNAkh+fzkZ6BbSh8FQ)-- From olivier.bonaventure@uclouvain.be Mon Aug 27 11:57:46 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D721F84D3 for ; Mon, 27 Aug 2012 11:57:46 -0700 (PDT) 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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0RcZ-v8dvGC for ; Mon, 27 Aug 2012 11:57:46 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id B39C421F84CF for ; Mon, 27 Aug 2012 11:57:45 -0700 (PDT) Received: from mbpobo.local (host-85-27-91-91.brutele.be [85.27.91.91]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 848EC11EB13; Mon, 27 Aug 2012 20:57:35 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 848EC11EB13 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1346093855; bh=Beuu1Iaii/Y10DbORE/kg9gjrHZjVCrGbYi7KMSjG74=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oIxY4aBm05a7AOPW+zkxgdyZ+RTvbQtJ/dTZk7S5wnDygXT5i2+0pigSIrte15gCH OOhcVULnlQv/C2ZSRIA/Fg4vbPYCIMip/YOg3+be/W3bFgEqOrR2B/3TmB2I1HAvpb yuA3dk7R6EL7ovgtYm2LcVbZ561+2zXGI7oWJFiM= Message-ID: <503BC31E.2030805@uclouvain.be> Date: Mon, 27 Aug 2012 20:57:34 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Anumita Biswas References: <66708DC5-FC75-4865-A361-4D407E248415@apple.com> <1494798.q17lBF49r3@cpaasch-mac> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 848EC11EB13.A448D X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , Mahesh M , =?ISO-8859-1?Q?Ilpo_J=E4rvinen?= Subject: Re: [multipathtcp] Number of DSS to store X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:57:46 -0000 Anumita, > Continuing on the topic of SACK and on Duplicate ACKs in general; > > Seeking clarification on this statement in the draft: > > This changes > the semantics of a duplicate ACK, these are usually only sent as a > signal of a lost segment [9] in regular TCP. Therefore, an MPTCP > implementation receiving a duplicate ACK which contains an MPTCP > option MUST NOT treat it as a signal of congestion. Additionally, an > MPTCP implementation SHOULD NOT send more than two duplicate ACKs in > a row for signaling purposes, so as to ensure no middleboxes > misinterpret this as a sign of congestion. In this paragraph, "signaling purposes" means a duplicate ACK that is only used to convey signalling information, ie. add address or remove address. During the data transfert, a duplicate ACK can contain the following options : - DSS - MP_PRIO - ADD_ADDR - REMOVE_ADDR A packet should only contain one DSS option but an MPTCP sender could need to send several MP_PRIO, ADD_ADDR and REMOVE_ADDR. The paragraph above was written to convey the idea that a duplicate ACK containing these options should not trigger a congestion response. It seems that it is a bit vague. Would the following be clearer ? "This changes the semantics of a duplicate ACK, these are usually only sent as a signal of a lost segment [9] in regular TCP. Therefore, an MPTCP implementation receiving a duplicate ACK which contains the MP_PRIO, ADD_ADDR or REMOVE_ADDR MPTCP option MUST NOT treat it as a signal of congestion. Additionally, an MPTCP implementation SHOULD NOT send more than two duplicate ACKs in a row containing any of these three options, so as to ensure no middleboxes misinterpret this as a sign of congestion." > An MPTCP connection is likely going to be sending DSS option, Data ACK > or Data ACK+DSS option in almost all packets. There is also sufficient > discussion in the draft that indicate that one or more SACK block can > fit in along with MPTCP options for most of the lower length DSS option > variants. Indicating that one can send loss information along with MPTCP > options. But the above statement seemed to indicate that an MPTCP > implementation receiving SACK in a packet along with MPTCP options must > not treat it as a signal of congestion? Even if SACK was not negotiated, > then the above statement indicates that Duplicate ACK should be sent as > a separate segment not tied with a packet containing MPTCP options. > There seems to be a contradiction between the above statement and say > the section that discussed comibining SACK with MPTCP "Appendix A. Notes > on use of TCP Options"? > > Or is the draft saying that one must treat the ACK field in a segment > with MPTCP options not as a Duplicate ACK unless it contains SACK? I > guess not. SACK should only complement Duplicate ACKs for indicating > packet loss. Also, why would an implementation send more than two > duplicate ACKs in a row unless it received two out of order packets in a > row? given the maximum length of the TCP options, when there are many SACKs to report, an MPTCP implementation will have to chose between sending SACKS and sending DSS/timestamp. Experimentation on the Internet is needed to provide better implementation guidance in this case. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From anumita_biswas@apple.com Mon Aug 27 13:56:04 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4E721F8545 for ; Mon, 27 Aug 2012 13:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtsyOJHfH5Ie for ; Mon, 27 Aug 2012 13:56:04 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 06FD721F856D for ; Mon, 27 Aug 2012 13:56:04 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fhmt9x90fGh5uI6QH4U10Q)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M9F00LARM3FIN70@mail-out.apple.com> for multipathtcp@ietf.org; Mon, 27 Aug 2012 13:56:03 -0700 (PDT) X-AuditID: 11807136-b7f6b6d00000741d-8b-503bdee2ea01 Received: from panthera-tigris.apple.com (panthera-tigris.apple.com [17.193.13.99]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 84.0B.29725.3EEDB305; Mon, 27 Aug 2012 13:56:03 -0700 (PDT) From: Anumita Biswas In-reply-to: <503BC31E.2030805@uclouvain.be> Date: Mon, 27 Aug 2012 13:56:02 -0700 Message-id: <54C31AF6-3216-458D-BC61-F2B102DE3DB2@apple.com> References: <66708DC5-FC75-4865-A361-4D407E248415@apple.com> <1494798.q17lBF49r3@cpaasch-mac> <503BC31E.2030805@uclouvain.be> To: Olivier.Bonaventure@uclouvain.be X-Mailer: Apple Mail (2.1472) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUieJA3WffxPesAgyffmC1erxG32D7jPJtF 288J7BafV19ns7jR8IPFgdWj9dleVo/XkycwevSv3M/usWTJTyaPV8e+swSwRnHZpKTmZJal FunbJXBlHGm/ylTQZVbxeO8t9gbGTt0uRk4OCQETicnP97JD2GISF+6tZ+ti5OIQEljJJPH8 4x2wBLNAgkTnuz5GEJtXQE9i3ss/YLawgJHEkhPPwWw2AX2Jo49uMIPYnAI6Epu7W1hAbBYB VYlz5xYzgQxlFrjGKHGtdRPUIBuJPV/2s0BsW8Ak8fnDIlaQhIiAisTkvufMECfJShxYf5t5 AiPfLCSHzEJyCERcW2LZwtfMELaexMumd+yY4roSF9dNYlzAyLaKUbAoNSex0tBUL7GgICdV Lzk/dxMjKMgbCs12MO74K3eIUYCDUYmH98d26wAh1sSy4srcQ4wSHMxKIrzXNgGFeFMSK6tS i/Lji0pzUosPMUpzsCiJ8/6+DZQSSE8sSc1OTS1ILYLJMnFwSjUwNrS9W7x/8g5Ne8P7sj+k pWa9Lri13yLmpsSyfd/3KOx+0CWRtuuXRuhyJaNfH86sERHLmK30hlNnyaS/801uvntTk+o8 5a+qC8PS40s/+rGxTemqzmTTuOP/dNFm9qMeWq4LYu7FK+zSTbSs+j1roeXv3QXx+sIFdavP H+d8Ks7jLrx2koBOsRJLcUaioRZzUXEiADdCglpuAgAA Cc: "multipathtcp@ietf.org" , Mahesh M , =?iso-8859-1?Q?Ilpo_J=E4rvinen?= Subject: Re: [multipathtcp] Number of DSS to store X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 20:56:04 -0000 --Boundary_(ID_fhmt9x90fGh5uI6QH4U10Q) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Olivier, On Aug 27, 2012, at 11:57 AM, Olivier Bonaventure wrote: > Anumita, > >> Continuing on the topic of SACK and on Duplicate ACKs in general; >> >> Seeking clarification on this statement in the draft: >> >> This changes >> the semantics of a duplicate ACK, these are usually only sent as a >> signal of a lost segment [9] in regular TCP. Therefore, an MPTCP >> implementation receiving a duplicate ACK which contains an MPTCP >> option MUST NOT treat it as a signal of congestion. Additionally, an >> MPTCP implementation SHOULD NOT send more than two duplicate ACKs in >> a row for signaling purposes, so as to ensure no middleboxes >> misinterpret this as a sign of congestion. > > In this paragraph, "signaling purposes" means a duplicate ACK that is > only used to convey signalling information, ie. add address or remove > address. > > During the data transfert, a duplicate ACK can contain the following > options : > > - DSS > - MP_PRIO > - ADD_ADDR > - REMOVE_ADDR > > A packet should only contain one DSS option but an MPTCP sender could > need to send several MP_PRIO, ADD_ADDR and REMOVE_ADDR. The paragraph > above was written to convey the idea that a duplicate ACK containing > these options should not trigger a congestion response. It seems that it > is a bit vague. > > Would the following be clearer ? > > "This changes the semantics of a duplicate ACK, these are usually only > sent as a signal of a lost segment [9] in regular TCP. Therefore, an > MPTCP implementation receiving a duplicate ACK which contains the > MP_PRIO, ADD_ADDR or REMOVE_ADDR MPTCP option MUST NOT treat it as a > signal of congestion. Additionally, an MPTCP implementation SHOULD NOT > send more than two duplicate ACKs in a row containing any of these three > options, so as to ensure no middleboxes misinterpret this as a sign of > congestion." Yes it is clearer. Thanks for the background also. Based on your comments, I went over the ADD_ADDR section also and found this: As discussed earlier, however, an MPTCP implementation MUST NOT treat duplicate ACKs with any MPTCP option, with the exception of the DSS option, as indications of congestion [9], and an MPTCP implementation SHOULD NOT send more than two duplicate ACKs in a row for signaling purposes. So the statement you have or perhaps even the above same statement can be placed in the more prominent location of Section 3. That way, MP_PRIO is not lost in the discussion. I am assuming that MP_FAIL and MP_FASTCLOSE do not count as they signal termination. > > > Olivier > > -- > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be --Boundary_(ID_fhmt9x90fGh5uI6QH4U10Q) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Olivier.Bonaventure@uclou= vain.be> wrote:
Anumita,

Continuing on = the topic of SACK and on Duplicate ACKs in general;

Seeking = clarification on this statement in the draft:

This changes
=   the semantics of a duplicate ACK, these are usually only = sent as a
  signal of a lost segment [9] in regular TCP. =  Therefore, an MPTCP
  implementation receiving a = duplicate ACK which contains an MPTCP
  option MUST NOT = treat it as a signal of congestion.  Additionally, an
=   MPTCP implementation SHOULD NOT send more than two duplicate = ACKs in
  a row for signaling purposes, so as to ensure no = middleboxes
  misinterpret this as a sign of = congestion.

In this paragraph, "signaling purposes" = means a duplicate ACK that is
only used to convey signalling = information, ie. add address or remove
address.

During the = data transfert, a duplicate ACK can contain the following
options = :

- DSS
- MP_PRIO
- ADD_ADDR
- REMOVE_ADDR

A = packet should only contain one DSS option but an MPTCP sender = could
need to send several MP_PRIO, ADD_ADDR and REMOVE_ADDR. The = paragraph
above was written to convey the idea that a duplicate ACK = containing
these options should not trigger a congestion response. It = seems that it
is a bit vague.

Would the following be clearer = ?

"This changes the semantics of a duplicate ACK, these are = usually only
sent as a signal of a lost segment [9] in regular TCP. =  Therefore, an
MPTCP implementation receiving a duplicate ACK = which contains the
MP_PRIO, ADD_ADDR or REMOVE_ADDR MPTCP option MUST = NOT treat it as a
signal of congestion.  Additionally, an MPTCP = implementation SHOULD NOT
send more than two duplicate ACKs in a row = containing any of these three
options, so as to ensure no middleboxes = misinterpret this as a sign = of
congestion."

Yes it is = clearer. 

Thanks for the background = also. Based on your comments, I went over the ADD_ADDR section also = and found this:
As discussed earlier, =
however, an MPTCP
   implementation MUST NOT treat duplicate ACKs with any MPTCP option,
   with the exception of the DSS option, as indications of congestion
   [9], and an MPTCP implementation SHOULD NOT send more than two
   duplicate ACKs in a row for signaling =
purposes.

So the statement you have or = perhaps even the above same statement can be placed in the more = prominent location of Section 3. That way, MP_PRIO is not lost in the = discussion.
I am assuming that MP_FAIL and MP_FASTCLOSE do not = count as they signal termination.  



Olivier

--
INL, ICTEAM, UCLouvain, Belgium, = http://inl.info.ucl.ac.be

= --Boundary_(ID_fhmt9x90fGh5uI6QH4U10Q)--