From ilpo.jarvinen@helsinki.fi Sat Jun 30 12:01:38 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 01B1021F86A3 for ; Sat, 30 Jun 2012 12:01:38 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 74mcAgTRBXbf for ; Sat, 30 Jun 2012 12:01:36 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8260921F8683 for ; Sat, 30 Jun 2012 12:01:26 -0700 (PDT) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sat, 30 Jun 2012 22:01:25 +0300 id 0008C5F6.4FEF4D05.000059DF Date: Sat, 30 Jun 2012 22:01:25 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: "Alan Ford (alanford)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="8323329-221348273-1341080635=:31476" Content-ID: X-Mailman-Approved-At: Sun, 01 Jul 2012 12:24:00 -0700 Cc: Mahesh M , "multipathtcp@ietf.org" 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: Sat, 30 Jun 2012 19:01:38 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-221348273-1341080635=:31476 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: On Sat, 30 Jun 2012, Alan Ford (alanford) wrote: > I see. Well, as the draft is written at the moment there is no restriction > on you sending all mapping upfront. Furthermore, there is no restriction on > the mapping having to fit within the advertised window. So you could, in > theory, send the mapping for your whole sendfile() upfront. I don't know if > existing implementations would have a problem with that, though. MPTCP is > not really intended to be used in this way, however, since doing this > defeats the point of responding to congestion signals – dynamically > readjusting which data are sent on which subflow according to > congestion/throughput. > > I don't know if implementors have a view on this, and whether we need to > restrict anything in this are? I can understand his question pretty well... having been there myself and wondered exactly the same thing and being surprised how unhelpful the mptcp docs were about this (I was doing a review of the Linux implementation back then). It's crucial for the receiver side implementation to know if the DSS stuff points to the current segment or not, ie., whether the sender can send arbitary mapping or no (even though it certainly doesn't make much sense), and in what order to expect them. ...My implementor point-of-view conclusion was back then summarized (in private discussions) in these points: "In summary, I think the docs should specify these two requirements with MUST (but I might be willing to negotitate on the second point if some good enough point is raised against it): 1) Mapping for subflow seqno x MUST not be sent before the mappings for subflow seqno 0 .. x-1 are/have been sent. 2) A mapping MUST appear, at latest, in the segment where is the first byte it covers is." ...The second point turned out to be impossible to guarantee at the receiving end because of middlebox behavior but I'd still "SHOULD be send, at latest," that in the docs to bound how far middleboxes could take it even when they try hard. In order to push data from subflow upwards one needs to locate the relevant mapping(s) which is the reason for the above wishlist, monotonicity in particular would be pretty helpful from implementation pov. -- i. --8323329-221348273-1341080635=:31476-- From christoph.paasch@uclouvain.be Mon Jul 2 01:29:12 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 A512F21F8AE7 for ; Mon, 2 Jul 2012 01:29:12 -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 VkUXoDmyF9zB for ; Mon, 2 Jul 2012 01:29:12 -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 B9D5421F8AD9 for ; Mon, 2 Jul 2012 01:29:11 -0700 (PDT) Received: from cpaasch-mac.localnet (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.43]) (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 B186B11E97F; Mon, 2 Jul 2012 10:29:09 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be B186B11E97F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1341217749; bh=CU0JYzMXM8dRv0eLs9V2Z7xUxYwlaBs9ELcGtd/+4D8=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=x7f3Ou3qczFIaxAoOZrXC35zehmwjHjUkU6zKhO+xHVtSi44A2IdDEs6SSP3zeOn0 8iXwQhnJQS9a8oZBOKmTYRABC2C1JurpG+QFyRa09VWTQzN3egLWT0sL9vJluoGWIm 4BYGptf4vqpiJYpzS76fqd8NRqMcmcSXx125DDOk= From: Christoph Paasch To: multipathtcp@ietf.org Date: Mon, 02 Jul 2012 10:29:05 +0200 Message-ID: <1838286.4eNqeAoOCE@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-26-mptcp; KDE/4.8.4; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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: B186B11E97F.A142C X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: Ilpo =?ISO-8859-1?Q?J=E4rvinen?= , Mahesh M 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: Mon, 02 Jul 2012 08:29:12 -0000 Hello, I agree with Ilpo that this should be simplified. The DSS-options should be sent on the segments whose mapping they are=20= covering. Thus, if a DSS-mapping goes from x -> y in the subflow-seqno space, the= DSS- option MUST be on one of these segments. Actually, that's what we currently do in our implementation because it = would=20 become very difficult to handle if mappings can come at any point. If t= he=20 segment's seqno is not part of the mapping, I reset the subflow. Cheers, Christoph On Saturday 30 June 2012 22:01:25 Ilpo J=C3=A4rvinen wrote: > On Sat, 30 Jun 2012, Alan Ford (alanford) wrote: > > I see. Well, as the draft is written at the moment there is no rest= riction > > on you sending all mapping upfront. Furthermore, there is no restri= ction > > on > > the mapping having to fit within the advertised window. So you coul= d, in > > theory, send the mapping for your whole sendfile() upfront. I don't= know > > if > > existing implementations would have a problem with that, though. MP= TCP is > > not really intended to be used in this way, however, since doing th= is > > defeats the point of responding to congestion signals =E2=80=93 dyn= amically > > readjusting which data are sent on which subflow according to > > congestion/throughput. > >=20 > > I don't know if implementors have a view on this, and whether we ne= ed to > > restrict anything in this are? >=20 > I can understand his question pretty well... having been there myself= and > wondered exactly the same thing and being surprised how unhelpful the= > mptcp docs were about this (I was doing a review of the Linux > implementation back then). It's crucial for the receiver side > implementation to know if the DSS stuff points to the current segment= or > not, ie., whether the sender can send arbitary mapping or no (even th= ough > it certainly doesn't make much sense), and in what order to expect th= em. >=20 > ...My implementor point-of-view conclusion was back then summarized (= in > private discussions) in these points: >=20 > "In summary, I think the docs should specify these two requirements w= ith > MUST (but I might be willing to negotitate on the second point if som= e > good enough point is raised against it): > 1) Mapping for subflow seqno x MUST not be sent before the mappings f= or > subflow seqno 0 .. x-1 are/have been sent. > 2) A mapping MUST appear, at latest, in the segment where is the firs= t > byte it covers is." >=20 > ...The second point turned out to be impossible to guarantee at the > receiving end because of middlebox behavior but I'd still "SHOULD be > send, at latest," that in the docs to bound how far middleboxes could= > take it even when they try hard. >=20 > In order to push data from subflow upwards one needs to locate the > relevant mapping(s) which is the reason for the above wishlist, > monotonicity in particular would be pretty helpful from implementatio= n > pov. --=20 IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Universit=C3=A9 Catholique de Louvain -- From georg.hampel@alcatel-lucent.com Mon Jul 2 06:55:22 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 10DA221F8620 for ; Mon, 2 Jul 2012 06:55:22 -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 ilhONAvdEOkB for ; Mon, 2 Jul 2012 06:55:21 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id F388821F861C for ; Mon, 2 Jul 2012 06:55:20 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q62DtFPC022790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jul 2012 08:55:15 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q62DtEII006300 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jul 2012 08:55:14 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 2 Jul 2012 08:55:14 -0500 From: "Hampel, K Georg (K Georg)" To: Christoph Paasch , "multipathtcp@ietf.org" Date: Mon, 2 Jul 2012 08:55:12 -0500 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1YLMpg4w05ybnYS324A3ZB8R1YEAAKg29A Message-ID: <154773479ED2314980CB638A48FC4434C49D3E5C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <1838286.4eNqeAoOCE@cpaasch-mac> In-Reply-To: <1838286.4eNqeAoOCE@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: =?iso-8859-1?Q?Ilpo_J=E4rvinen?= , Mahesh M 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, 02 Jul 2012 13:55:22 -0000 All, Mahesh has raised an interesting point. Mahesh's use case also applies to = wireless access environments where only one subflow is active for a long ti= me, e.g. because only one link is up or other links have very low link qual= ity. Currently, MPTCP supports the "bulk optimization" feature, where the DSS sp= ecifies a mapping that applies to future packets. The amount of data mapped= in bulk optimization is limited to the max value that can be carried in th= e 16bit range field, which amounts to ~65kB or ~43 packets Ethernet packets= . This is very small. To better address the above use case, we proposed the "temporary fallback" = feature some time ago. This feature allows MPTCP to fallback to conventiona= l TCP operation on the active subflow, i.e. fixed mapping with no further D= SS exchange, until a "multipath reinstatement" option is sent. I think we should continue working on such a feature given the growing inte= rest and the added benefits to MPTCP. Regards, Georg=20 -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Christoph Paasch Sent: Monday, July 02, 2012 4:29 AM To: multipathtcp@ietf.org Cc: Ilpo J=E4rvinen; Mahesh M Subject: Re: [multipathtcp] Number of DSS to store Hello, I agree with Ilpo that this should be simplified. The DSS-options should be sent on the segments whose mapping they are=20 covering. Thus, if a DSS-mapping goes from x -> y in the subflow-seqno space, the DSS= - option MUST be on one of these segments. Actually, that's what we currently do in our implementation because it woul= d=20 become very difficult to handle if mappings can come at any point. If the=20 segment's seqno is not part of the mapping, I reset the subflow. Cheers, Christoph On Saturday 30 June 2012 22:01:25 Ilpo J=E4rvinen wrote: > On Sat, 30 Jun 2012, Alan Ford (alanford) wrote: > > I see. Well, as the draft is written at the moment there is no restrict= ion > > on you sending all mapping upfront. Furthermore, there is no restrictio= n > > on > > the mapping having to fit within the advertised window. So you could, i= n > > theory, send the mapping for your whole sendfile() upfront. I don't kno= w > > if > > existing implementations would have a problem with that, though. MPTCP = is > > not really intended to be used in this way, however, since doing this > > defeats the point of responding to congestion signals - dynamically > > readjusting which data are sent on which subflow according to > > congestion/throughput. > >=20 > > I don't know if implementors have a view on this, and whether we need t= o > > restrict anything in this are? >=20 > I can understand his question pretty well... having been there myself and > wondered exactly the same thing and being surprised how unhelpful the > mptcp docs were about this (I was doing a review of the Linux > implementation back then). It's crucial for the receiver side > implementation to know if the DSS stuff points to the current segment or > not, ie., whether the sender can send arbitary mapping or no (even though > it certainly doesn't make much sense), and in what order to expect them. >=20 > ...My implementor point-of-view conclusion was back then summarized (in > private discussions) in these points: >=20 > "In summary, I think the docs should specify these two requirements with > MUST (but I might be willing to negotitate on the second point if some > good enough point is raised against it): > 1) Mapping for subflow seqno x MUST not be sent before the mappings for > subflow seqno 0 .. x-1 are/have been sent. > 2) A mapping MUST appear, at latest, in the segment where is the first > byte it covers is." >=20 > ...The second point turned out to be impossible to guarantee at the > receiving end because of middlebox behavior but I'd still "SHOULD be > send, at latest," that in the docs to bound how far middleboxes could > take it even when they try hard. >=20 > In order to push data from subflow upwards one needs to locate the > relevant mapping(s) which is the reason for the above wishlist, > monotonicity in particular would be pretty helpful from implementation > pov. --=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 -- _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From christoph.paasch@uclouvain.be Mon Jul 2 07:13:28 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131D321F859A for ; Mon, 2 Jul 2012 07:13:28 -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 yrDmkgzwc6zO for ; Mon, 2 Jul 2012 07:13:27 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF6721F8557 for ; Mon, 2 Jul 2012 07:13:27 -0700 (PDT) Received: from cpaasch-mac.localnet (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 8665A1C5DAC; Mon, 2 Jul 2012 16:13:26 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 8665A1C5DAC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1341238406; bh=QU7rtYd+f8yC55m9GJLX/xTjFH2ga/+I9V7ClrQvXV8=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=kRkpqCjbUVBXn8WnRNFWfnoA5xXLPWKKP1Agcfo99442ro5HbNQLZdu1I06zfC3PD yT2rgMWh1owRnucMo7kj9iuWXdnfJza6aPPObR8C4vaajshed0vNsYgqUTDJyQ/Rzw jziy8LB0D0b2lNIKRnrnHwToR1nT3jJpkJ8tl8X0= From: Christoph Paasch To: "Hampel, K Georg (K Georg)" Date: Mon, 02 Jul 2012 16:13:26 +0200 Message-ID: <1736381.lRxlcVXdQL@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-26-mptcp; KDE/4.8.4; x86_64; ; ) In-Reply-To: <154773479ED2314980CB638A48FC4434C49D3E5C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <1838286.4eNqeAoOCE@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3E5C@USNAVSXCHMBSA2.ndc.alcatel-lucent.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-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 8665A1C5DAC.A1488 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , Ilpo =?ISO-8859-1?Q?J=E4rvinen?= , Mahesh M 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: Mon, 02 Jul 2012 14:13:28 -0000 Hi Georg, On Monday 02 July 2012 08:55:12 Hampel, K Georg wrote: > To better address the above use case, we proposed the "temporary fall= back" > feature some time ago. This feature allows MPTCP to fallback to > conventional TCP operation on the active subflow, i.e. fixed mapping = with > no further DSS exchange, until a "multipath reinstatement" option is = sent. I remember this discussion. But at the time it was unclear how this can= work=20 across payload-modifying middleboxes. Do you have a solution to this no= w? > I think we should continue working on such a feature given the growin= g > interest and the added benefits to MPTCP. What is the benefit (increased goodput, reduced delay/jitter, ...) of s= ending=20 the DSS-mapping-option separated from the data itself ? In my opinion this just increases the implementation complexity, as we = then=20 need to support receiving many DSS-mappings before receiving the actual= data.=20 And all these DSS-mappings need to be stored somewhere for an unsure am= ount of=20 time... 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 georg.hampel@alcatel-lucent.com Mon Jul 2 07:30:57 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 9973321F8698 for ; Mon, 2 Jul 2012 07:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVzFUtGIaFZ0 for ; Mon, 2 Jul 2012 07:30:56 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 79A7321F854D for ; Mon, 2 Jul 2012 07:30:56 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q62EUcdt013990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jul 2012 09:30:44 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q62EIWa0025187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jul 2012 09:18:42 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 2 Jul 2012 09:09:35 -0500 From: "Hampel, K Georg (K Georg)" To: Christoph Paasch , "multipathtcp@ietf.org" Date: Mon, 2 Jul 2012 09:09:34 -0500 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1YLMpg4w05ybnYS324A3ZB8R1YEAALYYag Message-ID: <154773479ED2314980CB638A48FC4434C49D3E72@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <1838286.4eNqeAoOCE@cpaasch-mac> In-Reply-To: <1838286.4eNqeAoOCE@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: =?iso-8859-1?Q?Ilpo_J=E4rvinen?= , Mahesh M 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, 02 Jul 2012 14:30:57 -0000 Ilpo, Christoph, I'd like to better understand your comments: (1) I think we agree that the DSS mapping for byte x should ideally arrive = not later than byte x itself.=20 (2) We probably also agree that this is not always possible because of midd= le boxes that tear apart TCP options and payload, and delay the option. I don't see why we should prohibit sending mappings preemptively. This woul= d guarantee the availability of mappings when needed, even if they were del= ayed by middle boxes.=20 Obviously, preemptive mappings have to be stored on the receiver side. This= , however, uses very little less space and can be done very efficiently.=20 Am I missing something here? Thanks. Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Christoph Paasch Sent: Monday, July 02, 2012 4:29 AM To: multipathtcp@ietf.org Cc: Ilpo J=E4rvinen; Mahesh M Subject: Re: [multipathtcp] Number of DSS to store Hello, I agree with Ilpo that this should be simplified. The DSS-options should be sent on the segments whose mapping they are=20 covering. Thus, if a DSS-mapping goes from x -> y in the subflow-seqno space, the DSS= - option MUST be on one of these segments. Actually, that's what we currently do in our implementation because it woul= d=20 become very difficult to handle if mappings can come at any point. If the=20 segment's seqno is not part of the mapping, I reset the subflow. Cheers, Christoph On Saturday 30 June 2012 22:01:25 Ilpo J=E4rvinen wrote: > On Sat, 30 Jun 2012, Alan Ford (alanford) wrote: > > I see. Well, as the draft is written at the moment there is no restrict= ion > > on you sending all mapping upfront. Furthermore, there is no restrictio= n > > on > > the mapping having to fit within the advertised window. So you could, i= n > > theory, send the mapping for your whole sendfile() upfront. I don't kno= w > > if > > existing implementations would have a problem with that, though. MPTCP = is > > not really intended to be used in this way, however, since doing this > > defeats the point of responding to congestion signals - dynamically > > readjusting which data are sent on which subflow according to > > congestion/throughput. > >=20 > > I don't know if implementors have a view on this, and whether we need t= o > > restrict anything in this are? >=20 > I can understand his question pretty well... having been there myself and > wondered exactly the same thing and being surprised how unhelpful the > mptcp docs were about this (I was doing a review of the Linux > implementation back then). It's crucial for the receiver side > implementation to know if the DSS stuff points to the current segment or > not, ie., whether the sender can send arbitary mapping or no (even though > it certainly doesn't make much sense), and in what order to expect them. >=20 > ...My implementor point-of-view conclusion was back then summarized (in > private discussions) in these points: >=20 > "In summary, I think the docs should specify these two requirements with > MUST (but I might be willing to negotitate on the second point if some > good enough point is raised against it): > 1) Mapping for subflow seqno x MUST not be sent before the mappings for > subflow seqno 0 .. x-1 are/have been sent. > 2) A mapping MUST appear, at latest, in the segment where is the first > byte it covers is." >=20 > ...The second point turned out to be impossible to guarantee at the > receiving end because of middlebox behavior but I'd still "SHOULD be > send, at latest," that in the docs to bound how far middleboxes could > take it even when they try hard. >=20 > In order to push data from subflow upwards one needs to locate the > relevant mapping(s) which is the reason for the above wishlist, > monotonicity in particular would be pretty helpful from implementation > pov. --=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 -- _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From christoph.paasch@uclouvain.be Mon Jul 2 07:43:08 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 8E69721F853A for ; Mon, 2 Jul 2012 07:43:08 -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 sCCg5lpUHn1v for ; Mon, 2 Jul 2012 07:43:07 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id B808321F8543 for ; Mon, 2 Jul 2012 07:43:07 -0700 (PDT) Received: from cpaasch-mac.localnet (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 145D11C5F10; Mon, 2 Jul 2012 16:43:08 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 145D11C5F10 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1341240188; bh=1F1qeN6twTSN/RMrFuD7842KW2MePGnJYiODxt52D0w=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=h7CSgGhG1VNdG47R+QaNa1JVxA7N3gbCk5Wl3udWCxuncGFwljLceTxc+SytXf9GV QIJT1IsRFTNUg7dSCNJIr4UikvYpDQz4v+2XfkTNOd+o6q8fZizBfCy/yRVT7IE7Dg 7etreQWv0JMM1LtH2wpEveVC7NfFcxNwVRiw//KI= From: Christoph Paasch To: "Hampel, K Georg (K Georg)" Date: Mon, 02 Jul 2012 16:43:07 +0200 Message-ID: <8438987.5NKRMgqcR7@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-26-mptcp; KDE/4.8.4; x86_64; ; ) In-Reply-To: <154773479ED2314980CB638A48FC4434C49D3E72@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <1838286.4eNqeAoOCE@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3E72@USNAVSXCHMBSA2.ndc.alcatel-lucent.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-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 145D11C5F10.A4020 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , Ilpo =?ISO-8859-1?Q?J=E4rvinen?= , Mahesh M 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: Mon, 02 Jul 2012 14:43:08 -0000 On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: > I don't see why we should prohibit sending mappings preemptively. Thi= s would > guarantee the availability of mappings when needed, even if they were= > delayed by middle boxes.=20 The mapping is only needed after all the data has been received belongi= ng to=20 this mapping (we have to wait for all the data, to verify the DSS-csum)= . Thus, a mapping covering bytes x->y should be on any of the bytes betwe= en x=20 and y. > Obviously, preemptive mappings have to be stored on the receiver side= . This, > however, uses very little less space and can be done very efficiently= .=20 The question is, how many of these preemptive mappings do you store? An= d what=20 if you reach the limit of the allowed stored mappings? Probably you sho= uld=20 then drop some of the received mappings. But if you drop them, when the= data=20 comes in you don't know the mapping and have to drop the data. Thus, the data-level retransmission timer has to retransmit the data an= d this=20 will kill the performance. I imagine that these preemptive mappings would be sent on duplicate ack= s. We=20 then have to ensure reliable delivery of these mappings (thus need some= =20 mechanism to acknowledge this), because otherwise again the data-level=20= retransmission timer kicks in and performance drops. I think it's much cleaner if we prohibit preemptive mappings. 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 georg.hampel@alcatel-lucent.com Mon Jul 2 08:10:48 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2402A21F86AB for ; Mon, 2 Jul 2012 08:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WENSHAhoDpfo for ; Mon, 2 Jul 2012 08:10:47 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 56D2221F861E for ; Mon, 2 Jul 2012 08:10:47 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q62FAcpR010441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jul 2012 10:10:41 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q62EkxN4004253 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jul 2012 09:46:59 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Mon, 2 Jul 2012 09:46:58 -0500 From: "Hampel, K Georg (K Georg)" To: Christoph Paasch Date: Mon, 2 Jul 2012 09:46:58 -0500 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1YXPQSXaeQUf5bSm+fNt7Bbf3g7QAAcBVg Message-ID: <154773479ED2314980CB638A48FC4434C49D3EA6@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <1838286.4eNqeAoOCE@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3E5C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <1736381.lRxlcVXdQL@cpaasch-mac> In-Reply-To: <1736381.lRxlcVXdQL@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "multipathtcp@ietf.org" , =?iso-8859-1?Q?Ilpo_J=E4rvinen?= , Mahesh M 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, 02 Jul 2012 15:10:48 -0000 Christoph, all, Yes, temporary fallback can be done. A thorough WG discussion would be appr= eciated. Georg -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Monday, July 02, 2012 10:13 AM To: Hampel, K Georg (K Georg) Cc: multipathtcp@ietf.org; Ilpo J=E4rvinen; Mahesh M Subject: Re: [multipathtcp] Number of DSS to store Hi Georg, On Monday 02 July 2012 08:55:12 Hampel, K Georg wrote: > To better address the above use case, we proposed the "temporary fallback= " > feature some time ago. This feature allows MPTCP to fallback to > conventional TCP operation on the active subflow, i.e. fixed mapping with > no further DSS exchange, until a "multipath reinstatement" option is sent= . I remember this discussion. But at the time it was unclear how this can wor= k=20 across payload-modifying middleboxes. Do you have a solution to this now? > I think we should continue working on such a feature given the growing > interest and the added benefits to MPTCP. What is the benefit (increased goodput, reduced delay/jitter, ...) of sendi= ng=20 the DSS-mapping-option separated from the data itself ? In my opinion this just increases the implementation complexity, as we then= =20 need to support receiving many DSS-mappings before receiving the actual dat= a.=20 And all these DSS-mappings need to be stored somewhere for an unsure amount= of=20 time... 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 georg.hampel@alcatel-lucent.com Mon Jul 2 08:52:29 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 F36ED21F86E3 for ; Mon, 2 Jul 2012 08:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 89Wmsk7-np0l for ; Mon, 2 Jul 2012 08:52:28 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E479321F86D5 for ; Mon, 2 Jul 2012 08:52:27 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q62Focp8008710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jul 2012 10:51:23 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q62FCKO1017482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jul 2012 10:12:20 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 2 Jul 2012 10:12:20 -0500 From: "Hampel, K Georg (K Georg)" To: Christoph Paasch Date: Mon, 2 Jul 2012 10:12:19 -0500 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1YYQKQPD/HsYMWQzitTgQzBJKG6QAAI2sA Message-ID: <154773479ED2314980CB638A48FC4434C49D3EC6@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <1838286.4eNqeAoOCE@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3E72@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <8438987.5NKRMgqcR7@cpaasch-mac> In-Reply-To: <8438987.5NKRMgqcR7@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "multipathtcp@ietf.org" , =?iso-8859-1?Q?Ilpo_J=E4rvinen?= , Mahesh M 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, 02 Jul 2012 15:52:29 -0000 Christoph, I have implemented preemptive mapping. It's trivial.=20 You need only 16B per mapping range: SSN (4B), DSN (8B), range (4B). Note t= hat 16B can cover a large contiguous range! It's NOT 16B per DSS! For severe multipath operation, the sender probably doesn't plan ahead by m= ore than a few mappings. So that's a few times 16B. For single-path operati= on, there is only one mapping range, i.e. only 16B. I implemented the mapping as a list to provide fast insertion/deletion. By = keeping a pointer to the last lookup, you can typically retrieve informatio= n in const time. Insertion is also const time since mostly in back of list.= Same for deletion since the front of list is contiguous, i.e. only the fro= nt entry is affected. DSS should not be sent on separate ACKs since the receiver would consider t= hem as congestion signals. Georg=20 -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Monday, July 02, 2012 10:43 AM To: Hampel, K Georg (K Georg) Cc: multipathtcp@ietf.org; Ilpo J=E4rvinen; Mahesh M Subject: Re: [multipathtcp] Number of DSS to store On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: > I don't see why we should prohibit sending mappings preemptively. This wo= uld > guarantee the availability of mappings when needed, even if they were > delayed by middle boxes.=20 The mapping is only needed after all the data has been received belonging t= o=20 this mapping (we have to wait for all the data, to verify the DSS-csum). Thus, a mapping covering bytes x->y should be on any of the bytes between x= =20 and y. > Obviously, preemptive mappings have to be stored on the receiver side. Th= is, > however, uses very little less space and can be done very efficiently.=20 The question is, how many of these preemptive mappings do you store? And wh= at=20 if you reach the limit of the allowed stored mappings? Probably you should= =20 then drop some of the received mappings. But if you drop them, when the dat= a=20 comes in you don't know the mapping and have to drop the data. Thus, the data-level retransmission timer has to retransmit the data and th= is=20 will kill the performance. I imagine that these preemptive mappings would be sent on duplicate acks. W= e=20 then have to ensure reliable delivery of these mappings (thus need some=20 mechanism to acknowledge this), because otherwise again the data-level=20 retransmission timer kicks in and performance drops. I think it's much cleaner if we prohibit preemptive mappings. 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 Jul 2 11:12:56 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 23ABB21F8716 for ; Mon, 2 Jul 2012 11:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 G6PEVzSCZ3zT for ; Mon, 2 Jul 2012 11:12:55 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id EB4AF21F86E5 for ; Mon, 2 Jul 2012 11:12:54 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from relay16.apple.com ([17.128.113.55]) 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 <0M6J008F3ME8UP92@mail-out.apple.com> for multipathtcp@ietf.org; Mon, 02 Jul 2012 10:12:48 -0700 (PDT) X-AuditID: 11807137-b7f536d000006fcc-4f-4ff1d6902b9b 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 relay16.apple.com (Apple SCV relay) with SMTP id 5C.0F.28620.096D1FF4; Mon, 02 Jul 2012 10:12:48 -0700 (PDT) From: Anumita Biswas In-reply-to: <154773479ED2314980CB638A48FC4434C49D3EC6@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Mon, 02 Jul 2012 10:12:48 -0700 Content-transfer-encoding: quoted-printable Message-id: <0D16B52E-522A-4DA3-AC4D-EDD4DA47A9F8@apple.com> References: <1838286.4eNqeAoOCE@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3E72@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <8438987.5NKRMgqcR7@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3EC6@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> To: "Hampel, K Georg (K Georg)" X-Mailer: Apple Mail (2.1472) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUieJA3WXfCtY/+BofXClpMPTOZxeL1GnGL 7TPOs1m0/ZzAbvF59XU2B1aP1md7WT1eT57A6NG/cj+7x5IlP5k8Xh37zhLAGsVlk5Kak1mW WqRvl8CV8avvHHvBRcWKRTMOsjcwNkl3MXJySAiYSCz+tIkVwhaTuHBvPVsXIxeHkMBKJolj B/YwgSSYBXQkdm69wwZi8wroScx7+YcRxBYWMJJYcuI5mM0moC9x9NENZhCbUyBWYtKT/WBx FgEVid7GgywgQ5kFTjJKrPzVyA4xVFti2cLXzBBDbSTW7rnGCLF5EpNE26k7YAkRAUeJJc2n 2SHOk5U4sP428wRG/llIjpqF5KhZSOYuYGRexShYlJqTWGloppdYUJCTqpecn7uJERS0DYXm Oxi3/5U7xCjAwajEw6t4+4O/EGtiWXFl7iFGCQ5mJRHeuCMf/YV4UxIrq1KL8uOLSnNSiw8x SnOwKInz/qt47S8kkJ5YkpqdmlqQWgSTZeLglGpgzF4w79b1fdsP/We963tQlp99/Z32y665 j/J+L+7dVbw7eP6tt+qHHY4u7uiPN7hcuPCJaonZSu+VftqfvtjKcItk3Ul8+/lR6Aze0OaV 76zbJjiuWff7zK01vYGscWFcLiXhN3k+sK9/dXnr9R7h3DOrcjbyuq491brqTNTPgKt8DJ92 qy/2/K3EUpyRaKjFXFScCABngmzsVgIAAA== Cc: "multipathtcp@ietf.org" , =?iso-8859-1?Q?Ilpo_J=E4rvinen?= , Mahesh M 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, 02 Jul 2012 18:12:56 -0000 One advantage of sending the DSS with the corresponding data or atleast = a chunk of the data is that it is reliably sent. The arrival of the ack = for the data indicates that the receiver received the DSS option also. = Sending DSS options on ACKs should be prohibited as there are no ACKs = for ACKs. What is the use case for sending multiple DSS options each of 64K length = ahead of the data itself in cellular/wifi environments? Even if the bdp = is large enough to hold more than 64K of data, reacting to loss and = falling to an alternate path relies on MPTCP operation to be ON all the = time no? For offloading 64K to a TSO card, one obvious solution seems to be to = send the DSS option on the first non offloaded segment, followed by the = remaining data offloaded to the NIC. Alternately, if the TSO NIC = supports copying the TCP options in all segments of the large packet, = like it would with TCP timestamps, one can imagine offloading the entire = 64K data to the NIC. The receiver should be able to drop/ignore the = duplicate DSS options. =20 On Jul 2, 2012, at 8:12 AM, "Hampel, K Georg (K Georg)" = wrote: > Christoph, >=20 > I have implemented preemptive mapping. It's trivial.=20 >=20 > You need only 16B per mapping range: SSN (4B), DSN (8B), range (4B). = Note that 16B can cover a large contiguous range! It's NOT 16B per DSS! >=20 > For severe multipath operation, the sender probably doesn't plan ahead = by more than a few mappings. So that's a few times 16B. For single-path = operation, there is only one mapping range, i.e. only 16B. >=20 > I implemented the mapping as a list to provide fast = insertion/deletion. By keeping a pointer to the last lookup, you can = typically retrieve information in const time. Insertion is also const = time since mostly in back of list. Same for deletion since the front of = list is contiguous, i.e. only the front entry is affected. >=20 > DSS should not be sent on separate ACKs since the receiver would = consider them as congestion signals. >=20 >=20 > Georg=20 >=20 >=20 > -----Original Message----- > From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 > Sent: Monday, July 02, 2012 10:43 AM > To: Hampel, K Georg (K Georg) > Cc: multipathtcp@ietf.org; Ilpo J=E4rvinen; Mahesh M > Subject: Re: [multipathtcp] Number of DSS to store >=20 > On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: >> I don't see why we should prohibit sending mappings preemptively. = This would >> guarantee the availability of mappings when needed, even if they were >> delayed by middle boxes.=20 >=20 > The mapping is only needed after all the data has been received = belonging to=20 > this mapping (we have to wait for all the data, to verify the = DSS-csum). >=20 > Thus, a mapping covering bytes x->y should be on any of the bytes = between x=20 > and y. >=20 >> Obviously, preemptive mappings have to be stored on the receiver = side. This, >> however, uses very little less space and can be done very = efficiently.=20 >=20 > The question is, how many of these preemptive mappings do you store? = And what=20 > if you reach the limit of the allowed stored mappings? Probably you = should=20 > then drop some of the received mappings. But if you drop them, when = the data=20 > comes in you don't know the mapping and have to drop the data. > Thus, the data-level retransmission timer has to retransmit the data = and this=20 > will kill the performance. >=20 > I imagine that these preemptive mappings would be sent on duplicate = acks. We=20 > then have to ensure reliable delivery of these mappings (thus need = some=20 > mechanism to acknowledge this), because otherwise again the data-level=20= > retransmission timer kicks in and performance drops. >=20 >=20 > I think it's much cleaner if we prohibit preemptive mappings. >=20 >=20 > 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 > -- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From christoph.paasch@uclouvain.be Mon Jul 2 11:39:01 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FCC11E811B for ; Mon, 2 Jul 2012 11:39:01 -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 cjwGhc7SSAp3 for ; Mon, 2 Jul 2012 11:39:01 -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 BD76111E8112 for ; Mon, 2 Jul 2012 11:39:00 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [109.89.218.177]) (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 E5BEA11EBDB; Mon, 2 Jul 2012 20:39:01 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be E5BEA11EBDB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1341254341; bh=5ZjrtMC/s8v5SWqru6xCQezl4mko3skvI8K5VSffasE=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=nq4JeXEH+8I/WIMXJa5oa4LnMz5sVRSLDjd3ja/p0hwsx+QwslwP9QyQFrRLJngR/ SAhIiTCCjP86xb6nfChgI8d77yEgJzauf4Vqppvb6D7w564spwxMok/IhNV3VfbUVG V8CwaUdcHda2rnpISQXtDkWCq/nDfjMQ052D7FRk= From: Christoph Paasch To: "Hampel, K Georg (K Georg)" Date: Mon, 02 Jul 2012 20:39:01 +0200 Message-ID: <1552145.na4SViNQ9l@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-26-mptcp; KDE/4.8.4; x86_64; ; ) In-Reply-To: <154773479ED2314980CB638A48FC4434C49D3EC6@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <8438987.5NKRMgqcR7@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3EC6@USNAVSXCHMBSA2.ndc.alcatel-lucent.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: E5BEA11EBDB.A2DF3 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , Ilpo =?ISO-8859-1?Q?J=E4rvinen?= , Mahesh M 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: Mon, 02 Jul 2012 18:39:01 -0000 Georg, but still, what is the benefit of preemptive mapping in terms of goodpu= t,=20 delay, robustness,... ? All these little "features" just increase MPTCP's complexity and thus m= ake it=20 harder for other operating systems to implement it. Thus, decreasing MP= TCP's=20 chance of widespread deployment. In my opinion, unless there is a real benefit, we should keep MPTCP as = simple=20 as possible. Cheers, Christoph On Monday 02 July 2012 10:12:19 Hampel, K Georg wrote: > Christoph, >=20 > I have implemented preemptive mapping. It's trivial. >=20 > You need only 16B per mapping range: SSN (4B), DSN (8B), range (4B). = Note > that 16B can cover a large contiguous range! It's NOT 16B per DSS! >=20 > For severe multipath operation, the sender probably doesn't plan ahea= d by > more than a few mappings. So that's a few times 16B. For single-path > operation, there is only one mapping range, i.e. only 16B. >=20 > I implemented the mapping as a list to provide fast insertion/deletio= n. By > keeping a pointer to the last lookup, you can typically retrieve > information in const time. Insertion is also const time since mostly = in > back of list. Same for deletion since the front of list is contiguous= , i.e. > only the front entry is affected. >=20 > DSS should not be sent on separate ACKs since the receiver would cons= ider > them as congestion signals. >=20 >=20 > Georg >=20 >=20 > -----Original Message----- > From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be] > Sent: Monday, July 02, 2012 10:43 AM > To: Hampel, K Georg (K Georg) > Cc: multipathtcp@ietf.org; Ilpo J=E4rvinen; Mahesh M > Subject: Re: [multipathtcp] Number of DSS to store >=20 > On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: > > I don't see why we should prohibit sending mappings preemptively. T= his > > would guarantee the availability of mappings when needed, even if t= hey > > were delayed by middle boxes. >=20 > The mapping is only needed after all the data has been received belon= ging to > this mapping (we have to wait for all the data, to verify the DSS-csu= m). >=20 > Thus, a mapping covering bytes x->y should be on any of the bytes bet= ween x > and y. >=20 > > Obviously, preemptive mappings have to be stored on the receiver si= de. > > This, however, uses very little less space and can be done very > > efficiently. > The question is, how many of these preemptive mappings do you store? = And > what if you reach the limit of the allowed stored mappings? Probably = you > should then drop some of the received mappings. But if you drop them,= when > the data comes in you don't know the mapping and have to drop the dat= a. > Thus, the data-level retransmission timer has to retransmit the data = and > this will kill the performance. >=20 > I imagine that these preemptive mappings would be sent on duplicate a= cks. We > then have to ensure reliable delivery of these mappings (thus need so= me > mechanism to acknowledge this), because otherwise again the data-leve= l > retransmission timer kicks in and performance drops. >=20 >=20 > I think it's much cleaner if we prohibit preemptive mappings. >=20 >=20 > 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 Mahesh.M@citrix.com Mon Jul 2 12:13:19 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 19DA921F859E for ; Mon, 2 Jul 2012 12:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.631 X-Spam-Level: X-Spam-Status: No, score=-9.631 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLN3gOWN7lMC for ; Mon, 2 Jul 2012 12:13:18 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by ietfa.amsl.com (Postfix) with ESMTP id 340DA21F858F for ; Mon, 2 Jul 2012 12:13:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,512,1336363200"; d="scan'208";a="30178470" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Jul 2012 15:13:22 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Mon, 2 Jul 2012 12:13:21 -0700 From: Mahesh M To: Christoph Paasch , "Hampel, K Georg (K Georg)" Date: Mon, 2 Jul 2012 12:13:20 -0700 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1Ygfe2atYdbpRRQpGbXYWoselaMgABGKBA Message-ID: <6E004C34C1C59E45A35B4338808BC31501300E3FB18F@SJCPMAILBOX01.citrite.net> References: <8438987.5NKRMgqcR7@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3EC6@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <1552145.na4SViNQ9l@cpaasch-mac> In-Reply-To: <1552145.na4SViNQ9l@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" , =?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, 02 Jul 2012 19:13:19 -0000 If we don't allow preemptive mappings and making MUST to send mappings onl= y along with first data segment belonging to the mapping is a good idea. It= is simple and works in all the cases. Regards, Mahesh -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Monday, July 02, 2012 11:39 AM To: Hampel, K Georg (K Georg) Cc: multipathtcp@ietf.org; Ilpo J=E4rvinen; Mahesh M Subject: Re: [multipathtcp] Number of DSS to store Georg, but still, what is the benefit of preemptive mapping in terms of goodput, d= elay, robustness,... ? All these little "features" just increase MPTCP's complexity and thus make = it harder for other operating systems to implement it. Thus, decreasing MPT= CP's chance of widespread deployment. In my opinion, unless there is a real benefit, we should keep MPTCP as simp= le as possible. Cheers, Christoph On Monday 02 July 2012 10:12:19 Hampel, K Georg wrote: > Christoph, >=20 > I have implemented preemptive mapping. It's trivial. >=20 > You need only 16B per mapping range: SSN (4B), DSN (8B), range (4B). Note > that 16B can cover a large contiguous range! It's NOT 16B per DSS! >=20 > For severe multipath operation, the sender probably doesn't plan ahead by > more than a few mappings. So that's a few times 16B. For single-path > operation, there is only one mapping range, i.e. only 16B. >=20 > I implemented the mapping as a list to provide fast insertion/deletion. B= y > keeping a pointer to the last lookup, you can typically retrieve > information in const time. Insertion is also const time since mostly in > back of list. Same for deletion since the front of list is contiguous, i.= e. > only the front entry is affected. >=20 > DSS should not be sent on separate ACKs since the receiver would consider > them as congestion signals. >=20 >=20 > Georg >=20 >=20 > -----Original Message----- > From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be] > Sent: Monday, July 02, 2012 10:43 AM > To: Hampel, K Georg (K Georg) > Cc: multipathtcp@ietf.org; Ilpo J=E4rvinen; Mahesh M > Subject: Re: [multipathtcp] Number of DSS to store >=20 > On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: > > I don't see why we should prohibit sending mappings preemptively. This > > would guarantee the availability of mappings when needed, even if they > > were delayed by middle boxes. >=20 > The mapping is only needed after all the data has been received belonging= to > this mapping (we have to wait for all the data, to verify the DSS-csum). >=20 > Thus, a mapping covering bytes x->y should be on any of the bytes between= x > and y. >=20 > > Obviously, preemptive mappings have to be stored on the receiver side. > > This, however, uses very little less space and can be done very > > efficiently. > The question is, how many of these preemptive mappings do you store? And > what if you reach the limit of the allowed stored mappings? Probably you > should then drop some of the received mappings. But if you drop them, whe= n > the data comes in you don't know the mapping and have to drop the data. > Thus, the data-level retransmission timer has to retransmit the data and > this will kill the performance. >=20 > I imagine that these preemptive mappings would be sent on duplicate acks.= We > then have to ensure reliable delivery of these mappings (thus need some > mechanism to acknowledge this), because otherwise again the data-level > retransmission timer kicks in and performance drops. >=20 >=20 > I think it's much cleaner if we prohibit preemptive mappings. >=20 >=20 > 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 Mon Jul 2 12:22:10 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3215D11E80DE for ; Mon, 2 Jul 2012 12:22:10 -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 NWWxV0oifGJq for ; Mon, 2 Jul 2012 12:22:09 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 86E5F11E80C4 for ; Mon, 2 Jul 2012 12:22:09 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [109.89.218.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E60BB1C5DAA; Mon, 2 Jul 2012 21:22:10 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be E60BB1C5DAA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1341256930; bh=9u105fKNnKA6znLKDIeHlJhH83cbdHJu/uADP+9I/i8=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=zsv2II95D+i5a7WksUuL+BA4h5hFNX0eVgF9XeRuulysJ+mzdM8xlx1znnbJSnx0P ArRCVIjYOtAxwnLX4iA8eOMnA4ETSn/iwAUAmEE6+9Rh+SImdF/uTR31ghMsALoDzn b7ERct52F6H0szVLg4vaOS7qNKxpUboDXwKuuqzs= From: Christoph Paasch To: Mahesh M Date: Mon, 02 Jul 2012 21:22:10 +0200 Message-ID: <1541491.9qWncQmH1U@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-26-mptcp; KDE/4.8.4; x86_64; ; ) In-Reply-To: <6E004C34C1C59E45A35B4338808BC31501300E3FB18F@SJCPMAILBOX01.citrite.net> References: <1552145.na4SViNQ9l@cpaasch-mac> <6E004C34C1C59E45A35B4338808BC31501300E3FB18F@SJCPMAILBOX01.citrite.net> 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-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: E60BB1C5DAA.A19E9 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , 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: Mon, 02 Jul 2012 19:22:10 -0000 On Monday 02 July 2012 12:13:20 Mahesh M wrote: > If we don't allow preemptive mappings and making MUST to send mappin= gs only > along with first data segment belonging to the mapping is a good idea= . It > is simple and works in all the cases. Guarantee that it will be on the first data-segment is not possible due= to=20 segment-splitting middleboxes who might copy the TCP-option only on the= second=20 packet. But this is not a huge problem. In our implementation we just store the segments without mapping in the= =20 subflow-receive-queue until all segments of the mapping have arrived to= gether=20 with the required DSS-option. The DSS-mapping is temporarily stored in = the=20 TCP-sock. No need to dynamically allocate 16B (actually it would be 32B as this i= s the=20 minimal allocation-size) and store them in a list and thus potentially = have=20 additional cache-misses and burn more CPU-cycles. 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 Mahesh.M@citrix.com Mon Jul 2 12:53: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 8264E11E80B3 for ; Mon, 2 Jul 2012 12:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=-2.639, BAYES_00=-2.599, 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 uVbUkOwHB3Mg for ; Mon, 2 Jul 2012 12:53:58 -0700 (PDT) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by ietfa.amsl.com (Postfix) with ESMTP id B2B7A11E8083 for ; Mon, 2 Jul 2012 12:53:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,512,1336363200"; d="scan'208";a="200804048" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Jul 2012 15:54:03 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Mon, 2 Jul 2012 12:54:02 -0700 From: Mahesh M To: Christoph Paasch Date: Mon, 2 Jul 2012 12:54:01 -0700 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1YiBiPq4nz/cKNTzKyMFUSpWcwPwABDqBw Message-ID: <6E004C34C1C59E45A35B4338808BC31501300E3FB1A1@SJCPMAILBOX01.citrite.net> References: <1552145.na4SViNQ9l@cpaasch-mac> <6E004C34C1C59E45A35B4338808BC31501300E3FB18F@SJCPMAILBOX01.citrite.net> <1541491.9qWncQmH1U@cpaasch-mac> In-Reply-To: <1541491.9qWncQmH1U@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" , =?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, 02 Jul 2012 19:53:59 -0000 Guarantee that it will be on the first data-segment is not possible due to = segment-splitting middleboxes who might copy the TCP-option only on the sec= ond packet. Mahesh> Is there an example of this? Which proxy does this? Regards, Mahesh -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Monday, July 02, 2012 12:22 PM To: Mahesh M Cc: Hampel, K Georg (K Georg); multipathtcp@ietf.org; Ilpo J=E4rvinen Subject: Re: [multipathtcp] Number of DSS to store On Monday 02 July 2012 12:13:20 Mahesh M wrote: > If we don't allow preemptive mappings and making MUST to send=20 > mappings only along with first data segment belonging to the mapping=20 > is a good idea. It is simple and works in all the cases. Guarantee that it will be on the first data-segment is not possible due to = segment-splitting middleboxes who might copy the TCP-option only on the sec= ond packet. But this is not a huge problem. In our implementation we just store the segments without mapping in the sub= flow-receive-queue until all segments of the mapping have arrived together = with the required DSS-option. The DSS-mapping is temporarily stored in the = TCP-sock. No need to dynamically allocate 16B (actually it would be 32B as this is th= e minimal allocation-size) and store them in a list and thus potentially ha= ve additional cache-misses and burn more CPU-cycles. Christoph -- 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 Mon Jul 2 12:59:00 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8F411E80B3 for ; Mon, 2 Jul 2012 12:59:00 -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 GzkmJ4-c5vng for ; Mon, 2 Jul 2012 12:59:00 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1477C11E8083 for ; Mon, 2 Jul 2012 12:59:00 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [109.89.218.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E04D51C5F9C; Mon, 2 Jul 2012 21:59:01 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be E04D51C5F9C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1341259141; bh=lARiZypz9sHHs1wVRTHIztdD2MfR6XlmdaaMRy5RbhY=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=lf+VNcMzlchMtKKeWZO+VQ4MLYXJgmkc+xQ17RFdULSw7gqvfBJwq6oq07TAQZ+8P 2hLRnX2Nhfymsnmkoeg2Om4WVUyMY0ukRSueYdIhqSynh2fY0Arixj29RvqhMZb4nh MPHbVKVLCvIVe3rI/TxPGBudLnU+GO7Yk/lpqXCU= From: Christoph Paasch To: Mahesh M Date: Mon, 02 Jul 2012 21:59:01 +0200 Message-ID: <2680516.vueP1rtV4N@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-26-mptcp; KDE/4.8.4; x86_64; ; ) In-Reply-To: <6E004C34C1C59E45A35B4338808BC31501300E3FB1A1@SJCPMAILBOX01.citrite.net> References: <1541491.9qWncQmH1U@cpaasch-mac> <6E004C34C1C59E45A35B4338808BC31501300E3FB1A1@SJCPMAILBOX01.citrite.net> 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-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: E04D51C5F9C.A0C97 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , 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: Mon, 02 Jul 2012 19:59:00 -0000 On Monday 02 July 2012 12:54:01 Mahesh M wrote: >> Guarantee that it will be on the first data-segment is not possible = due to >> segment-splitting middleboxes who might copy the TCP-option only on = the >> second packet.=20 > Mahesh> Is there an example of this? Which proxy does this? Actually, I don't know of an example of such kind of middlebox. In Michio's paper "Is it still possible to extend TCP?" they did not fo= und=20 such kind of a middlebox. However, their sample-size is limited and who knows if there exists suc= h kind=20 of a (maybe buggy) middlebox somewhere on the Internet. MPTCP should also pass by such kind of a middlebox. 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 georg.hampel@alcatel-lucent.com Mon Jul 2 13:21:00 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7728211E80A5 for ; Mon, 2 Jul 2012 13:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.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 c0o2XPbzxmvM for ; Mon, 2 Jul 2012 13:20:59 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D655A11E8080 for ; Mon, 2 Jul 2012 13:20:58 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q62KKpBs001467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jul 2012 15:20:52 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q62KKpkk020562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jul 2012 15:20:51 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 2 Jul 2012 15:20:51 -0500 From: "Hampel, K Georg (K Georg)" To: Christoph Paasch , Mahesh M Date: Mon, 2 Jul 2012 15:20:50 -0500 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1Yh/+bA+bM+s+nTduspWfUSELGiAABwlGw Message-ID: <154773479ED2314980CB638A48FC4434C49D4060@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <1552145.na4SViNQ9l@cpaasch-mac> <6E004C34C1C59E45A35B4338808BC31501300E3FB18F@SJCPMAILBOX01.citrite.net> <1541491.9qWncQmH1U@cpaasch-mac> In-Reply-To: <1541491.9qWncQmH1U@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "multipathtcp@ietf.org" , =?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, 02 Jul 2012 20:21:00 -0000 For our packet-filter proxy implementation DSS delay is a huge problem sinc= e we don't buffer packets but only Seq No mappings. If the mapping is not a= vailable when the packet arrives the packet has to be dropped.=20 The mapping may cost us 16B but we save 1500B for every packet that's cover= ed by this mapping. We ran our implementation on LTE carriers and big ISPs in the US and didn't= account any problem. This means that segment-splitting middleboxes don't s= eem to be that frequent. I also wonder if payload-rewriting middleboxes really exist... Georg =20 -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Monday, July 02, 2012 3:22 PM To: Mahesh M Cc: Hampel, K Georg (K Georg); multipathtcp@ietf.org; Ilpo J=E4rvinen Subject: Re: [multipathtcp] Number of DSS to store On Monday 02 July 2012 12:13:20 Mahesh M wrote: > If we don't allow preemptive mappings and making MUST to send mappings o= nly > along with first data segment belonging to the mapping is a good idea. It > is simple and works in all the cases. Guarantee that it will be on the first data-segment is not possible due to= =20 segment-splitting middleboxes who might copy the TCP-option only on the sec= ond=20 packet. But this is not a huge problem. In our implementation we just store the segments without mapping in the=20 subflow-receive-queue until all segments of the mapping have arrived togeth= er=20 with the required DSS-option. The DSS-mapping is temporarily stored in the= =20 TCP-sock. No need to dynamically allocate 16B (actually it would be 32B as this is th= e=20 minimal allocation-size) and store them in a list and thus potentially have= =20 additional cache-misses and burn more CPU-cycles. 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 georg.hampel@alcatel-lucent.com Mon Jul 2 13:31:19 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 BB94711E8083 for ; Mon, 2 Jul 2012 13:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq8DHtgTSuKh for ; Mon, 2 Jul 2012 13:31:18 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BCD3111E80E7 for ; Mon, 2 Jul 2012 13:31:18 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q62KVBNG004892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jul 2012 15:31:12 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q62KV8HP027866 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jul 2012 15:31:11 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 2 Jul 2012 15:31:08 -0500 From: "Hampel, K Georg (K Georg)" To: Christoph Paasch Date: Mon, 2 Jul 2012 15:31:06 -0500 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1Ygf9oZ8MOlRT1SX+/2ERjk1AXmAADjYvw Message-ID: <154773479ED2314980CB638A48FC4434C49D4067@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <8438987.5NKRMgqcR7@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3EC6@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <1552145.na4SViNQ9l@cpaasch-mac> In-Reply-To: <1552145.na4SViNQ9l@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "multipathtcp@ietf.org" , =?iso-8859-1?Q?Ilpo_J=E4rvinen?= , Mahesh M 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, 02 Jul 2012 20:31:19 -0000 Christoph, For packet-filter implementations bulk optimization and temporary fall back= can leverage hardware acceleration or other forms of local processing sinc= e only IPs, ports, Seq No and Ack No have to be rewritten. This is a huge benefit for MPTCP proxies which are instrumental to MPTCP's = deployment. Georg -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Monday, July 02, 2012 2:39 PM To: Hampel, K Georg (K Georg) Cc: multipathtcp@ietf.org; Ilpo J=E4rvinen; Mahesh M Subject: Re: [multipathtcp] Number of DSS to store Georg, but still, what is the benefit of preemptive mapping in terms of goodput,=20 delay, robustness,... ? All these little "features" just increase MPTCP's complexity and thus make = it=20 harder for other operating systems to implement it. Thus, decreasing MPTCP'= s=20 chance of widespread deployment. In my opinion, unless there is a real benefit, we should keep MPTCP as simp= le=20 as possible. Cheers, Christoph On Monday 02 July 2012 10:12:19 Hampel, K Georg wrote: > Christoph, >=20 > I have implemented preemptive mapping. It's trivial. >=20 > You need only 16B per mapping range: SSN (4B), DSN (8B), range (4B). Note > that 16B can cover a large contiguous range! It's NOT 16B per DSS! >=20 > For severe multipath operation, the sender probably doesn't plan ahead by > more than a few mappings. So that's a few times 16B. For single-path > operation, there is only one mapping range, i.e. only 16B. >=20 > I implemented the mapping as a list to provide fast insertion/deletion. B= y > keeping a pointer to the last lookup, you can typically retrieve > information in const time. Insertion is also const time since mostly in > back of list. Same for deletion since the front of list is contiguous, i.= e. > only the front entry is affected. >=20 > DSS should not be sent on separate ACKs since the receiver would consider > them as congestion signals. >=20 >=20 > Georg >=20 >=20 > -----Original Message----- > From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be] > Sent: Monday, July 02, 2012 10:43 AM > To: Hampel, K Georg (K Georg) > Cc: multipathtcp@ietf.org; Ilpo J=E4rvinen; Mahesh M > Subject: Re: [multipathtcp] Number of DSS to store >=20 > On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: > > I don't see why we should prohibit sending mappings preemptively. This > > would guarantee the availability of mappings when needed, even if they > > were delayed by middle boxes. >=20 > The mapping is only needed after all the data has been received belonging= to > this mapping (we have to wait for all the data, to verify the DSS-csum). >=20 > Thus, a mapping covering bytes x->y should be on any of the bytes between= x > and y. >=20 > > Obviously, preemptive mappings have to be stored on the receiver side. > > This, however, uses very little less space and can be done very > > efficiently. > The question is, how many of these preemptive mappings do you store? And > what if you reach the limit of the allowed stored mappings? Probably you > should then drop some of the received mappings. But if you drop them, whe= n > the data comes in you don't know the mapping and have to drop the data. > Thus, the data-level retransmission timer has to retransmit the data and > this will kill the performance. >=20 > I imagine that these preemptive mappings would be sent on duplicate acks.= We > then have to ensure reliable delivery of these mappings (thus need some > mechanism to acknowledge this), because otherwise again the data-level > retransmission timer kicks in and performance drops. >=20 >=20 > I think it's much cleaner if we prohibit preemptive mappings. >=20 >=20 > 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 Mon Jul 2 13:37:47 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 5076C21F8455 for ; Mon, 2 Jul 2012 13:37:47 -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 t9U9qm4FI269 for ; Mon, 2 Jul 2012 13:37:42 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6387C21F861A for ; Mon, 2 Jul 2012 13:37:42 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [109.89.218.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E0AE41C5773; Mon, 2 Jul 2012 22:37:43 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be E0AE41C5773 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1341261463; bh=td7CgKPMfiSr9pGDt0OvJDo9z/V7bTRT7NozGIg1veU=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=Yy8xGuJTf+dUWO87dr4Om7WHhDsw1Ee+GTBjrwf+Cw16V3gSxaXd729jhe8smhYJL /zati0ashyioeowoeXezwaCzbk0j6j+oT0qXrkR6F1Bd/x34vWYfTVPa1nYscKmTMo nbMOZ6IbXCvuDGLnD3PfPSb1gRwsc6AdWvXvOR7w= From: Christoph Paasch To: "Hampel, K Georg (K Georg)" Date: Mon, 02 Jul 2012 22:37:43 +0200 Message-ID: <6072409.rDibRJRay4@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-26-mptcp; KDE/4.8.4; x86_64; ; ) In-Reply-To: <154773479ED2314980CB638A48FC4434C49D4060@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <1541491.9qWncQmH1U@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D4060@USNAVSXCHMBSA2.ndc.alcatel-lucent.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-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: E0AE41C5773.AECAD X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: Mahesh M , "multipathtcp@ietf.org" , 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: Mon, 02 Jul 2012 20:37:47 -0000 On Monday 02 July 2012 15:20:50 Hampel, K Georg wrote: > We ran our implementation on LTE carriers and big ISPs in the US and = didn't > account any problem. This means that segment-splitting middleboxes do= n't > seem to be that frequent. If they are not so frequent, putting the DSS-option on the first packet= that=20 is covered by the mapping should be sufficient for you. No need to send= them=20 preemptively. > I also wonder if payload-rewriting middleboxes really exist... FTP across NAT. The Linux Kernel implementation does modify IP-addresse= s if=20 FTP is used across NAT, and the ftp-helper module is loaded in the kern= el. I took a quick look at the source-code and it does not seem to me that = they=20 remove TCP-options. Thus, MPTCP needs to deal with this. 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 nishida@sfc.wide.ad.jp Wed Jul 4 03:18: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 5167C21F870F for ; Wed, 4 Jul 2012 03:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.509 X-Spam-Level: X-Spam-Status: No, score=-101.509 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrxTFWUeYeuv for ; Wed, 4 Jul 2012 03:18:14 -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 5182621F86EA for ; Wed, 4 Jul 2012 03:18:14 -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 F25582780B7 for ; Wed, 4 Jul 2012 19:18:21 +0900 (JST) Received: by lbbgo11 with SMTP id go11so11193313lbb.31 for ; Wed, 04 Jul 2012 03:18:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.84.168 with SMTP id a8mr9702723lbz.92.1341397099220; Wed, 04 Jul 2012 03:18:19 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Wed, 4 Jul 2012 03:18:19 -0700 (PDT) In-Reply-To: <8438987.5NKRMgqcR7@cpaasch-mac> References: <1838286.4eNqeAoOCE@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3E72@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <8438987.5NKRMgqcR7@cpaasch-mac> Date: Wed, 4 Jul 2012 03:18:19 -0700 Message-ID: From: Yoshifumi Nishida To: Christoph Paasch Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 04 Jul 2012 10:18:15 -0000 Hi, On Mon, Jul 2, 2012 at 7:43 AM, Christoph Paasch wrote: > On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: >> I don't see why we should prohibit sending mappings preemptively. This would >> guarantee the availability of mappings when needed, even if they were >> delayed by middle boxes. > > The mapping is only needed after all the data has been received belonging to > this mapping (we have to wait for all the data, to verify the DSS-csum). > > Thus, a mapping covering bytes x->y should be on any of the bytes between x > and y. > >> Obviously, preemptive mappings have to be stored on the receiver side. This, >> however, uses very little less space and can be done very efficiently. > > The question is, how many of these preemptive mappings do you store? And what > if you reach the limit of the allowed stored mappings? Probably you should > then drop some of the received mappings. But if you drop them, when the data > comes in you don't know the mapping and have to drop the data. > Thus, the data-level retransmission timer has to retransmit the data and this > will kill the performance. Hmm. I have a naive question.. Let's say we send 100 packets and each packet has DSS option which covers its own payload. Now, if we lost every other packets before they arrived at the receiver, I guess we'll need to maintain 50 mappings. So, I'm thinking that even if we prohibit preemptive mappings, there might be a situation we have to keep rather complex mappings.. Is this OK? Thanks, -- Yoshifumi From ilpo.jarvinen@helsinki.fi Wed Jul 4 03:39:45 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 7768421F87DE for ; Wed, 4 Jul 2012 03:39:45 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 DVMfkeoe+XmZ for ; Wed, 4 Jul 2012 03:39:45 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAB821F87D7 for ; Wed, 4 Jul 2012 03:39:43 -0700 (PDT) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 04 Jul 2012 13:39:52 +0300 id 0008C294.4FF41D78.0000463D Date: Wed, 4 Jul 2012 13:39:52 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Yoshifumi Nishida In-Reply-To: Message-ID: References: <1838286.4eNqeAoOCE@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3E72@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <8438987.5NKRMgqcR7@cpaasch-mac> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 04 Jul 2012 03:41:19 -0700 Cc: "multipathtcp@ietf.org" , Mahesh M 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: Wed, 04 Jul 2012 10:39:45 -0000 On Wed, 4 Jul 2012, Yoshifumi Nishida wrote: > On Mon, Jul 2, 2012 at 7:43 AM, Christoph Paasch > wrote: > > On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: > >> I don't see why we should prohibit sending mappings preemptively. This would > >> guarantee the availability of mappings when needed, even if they were > >> delayed by middle boxes. > > > > The mapping is only needed after all the data has been received belonging to > > this mapping (we have to wait for all the data, to verify the DSS-csum). > > > > Thus, a mapping covering bytes x->y should be on any of the bytes between x > > and y. > > > >> Obviously, preemptive mappings have to be stored on the receiver side. This, > >> however, uses very little less space and can be done very efficiently. > > > > The question is, how many of these preemptive mappings do you store? And what > > if you reach the limit of the allowed stored mappings? Probably you should > > then drop some of the received mappings. But if you drop them, when the data > > comes in you don't know the mapping and have to drop the data. > > Thus, the data-level retransmission timer has to retransmit the data and this > > will kill the performance. > > Hmm. I have a naive question.. > Let's say we send 100 packets and each packet has DSS option which > covers its own payload. > Now, if we lost every other packets before they arrived at the > receiver, I guess we'll need to maintain 50 mappings. So, I'm thinking > that even if we prohibit preemptive mappings, there might be a > situation we have to keep rather complex mappings.. Is this OK? It's not about storing those mappings until needed but having to do that independently of the actual payload. ...It depends on implementation detail of course, but I can easily see that the mapping could reside where the actual payload is until the payload itself is consumed and the mapping, if not pointing to some random place, will be needed at that point too and can be immediately discarded once used. But then if there's no payload to associate it with (either consumed already or not even arrived yet) you need start building other structures and do all kinds of extra "simple" operations such as allocate that space, maintain lists, do the memory accounting, and whatever... -- i. From krishna.khanal2@citrix.com Wed Jul 4 04:23:05 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 9860521F8508 for ; Wed, 4 Jul 2012 04:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] 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 aJkPHmfZj0Ej for ; Wed, 4 Jul 2012 04:23:04 -0700 (PDT) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4683321F8462 for ; Wed, 4 Jul 2012 04:23:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,522,1336348800"; d="scan'208";a="11941495" Received: from banpmailmx01.citrite.net ([10.103.128.73]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5; 04 Jul 2012 11:23:12 +0000 Received: from BANPMAILBOX01.citrite.net ([10.103.128.71]) by BANPMAILMX01.citrite.net ([10.103.128.73]) with mapi; Wed, 4 Jul 2012 16:53:11 +0530 From: Krishna Khanal To: Yoshifumi Nishida , Christoph Paasch Date: Wed, 4 Jul 2012 16:53:10 +0530 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1ZzmSTPKqISvTtTLSyAvfzIdED2QABknDw Message-ID: <4FCA39B99132DA4EA70BE3CE408C193D010DD180F0EF@BANPMAILBOX01.citrite.net> References: <1838286.4eNqeAoOCE@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D3E72@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <8438987.5NKRMgqcR7@cpaasch-mac> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" , 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: Wed, 04 Jul 2012 11:23:05 -0000 Yoshifumi, I think this should not be a problem as long as you are handling out-of-or= der packets at subflow level. When every other packets are lost, this creat= es the out-of-order at the subflow level and you should not pass those pack= ets to mptcp connection. This means you will always have a single map for a= subflow or if the map is only for the payload carried by that packet, you = don't have to store anything. Regards, Krishna -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Yoshifumi Nishida Sent: Wednesday, July 04, 2012 3:48 PM To: Christoph Paasch Cc: multipathtcp@ietf.org; Mahesh M; Ilpo J=E4rvinen Subject: Re: [multipathtcp] Number of DSS to store Hi, On Mon, Jul 2, 2012 at 7:43 AM, Christoph Paasch wrote: > On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: >> I don't see why we should prohibit sending mappings preemptively. This w= ould >> guarantee the availability of mappings when needed, even if they were >> delayed by middle boxes. > > The mapping is only needed after all the data has been received belonging= to > this mapping (we have to wait for all the data, to verify the DSS-csum). > > Thus, a mapping covering bytes x->y should be on any of the bytes between= x > and y. > >> Obviously, preemptive mappings have to be stored on the receiver side. T= his, >> however, uses very little less space and can be done very efficiently. > > The question is, how many of these preemptive mappings do you store? And = what > if you reach the limit of the allowed stored mappings? Probably you shoul= d > then drop some of the received mappings. But if you drop them, when the d= ata > comes in you don't know the mapping and have to drop the data. > Thus, the data-level retransmission timer has to retransmit the data and = this > will kill the performance. Hmm. I have a naive question.. Let's say we send 100 packets and each packet has DSS option which covers its own payload. Now, if we lost every other packets before they arrived at the receiver, I guess we'll need to maintain 50 mappings. So, I'm thinking that even if we prohibit preemptive mappings, there might be a situation we have to keep rather complex mappings.. Is this OK? Thanks, -- Yoshifumi _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From christoph.paasch@uclouvain.be Wed Jul 4 04:57: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 5B91E21F871D for ; Wed, 4 Jul 2012 04:57:43 -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 kg81uYVKLxAp for ; Wed, 4 Jul 2012 04:57:42 -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 214F421F8753 for ; Wed, 4 Jul 2012 04:57:41 -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 AF47911EBFA; Wed, 4 Jul 2012 13:57:47 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be AF47911EBFA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1341403067; bh=Vd33jXJJKbJin8hE30x/i1KvHYr3l6WxaQVNNcx0jhs=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=el6Gfci+4klBt/EZa/5iK0at8LiTCprjP9adrqa/MILxU+scrW3ibBXSM30uYz1EO /E/6O1D4f9zxLxeVPRbzjB6ImRicQGwhPkXn9/XQiq3Jg0vqTQPN7lZ7ZDBsdhsBsK USWB0Ha7sW320N2FCUVlWKF0ByI/UnuzyCEWq5Ek= From: Christoph Paasch To: Yoshifumi Nishida Date: Wed, 04 Jul 2012 13:57:34 +0200 Message-ID: <2228022.C3KFSO16Cc@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-26-mptcp; KDE/4.8.4; x86_64; ; ) In-Reply-To: References: <8438987.5NKRMgqcR7@cpaasch-mac> 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: AF47911EBFA.A235F 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, 04 Jul 2012 11:57:43 -0000 Hello, just to confirm what Ilpo & Krishna said: Our implementation does store segments in the subflow-out-of-order queu= e if=20 there has been loss on the subflow. And then, when the segment becomes in-order at the subflow-level and we= can=20 push it one level higher to the meta-socket we read the DSS out of the=20= segment's TCP-option space. (for those who like to read code:=20 http://goo.gl/WM7I7 - this is the place where we make the layer-switch = from=20 subflow to meta-socket and read the DSS-option out of the segment) Cheers, Christoph On Wednesday 04 July 2012 03:18:19 Yoshifumi Nishida wrote: > Hi, >=20 > On Mon, Jul 2, 2012 at 7:43 AM, Christoph Paasch >=20 > wrote: > > On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: > >> I don't see why we should prohibit sending mappings preemptively. = This > >> would guarantee the availability of mappings when needed, even if = they > >> were delayed by middle boxes. > >=20 > > The mapping is only needed after all the data has been received bel= onging > > to this mapping (we have to wait for all the data, to verify the > > DSS-csum). > >=20 > > Thus, a mapping covering bytes x->y should be on any of the bytes b= etween > > x > > and y. > >=20 > >> Obviously, preemptive mappings have to be stored on the receiver s= ide. > >> This, however, uses very little less space and can be done very > >> efficiently.>=20 > > The question is, how many of these preemptive mappings do you store= ? And > > what if you reach the limit of the allowed stored mappings? Probabl= y you > > should then drop some of the received mappings. But if you drop the= m, > > when the data comes in you don't know the mapping and have to drop = the > > data. > > Thus, the data-level retransmission timer has to retransmit the dat= a and > > this will kill the performance. >=20 > Hmm. I have a naive question.. > Let's say we send 100 packets and each packet has DSS option which > covers its own payload. > Now, if we lost every other packets before they arrived at the > receiver, I guess we'll need to maintain 50 mappings. So, I'm thinkin= g > that even if we prohibit preemptive mappings, there might be a > situation we have to keep rather complex mappings.. Is this OK? >=20 > Thanks, > -- > Yoshifumi --=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 Wed Jul 4 07:06:12 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 7BD0121F882D for ; Wed, 4 Jul 2012 07:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 AVxYyH327img for ; Wed, 4 Jul 2012 07:06:11 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id A441D21F8829 for ; Wed, 4 Jul 2012 07:06:11 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from relay17.apple.com ([17.128.113.18]) 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 <0M6N00G4K35OIE51@mail-out.apple.com> for multipathtcp@ietf.org; Wed, 04 Jul 2012 07:06:15 -0700 (PDT) X-AuditID: 11807112-b7f826d000004103-28-4ff44dd6152d 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 relay17.apple.com (Apple SCV relay) with SMTP id D0.66.16643.7DD44FF4; Wed, 04 Jul 2012 07:06:15 -0700 (PDT) From: Anumita Biswas In-reply-to: <2228022.C3KFSO16Cc@cpaasch-mac> Date: Wed, 04 Jul 2012 07:06:14 -0700 Content-transfer-encoding: quoted-printable Message-id: <5F3EC5C2-BE97-4FF6-B34B-B838D86BCAC6@apple.com> References: <8438987.5NKRMgqcR7@cpaasch-mac> <2228022.C3KFSO16Cc@cpaasch-mac> To: Christoph Paasch X-Mailer: Apple Mail (2.1472) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUieJA3Wfe67xd/g/7jjBZTz0xmsdg+4zyb RdvPCewWn1dfZ7PYuOQGmwOrx+vJExg9+lfuZ/dYsuQnk8fF19eZPV4d+84SwBrFZZOSmpNZ llqkb5fAlbF3h2LBDumKPa+mszQw/hbtYuTkkBAwkdg37TULhC0mceHeejYQW0hgJZPEhrmh IDazgI7Ezq13wOK8AnoS817+YQSxhQWMJJaceA5mswnoSxx9dIMZxOYU0JW4fOkTmM0ioCIx 6dgMoF4uoDmHGSW+zT3ACjFUW2LZwtfMEENtJG48WcUMsXgro8TiV94gtgjQcZeWHWGDOE5W 4sD628wTGPlnIblpFpKbZiEZu4CReRWjYFFqTmKlobleYkFBTqpecn7uJkZQwDYUCu1gvL9L 7xCjAAejEg9vosJnfyHWxLLiytxDjBIczEoivB3KX/yFeFMSK6tSi/Lji0pzUosPMUpzsCiJ 827yAUoJpCeWpGanphakFsFkmTg4pRoY9aMcP1ab7rnkeVwm+ULJzzmf2O7nmbFunnG0zp3D fuM3wf3XVeOfJBfINAbyizLcnndBSZ1ffEVUUVrQJA7jOd/tVt1rd12//n1z0Bz91itHWuxT 9+9/0/eJt3ih66aKhOomUY6pbUw/V98Q/JOepM52vZzNz18542v+k1nzepb63VTsaZugxFKc kWioxVxUnAgAdNB+11QCAAA= 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: Wed, 04 Jul 2012 14:06:12 -0000 In Yoshifumi's example, if all the dropped packets belonged to one = subflow, and all the other packets belonged to another sub flow, the = MPTCP receiver would receive out of order data at the MPTCP level and = would either have to retain the tcp options in each packet even after = the packet reaches the MPTCP level or store the mappings in an auxiliary = data structure. If such striping isn't used across multiple subflows, then very little = state needs to be stored at the receiver. But a robust receiver = implementation should be prepared to handle out of order data and = mappings at the MPTCP level. Anumita. =20 On Jul 4, 2012, at 4:57 AM, Christoph Paasch = wrote: > Hello, >=20 > just to confirm what Ilpo & Krishna said: >=20 > Our implementation does store segments in the subflow-out-of-order = queue if=20 > there has been loss on the subflow. >=20 > And then, when the segment becomes in-order at the subflow-level and = we can=20 > push it one level higher to the meta-socket we read the DSS out of the=20= > segment's TCP-option space. (for those who like to read code:=20 > http://goo.gl/WM7I7 - this is the place where we make the layer-switch = from=20 > subflow to meta-socket and read the DSS-option out of the segment) >=20 >=20 > Cheers, > Christoph >=20 >=20 > On Wednesday 04 July 2012 03:18:19 Yoshifumi Nishida wrote: >> Hi, >>=20 >> On Mon, Jul 2, 2012 at 7:43 AM, Christoph Paasch >>=20 >> wrote: >>> On Monday 02 July 2012 09:09:34 Hampel, K Georg wrote: >>>> I don't see why we should prohibit sending mappings preemptively. = This >>>> would guarantee the availability of mappings when needed, even if = they >>>> were delayed by middle boxes. >>>=20 >>> The mapping is only needed after all the data has been received = belonging >>> to this mapping (we have to wait for all the data, to verify the >>> DSS-csum). >>>=20 >>> Thus, a mapping covering bytes x->y should be on any of the bytes = between >>> x >>> and y. >>>=20 >>>> Obviously, preemptive mappings have to be stored on the receiver = side. >>>> This, however, uses very little less space and can be done very >>>> efficiently.>=20 >>> The question is, how many of these preemptive mappings do you store? = And >>> what if you reach the limit of the allowed stored mappings? Probably = you >>> should then drop some of the received mappings. But if you drop = them, >>> when the data comes in you don't know the mapping and have to drop = the >>> data. >>> Thus, the data-level retransmission timer has to retransmit the data = and >>> this will kill the performance. >>=20 >> Hmm. I have a naive question.. >> Let's say we send 100 packets and each packet has DSS option which >> covers its own payload. >> Now, if we lost every other packets before they arrived at the >> receiver, I guess we'll need to maintain 50 mappings. So, I'm = thinking >> that even if we prohibit preemptive mappings, there might be a >> situation we have to keep rather complex mappings.. Is this OK? >>=20 >> Thanks, >> -- >> Yoshifumi > --=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 > -- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From christoph.paasch@uclouvain.be Wed Jul 4 07:23:44 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 9E58721F8749 for ; Wed, 4 Jul 2012 07:23:44 -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 Oym0L4GT4s1o for ; Wed, 4 Jul 2012 07:23:43 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id B816E21F873A for ; Wed, 4 Jul 2012 07:23:43 -0700 (PDT) Received: from cpaasch-mac.localnet (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6F55F1C5DDE; Wed, 4 Jul 2012 16:23:49 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 6F55F1C5DDE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1341411829; bh=+7zcfsTq9Jah19wh+vBvmWq/GVGHfYsZ7RVEJwD5KvQ=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=Ku8Wbos8fODGdvUs24B+DLCL/5O1WgNO3/4kKP7+oc4Ldkll8ZvrstISevlEaSsa6 Kb+deWyfBz/CRxeCVNO7aMB18zOuZvJKCpQEHGQ6nOdHMRJ3Dl7YlpQOUXEUqxARyO noRaSlSLsffn+YPwp8F9GetIZOODJapxRNIyw2+0= From: Christoph Paasch To: Anumita Biswas Date: Wed, 04 Jul 2012 16:23:49 +0200 Message-ID: <4176028.9GEuC7cy4F@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-26-mptcp; KDE/4.8.4; x86_64; ; ) In-Reply-To: <5F3EC5C2-BE97-4FF6-B34B-B838D86BCAC6@apple.com> References: <2228022.C3KFSO16Cc@cpaasch-mac> <5F3EC5C2-BE97-4FF6-B34B-B838D86BCAC6@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-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6F55F1C5DDE.A212E 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, 04 Jul 2012 14:23:44 -0000 On Wednesday 04 July 2012 07:06:14 Anumita Biswas wrote: > In Yoshifumi's example, if all the dropped packets belonged to one su= bflow, > and all the other packets belonged to another sub flow, the MPTCP rec= eiver > would receive out of order data at the MPTCP level and would either h= ave to > retain the tcp options in each packet even after the packet reaches t= he > MPTCP level or store the mappings in an auxiliary data structure. Right. That's why we have two levels of out-of-order queues. One at the= =20 subflow-level and one at the MPTCP-level to support your described reor= dering. The mapping is read when going from the subflow-level to the MPTCP-leve= l and=20 stored inside existing fields of the sk_buff. These fields are the seqn= o's of=20 the subflow. We overwrite these TCP subflow sequence-numbers as they are no more nee= ded as=20 they belonged to the subflow and we are moving a level higher to the MP= TCP- layer where only the data-sequence-number matters. That way we avoid to increase the size of the sk_buff structure, as we = reuse=20 the TCP-fields for MPTCP-information.=20 Cheers, Christoph > If such striping isn't used across multiple subflows, then very littl= e state > needs to be stored at the receiver. But a robust receiver implementat= ion > should be prepared to handle out of order data and mappings at the MP= TCP > level. --=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 georg.hampel@alcatel-lucent.com Thu Jul 5 06:47:11 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F8621F853D for ; Thu, 5 Jul 2012 06:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.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 qyz5lkd22hRa for ; Thu, 5 Jul 2012 06:47:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 38B0021F85F8 for ; Thu, 5 Jul 2012 06:47:10 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q65Dl65q019464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jul 2012 08:47:07 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q65Dl4XO003948 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Jul 2012 08:47:05 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 5 Jul 2012 08:47:04 -0500 From: "Hampel, K Georg (K Georg)" To: Christoph Paasch , Anumita Biswas Date: Thu, 5 Jul 2012 08:47:03 -0500 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1Z8KahajHagh6OSbmzCV0wPw7aEQAwmeXg Message-ID: <154773479ED2314980CB638A48FC4434C49D4521@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <2228022.C3KFSO16Cc@cpaasch-mac> <5F3EC5C2-BE97-4FF6-B34B-B838D86BCAC6@apple.com> <4176028.9GEuC7cy4F@cpaasch-mac> In-Reply-To: <4176028.9GEuC7cy4F@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 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: Thu, 05 Jul 2012 13:47:11 -0000 It is not known how packet-re-segmenting middleboxes align DSS and payload.= When packet-re-segmentation occurs the DSS mapping may arrive earlier at t= he receiver than the corresponding payload. Therefore, as long as we subscribe to the assumption that packet-re-segment= ing middleboxes exist, the implementation needs to support preemptive mappi= ngs. Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Christoph Paasch Sent: Wednesday, July 04, 2012 10:24 AM To: Anumita Biswas Cc: multipathtcp@ietf.org; Mahesh M; Ilpo J=E4rvinen Subject: Re: [multipathtcp] Number of DSS to store On Wednesday 04 July 2012 07:06:14 Anumita Biswas wrote: > In Yoshifumi's example, if all the dropped packets belonged to one subflo= w, > and all the other packets belonged to another sub flow, the MPTCP receive= r > would receive out of order data at the MPTCP level and would either have = to > retain the tcp options in each packet even after the packet reaches the > MPTCP level or store the mappings in an auxiliary data structure. Right. That's why we have two levels of out-of-order queues. One at the=20 subflow-level and one at the MPTCP-level to support your described reorderi= ng. The mapping is read when going from the subflow-level to the MPTCP-level an= d=20 stored inside existing fields of the sk_buff. These fields are the seqno's = of=20 the subflow. We overwrite these TCP subflow sequence-numbers as they are no more needed = as=20 they belonged to the subflow and we are moving a level higher to the MPTCP- layer where only the data-sequence-number matters. That way we avoid to increase the size of the sk_buff structure, as we reus= e=20 the TCP-fields for MPTCP-information.=20 Cheers, Christoph > If such striping isn't used across multiple subflows, then very little st= ate > needs to be stored at the receiver. But a robust receiver implementation > should be prepared to handle out of order data and mappings at the MPTCP > level. --=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 -- _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From christoph.paasch@uclouvain.be Thu Jul 5 06:54: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 E628E21F84D6 for ; Thu, 5 Jul 2012 06:54:04 -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 u21I6CdhHsXZ for ; Thu, 5 Jul 2012 06:54:04 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id DE84E21F84B9 for ; Thu, 5 Jul 2012 06:54:03 -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@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id EC2641C5EEA; Thu, 5 Jul 2012 15:54:12 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be EC2641C5EEA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1341496452; bh=6p3wtgvyPR8L4dNwsYyS+I3dOt88SVrErxx4RMiVEqc=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=ZGK3InArixDnqth0BnsvBF+TnQLe61CaZTpol6eqFZDwUqy5Zmm2uOKOjYZiTA4hw MYKDT/9TePNPwsajFizimPFqP5/14HyGjxMhyTx0WmH3pRea3CzIFQLdHHUhF+yYtU 3mSwF+rk31PSDGUsB+jzrH9mg/4zqPEUvdz5xzUY= From: Christoph Paasch To: "Hampel, K Georg (K Georg)" Date: Thu, 05 Jul 2012 15:54:12 +0200 Message-ID: <5163084.8fW8eOkCyj@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.4 (Linux/3.2.0-26-mptcp; KDE/4.8.4; x86_64; ; ) In-Reply-To: <154773479ED2314980CB638A48FC4434C49D4521@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4176028.9GEuC7cy4F@cpaasch-mac> <154773479ED2314980CB638A48FC4434C49D4521@USNAVSXCHMBSA2.ndc.alcatel-lucent.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-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: EC2641C5EEA.A3B8A 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: Thu, 05 Jul 2012 13:54:05 -0000 On Thursday 05 July 2012 08:47:03 Hampel, K Georg wrote: > It is not known how packet-re-segmenting middleboxes align DSS and pa= yload. > When packet-re-segmentation occurs the DSS mapping may arrive earlier= at > the receiver than the corresponding payload. How could this happen? Can you give an example with sequence-numbers, w= here=20 the DSS is not on one of the packets whose sequence-numbers he belongs = to. What I mean is: If a packet with DSS-mapping x -> y and subflow-seq-no x comes at the=20= middlebox. How could the middlebox resegment this packet so that the DSS-mapping i= s on=20 packet with subflow-seq-no x-1 ? This is a very buggy middlebox in my opinion, as it is sending a segmen= t (x-1)=20 that has already passed by this middlebox in the past. Christoph > Therefore, as long as we subscribe to the assumption that > packet-re-segmenting middleboxes exist, the implementation needs to s= upport > preemptive mappings. --=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 kpxue@ustc.edu Mon Jul 9 20:18:47 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 8FA7711E8110 for ; Mon, 9 Jul 2012 20:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.632 X-Spam-Level: ** X-Spam-Status: No, score=2.632 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] 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 FOXX6thAD3zz for ; Mon, 9 Jul 2012 20:18:47 -0700 (PDT) Received: from ustc.edu (smtp2.ustc.edu [202.141.160.101]) by ietfa.amsl.com (Postfix) with SMTP id 6D78A11E80F1 for ; Mon, 9 Jul 2012 20:18:45 -0700 (PDT) Received: from lenovo-09d60efa (unknown [202.38.84.142]) by mail.ustc.edu (Coremail) with SMTP id BxUW2rCrcjMfn_tPbzBIEg==.64836S2; Tue, 10 Jul 2012 11:19:09 +0800 (CST) Date: Mon, 9 Jul 2012 23:19:02 -0500 From: kpxue To: multipathtcp X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <201207092318483756687@ustc.edu> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Coremail-Antispam: 1U3129KBjvJXoW7tFW5Ww1DJrWUAry7Kw4Uurg_yoW8GFWDpa 1fZr9Igw1kJ34vqwn7XFn8tw1fu3y5ta92ka48Gr1F9Fs8uF10kF10kFWSgrWUGFy2krnx AF4xu34UXw4kXr7anT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjpFb7 Iv0xC_Cr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAFIxvE14AKwVWUJVWUGwAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lFcxC0VAYjxAxZF0Ew4CEw7xC 0wACY4xI67k04243AVC20s07Mx02cVAKzwCY0x0Ix7I2Y4AK64vIr41l4x8a64kEw24lx4 CE17CEb7AF67AKxVWUJVWUXwCE64xvF2IEb7IF0Fy70xZFpf9x07jMtC7UUUUU= Subject: [multipathtcp] Request comments on draft-xue-mptcp-tmpp-unware-hosts-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: Tue, 10 Jul 2012 03:18:47 -0000 SGkgYWxsLA0KDQp3ZSd2ZSBzdWJtaXR0ZWQgYSBkcmFmdCB0aXRsZWQgIlRNUFAgZm9yIEJvdGgg VHdvIE1QVENQLXVuYXdhcmUgSG9zdHMiLCBiZWxvdyBpcyB0aGUgbGluazogDQpodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dWUtbXB0Y3AtdG1wcC11bndhcmUtaG9z dHMtMDAudHh0IA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteHVlLW1wdGNwLXRtcHAt dW53YXJlLWhvc3RzLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBM ZWkgWmh1IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQogDQpGaWxlbmFtZTog IGRyYWZ0LXh1ZS1tcHRjcC10bXBwLXVud2FyZS1ob3N0cw0KUmV2aXNpb246ICAwMA0KVGl0bGU6 ICBUTVBQIGZvciBCb3RoIFR3byBNUFRDUC11bmF3YXJlIEhvc3RzDQpDcmVhdGlvbiBkYXRlOiAg MjAxMi0wNi0zMA0KV0cgSUQ6ICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdl czogMTQNClVSTDogaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHVl LW1wdGNwLXRtcHAtdW53YXJlLWhvc3RzLTAwLnR4dA0KU3RhdHVzOiBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1ZS1tcHRjcC10bXBwLXVud2FyZS1ob3N0cw0KSHRtbGl6 ZWQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1ZS1tcHRjcC10bXBwLXVud2Fy ZS1ob3N0cy0wMA0KIA0KIA0KQWJzdHJhY3Q6DQogICBUcmFuc3BhcmVudCBNUFRDUCBQcm94eShU TVBQKSBpcyBhIG5ldHdvcmstYmFzZWQgZnVuY3Rpb24sIHdoaWNoIGlzDQogICB1bmRlciBNUFRD UCBhcmNoaXRlY3R1cmUuICBJdCBjYW4gaGVscCB0d28gTVBUQ1AtdW5hd2FyZSBob3N0cyBlbmpv eQ0KICAgbXVsdGlwYXRoIHN1cHBvcnQsIGFuZCBjYW4gYmUgZXh0ZW5zaXZlbHkgdXNlZCBib3Ro IGluIHRoZSBhY2Nlc3MNCiAgIG5ldHdvcmtzIGFuZCBvcGVyYXRvcnMnIG5ldHdvcmtzLiAgTWVh bndoaWxlLCBpbiBNUFRDUCBhcmNoaXRlY3R1cmUNCiAgIHdpdGggVE1QUCwgVE1QUCBuZWVkcyB0 byBtb2RpZnkgdGhlIHJlY2VpdmVkIHBhY2tldHMgYW5kIHRyYW5zbWl0DQogICB0aGVtIGFnYWlu KGp1c3QgbGlrZSBnYXRld2F5IGluIE5BVCBlbnZpcm9ubWVudCkuICBJbiB0aGlzIGRvY3VtZW50 LA0KICAgd2UgYWxzbyBkaXNjdXNzIHRoZSBndWFyYW50ZWUgZm9yIGRhdGEgdHJhbnNmZXIgb24g VE1QUCdzIHNpZGUuICBUaGUNCiAgIGNvbnNpZGVyYXRpb24gb2YgZGF0YSB0cmFuc2ZlciBjYW4g YmUgZXhwYW5kZWQgdG8gdGhlIE1QVENQDQogICBhcmNoaXRlY3R1cmUgd2l0aCBwcm94eS4NCg0K DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpLYWlwaW5nIFh1ZQ== From kpxue@ustc.edu Mon Jul 9 20:25: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 7854011E8110 for ; Mon, 9 Jul 2012 20:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.077 X-Spam-Level: *** X-Spam-Status: No, score=3.077 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_05=-1.11, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] 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 rgxPk9+42hrz for ; Mon, 9 Jul 2012 20:25:43 -0700 (PDT) Received: from ustc.edu (smtp2.ustc.edu [202.141.160.101]) by ietfa.amsl.com (Postfix) with SMTP id 1A4C811E810A for ; Mon, 9 Jul 2012 20:25:41 -0700 (PDT) Received: from lenovo-09d60efa (unknown [202.38.84.142]) by mail.ustc.edu (Coremail) with SMTP id BxUW2rCLIW3LoPtPXvZKEg==.65378S2; Tue, 10 Jul 2012 11:26:06 +0800 (CST) Date: Mon, 9 Jul 2012 23:25:59 -0500 From: kpxue To: multipathtcp References: <20120710032015.42842D880B0@mda113-92.sinamail.sina.com.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <201207092325570007489@ustc.edu> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Coremail-Antispam: 1U3129KBjvJXoWxXFyDZw48ZF4fXrWUWr1UGFg_yoWruw15pr 1Sqry7Kr4DGryUt3W8A3W8XFy5Crn5Jw4DG3Wrtry8Zr98AryDGr1xtFyrtFyUXr95Xw15 XFyjgr15AF1UJw7anT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UU U0I7k0a2IF6w4kMc02F40EFcxC0VAKzVAqx4xG6I80ewAYFVCjjxCrM7AC8VAFwI0_Jr0_ Gr1l1I0E4x80FVCIwcAKzIAtM7C26IkvcIIF6IxKo4kEV4yl1IIY67AEw4v_Jr0_Jr4lYx 0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UM4xvF2IEb7IF0Fy264kE 64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCjxxvEw4Wlc2IjII80xcxEwVAKI48JMxCjnVAKz4 kxMI8E67AF67kF1VAFwI0_Jr0_JrylIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aV CY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy70xZFpf9x07bqWrAUUUUU= Subject: Re: [multipathtcp] Request comments ondraft-xue-mptcp-tmpp-unware-hosts-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: Tue, 10 Jul 2012 03:25:43 -0000 SGkgYWxsLA0KDQpQbGVhc2UgcHJvdmlkZSBjb21tZW50cyBhbmQgZmVlZGJhY2sgb2Ygb3VyIGRy YWZ0LiANCg0KQWNjb3JkaW5nIHRvIHdoZXRoZXIgZW5kIGhvc3RzIHJ1biBNUFRDUCwgdGhlIGNh c2UgIk5laXRoZXIgZW5kIGhvc3QgcnVucyBNUFRDUCIgaXMgbWV0aW9uZWQsIHdoaWNoIGlzIGhv dGx5IGRpc2N1c3NlZCBpbiBXRyBtZWV0aW5nKElFVEYtODMpIGFuZCBtYWlsaXN0Lg0KDQpUTVBQ IChUcmFuc3BhcmVudCBNUFRDUCBQcm94eSkgaXMgcHJlZG9taW5hbnRseSB1c2VkIHdoZW4gdHdv IE1QVENQLXVuYXdhcmUgaG9zdHMgYXJlIGNvbW11bmljYXRpbmcgd2l0aCBlYWNoIG90aGVyLCBh bmQgYXQgbGVhc3Qgb25lIG9mIHRoZW0gaXMgbG9jYXRlZCBpbiBtb2JpbGUgYWNjZXNzIG5ldHdv cmtzIGVuYWJsaW5nIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheXMgd2l0aCBNUFRDUCBmdW5jdGlvbiB0 b3dhcmRzIG5ldHdvcmsgc2lkZSwgb3Igb25lIG5ldHdvcmsgZWxlbWVudCBpbiB0aGUgbmV0d29y ayBzdXBwb3J0aW5nIG11bHRpcGF0aC4gSW4gb3RoZXIgd29yZHMsIHRoZSBjb25uZWN0aW9uIHNw bGl0LXBvaW50IG1heSBsb2NhdGUgaW4gdGhlIGFjY2VzcyBzaWRlIG9yIHRoZSBvcGVyYXRvcnMn IG5ldHdvcmtzLg0KDQp3ZSB0aGluayB0aGVyZSBhcmUgZm9sbG93aW5nIGRlcGxveW1lbnQgc2Nl bmFyaW9zIGZpdHRpbmcgaW50byB0aGlzIGNhc2UuDQoNCjEpIFNwbGl0LXBvaW50IGxvY2F0ZXMg aW4gdGhlIGFjY2VzcyBuZXR3b3Jrcy4gVGhlIGFjY2VzcyBnYXRld2F5IHByb3ZpZGVzIE1QVENQ IGZ1bmN0aW9uIHRvd2FyZHMgbmV0d29yayBzaWRlLCBhbmQgdGhlIG11bHRpcGF0aCBjb25uZWN0 aW9uIGJlZ2lucyBhbmQgZW5kcyBib3RoIGF0IHRoZSBzZXBlcmF0ZSBhY2Nlc3MgZ2F0ZXdheXMu IFdoaWxlIGl0J3Mgbm90IHJlYWxpc3RpYyB0byBtYWtlIGFsbCBlbmQgZGV2aXNlcyBNUFRDUC1j YXBhYmxlLCBrZWVwaW5nIE1QVENQIGZ1bmN0aW9uIG9uIG5ldHdvcmstc2lkZSB3aWxsIGJlIGhl bHBmdWwgYnkgZW5zdXJpbmcgdGhlIG5ldHdvcmsgYWNjZXNzIGRldmlzZSBpcyBNUFRDUC1jYXBh YmxlLiANCihhKUEgaG91c2Vob2xkIGFjY2VzcyBkZXZpY2UgaXMgY29ubmVjdGVkIHRvIHRoZSBJ bnRlcm5ldCB2aWEgbXVsdGlwbGUgYWNjZXNzIG1ldGhvZHMsIHdoaWxlIHRoZSBlbmQgZGV2aXNl IHZpYSBhIHVuaXF1ZSB3YXkgdG8gdGhlIGFjY2VzcyBkZXZpc2UuDQooYilBIHZlaGljbGUgbmV0 d29yayBoYXMgc2V2ZXJhbCBhY2Nlc3MgbWV0aG9kcywgd2hpbGUgdGhlIG1vYmlsZSBkZXZpY2Vz IGhvbGQgYnkgcGFzc2VuZ2VycyBjYW4gY29ubmVjdCBpdCB2aWEgb25seSBvbmUgd2F5IChlLmcu IFdpLUZpKS4NCkluIHRoZSB0aGlzIHNjZW5hcmlvLCBpdCBzaW1wbHkgc29sdmVzIHRoZSBwcm9i bGVtIGJ5IHByb3ZpZGluZyBhIE1QVENQLWNhcGFibGUgYWNjZXNzIGdhdGV3YXksIHRoZW4gaXQg b25seSBuZWVkcyBuZXR3b3JrIGVkZ2UgZGV2aWNlcydzdXBwb3J0LCBob3dldmVyLCBpdCBjb3N0 cyBtdWNoIGJlY2F1c2UgdGhlIGVkZ2UgZGV2aWNlIHNob3VsZCBoYXZlIHNldmVyYWwgU1Agc2ln bmluZ3MuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICst LS0tLS0tLStfX19fX19fX19fX19fX19fX19fX19fX18rLS0tLS0tLS0rDQogICArLS0tLS0tKyAg IHwgICAgICAgIHwgOiAgICAgICAgICA6ICAgICAgICAgOiB8ICAgICAgICB8ICAgKy0tLS0tLSsN CiAgIHwgICAgICB8ICAgfCBBY2Nlc3MgfF9fX19fX19fX19fX19fX19fX19fX19fX3wgICAgICAg IHwgICB8ICAgICAgfA0KICAgfCBIb3N0IHwgICB8IEdhdGV3YXl8IDogICAgICAgICAgOiAgICAg ICAgIDogfCBBY2Nlc3MgfCAgIHwgSG9zdCB8DQogICB8ICAgICAgfC0tLXwgICAgQSAgIHxfX19f X19fX19fX19fX19fX19fX19fX198R2F0ZXdheSB8LS0tfCAgICAgIHwNCiAgIHwgICBBICB8ICAg fCAgICAgICAgfCA6ICAgICAgICAgIDogICAgICAgICA6IHwgICAgQiAgIHwgICB8ICAgQiAgfA0K ICAgfCAgICAgIHwgICB8ICAgICAgICB8X19fX19fX19fX19fX19fX19fX19fX19ffCAgICAgICAg fCAgIHwgICAgICB8DQogICArLS0tLS0tKyAgIHwgKFRNUFApIHwgOiAgICAgICAgICA6ICAgICAg ICAgOiB8IChUTVBQKSB8ICAgKy0tLS0tLSsNCiAgICAgICAgICAgICAgKy0tLS0tLS0tKyAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRmlndXJlIDENCg0KMilTcGxpdC1wb2ludCBsb2NhdGVzIGluIHRoZSBvcGVyYXRvcnMnIG5l dHdvcmtzLiBDdXJyZW50bHksIHRoZSBib3R0bGVuZWNrIGlzIHRoZSBhY2Nlc3Mgc2lkZSdzIGVu dHJhbmNlIGludG8gdGhlIGNvcmUgbmV0d29yay4gQWx0aG91Z2ggdGhlIGluc2lkZSBjb3JlIG5l dHdvcmsgd29ya3Mgd2VsbCwgdGhlIGxvdyBlZmZpY2llbmN5IGluIGJhY2toYXVsIGxpbWl0cyB0 aGUgd2hvbGUgc3lzdGVtJ3MgcGVyZm9ybWFuY2UuIFRoZSBlYXJsaWVyIGZvciB0aGUgbXVsdGlw bGUgcGF0aHMgdG8gYWdncmVnYXRlLCB0aGUgYmV0dGVyLCB3aGljaCBpcyB0aGUgc2FtZSB0byBz ZXBhcmF0ZSwgc28gaXShr3Mgc3VnZ2VzdGVkIHRvIHB1dCB0aGUgc3BsaXQgcG9pbnQgaW50byBh biBvcGVyYXRvciBuZXR3b3JrIGVsZW1lbnQuIEluIHRoaXMgd2F5LCAgDQooYSlpdCB3aWxsIGJl IGNvbnZlbmllbnQgZm9yIG9wZXJhdG9yJ3MgZmxleGlibGUgbWFuYWdlbWVudCBhbmQgY2hhcmdp bmcuIA0KKGIpU2luY2UgdGhlIG11bHRpcGxlIHBhdGhzIGFyZSBtYW5hZ2VkIGJ5IHRoZSBvcGVy YXRvciwgdGhpcyBzaW5nbGUgY29ubmVjdGlvbiBuZWVkcyBvbmx5IG9uZSBTUCBzaWduaW5nLg0K VHdvIGNhc2VzIG9mIHRoaXMgc2NlbmFyaW86DQoyLTEpVGhlIHNlbmRlciBvciB0aGUgcmVjZWl2 ZXIgaXMgbGltaXRlZCwgdGhlIHVuLWxpbWl0ZWQgZW5kIGhvc3QgbG9jYXRlcyBpbiBJbnRlcm5l dCwgYW5kIGEgTVBUQ1AtY2FwYWJsZSBQLUdXIG1hbmFnZXMgbXVsdGlwYXRoLg0KICAgICAgICAg ICAgICAgKy0tLS0tLS0tK19fX19fX19fX19fX19fX19fKy0tLS0tLS0tKyAgDQogICAgKy0tLS0t LSsgICB8ICAgICAgICB8IDogICAgICAgICAgOiAgICB8ICAgICAgICB8ICAgICAgICAgICArLS0t LS0tLS0rDQogICAgfCAgICAgIHwgICB8IEFjY2VzcyB8X19fX19fX19fX19fX19fX198ICBNUFRD UCB8ICAgICAgICAgICB8ICAgICAgICB8DQogICAgfCBIb3N0IHwgICB8IEdhdGV3YXl8IDogICAg ICAgICAgOiAgICB8LWNhcGFibGV8ICAgICAgICAgICB8IEhvc3QgICB8ICAgDQogICAgfCAgICAg IHwtLS18ICAgICAgICB8X19fX19fX19fX19fX19fX198IFAtR1cgICB8LS0tLS0tLS0tLS18ICBC ICAgICB8ICANCiAgICB8ICAgQSAgfCAgIHwgICAgICAgIHwgOiAgICAgICAgICA6ICAgIHwgICAg ICAgIHwgICAgICAgICAgIHwobG9jYXRlc3wNCiAgICB8ICAgICAgfCAgIHwgICAgICAgIHxfX19f X19fX19fX19fX19fX3wgICAgICAgIHwgICAgICAgICAgIHwgICBpbiAgIHwNCiAgICArLS0tLS0t KyAgIHwgKFRNUFApIHwgOiAgICAgICAgICA6ICAgIHwgICAgICAgIHwgICAgICAgICAgIHxJbnRl cm5ldHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICstLS0tLS0t LSsgICAgICAgICAgICstLS0tLS0tLSsgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBGaWd1cmUyDQoNCjItMilCb3RoIHRoZSBzZW5kZXIgYW5kIHRoZSByZWNlaXZlciBh cmUgbGltaXRlZC4gYW5kIHRoZXJlIGFyZSB0d28gTVBUQ1AtY2FwYWJsZSBQLUdXcyB3b3JraW5n IGZvciB0aGVtIHNlcGFyYXRlbHkuDQoNCiAgICAgICAgICAgICAgKy0tLS0tLS0tK19fX19fX19f X19fX19fX19fKy0tLS0tLS0tKyAgICAgICstLS0tLS0tLStfX19fX19fX19fX19fX19fXystLS0t LS0tLSsNCiAgICstLS0tLS0rICAgfCAgICAgICAgfCA6ICAgICAgICAgIDogICAgfCAgICAgICAg fCAgICAgIHwgICAgICAgIHwgOiAgICAgICAgICA6ICAgIHwgICAgICAgIHwgICAgICArLS0tLS0t Kw0KICAgfCAgICAgIHwgICB8IEFjY2VzcyB8X19fX19fX19fX19fX19fX198ICBNUFRDUCB8ICAg ICAgfCAgTVBUQ1AgfF9fX19fX19fX19fX19fX19ffCBBY2Nlc3MgfCAgICAgIHwgICAgICB8DQog ICB8IEhvc3QgfCAgIHwgR2F0ZXdheXwgOiAgICAgICAgICA6ICAgIHwtY2FwYWJsZXwgICAgICB8 LWNhcGFibGV8IDogICAgICAgICAgOiAgICB8IEdhdGV3YXl8ICAgICAgfCBIb3N0IHwNCiAgIHwg ICAgICB8LS0tfCAgIEEgICAgfF9fX19fX19fX19fX19fX19ffCBQLUdXIEEgfC0tLS0tLXwgUC1H VyBCIHxfX19fX19fX19fX19fX19fX3wgICBCICAgIHwtLS0tLS18ICAgICAgfA0KICAgfCAgIEEg IHwgICB8ICAgICAgICB8IDogICAgICAgICAgOiAgICB8ICAgICAgICB8ICAgICAgfCAgICAgICAg fCA6ICAgICAgICAgIDogICAgfCAgICAgICAgfCAgICAgIHwgICBCICB8DQogICB8ICAgICAgfCAg IHwgICAgICAgIHxfX19fX19fX19fX19fX19fX3wgICAgICAgIHwgICAgICB8ICAgICAgICB8X19f X19fX19fX19fX19fX198ICAgICAgICB8ICAgICAgfCAgICAgIHwNCiAgICstLS0tLS0rICAgfCAo VE1QUCkgfCA6ICAgICAgICAgIDogICAgfCAgICAgICAgfCAgICAgIHwgICAgICAgIHwgOiAgICAg ICAgICA6ICAgIHwgKFRNUFApIHwgICAgICArLS0tLS0tKw0KICAgICAgICAgICAgICArLS0tLS0t LS0rICAgICAgICAgICAgICAgICArLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRmlndXJlIDMNCg0KUmVjZW50bHksIFtkcmFmdC1heWFyLXRyYW5zcGFyZW50LXNjYS1w cm94eS0wMF0gcHJlc2VudHMgYSBuZXcgYXJjaGl0ZWN0dXJlLCBuYW1lZCBTQ0EgKFNwbGl0dGVy L0NvbWJpbmVyIEFyY2hpdGVjdHVyZSksIHdoaWNoIGVuYWJsZXMgbm9uLU1QVENQLWNhcGFibGUg c2luZ2xlLWhvbWVkIGhvc3RzIHRvIGJlbmVmaXQgZnJvbSBtdWx0aXBhdGggYnkgbWVhbnMgb2Yg UEVQcyAoUGVyZm9ybWFuY2UgRW5oYW5jaW5nIFByb3hpZXMpIHBsYWNlZCBpbiB0aGUgYWNjZXNz IG5ldHdvcmtzLiBUaGlzIGRyYWZ0IGNvcnJlc3BvbmRzIHRvIHRoZSB0aGlzIGNhc2UsIGJ1dCBp dCBpcyBjb250cm92ZXJzaWFsIHNpbmNlIGl0J3MgY29tcGxldGVseSBpbmRlcGVuZGVudCBvZiBN UFRDUCBhcmNoaXRlY3R1cmUuDQoNCldlIHRoaW5rIHRoZXJlIGFyZSBvbmUgc2ltcGxlIHRoaW5n IHRvIHN1cHBvcnQgdGhpcyBjYXNlLiBJbiBvcmRlciB0byBwcm92aWRlIGNoYW5jZXMgZm9yIGEg Y29ubmVjdGlvbiBiZXR3ZWVuIHR3byBNUFRDUC11bmF3YXJlIGhvc3RzIHRvIGVuam95IG11bHRp cGF0aCBzdXBwb3J0LCB3ZSBtYWtlIGEgY2hhbmdlIHdoaWNoIHJlcXVpcmVzIGFub3RoZXIgaW1w bGljaXQgTVBUQ1AgbmV0d29yayBub2RlIHNob3VsZCBhbHNvIGluc2VydCBNUF9DQVBBQkxFIHRv IHRoZSBTWU4tQUNLIHJlc3BvbnNlIGV2ZW4gaWYgZmluZGluZyB0aGUgUFJPWFkgZmxhZyBzZXQg aW4gdGhlIE1QX0NBUEFCTEUgb3B0aW9uLiANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkthaXBpbmcgWHVl From kpxue@ustc.edu Mon Jul 9 20:42:41 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 2F75811E8117 for ; Mon, 9 Jul 2012 20:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.554 X-Spam-Level: ** X-Spam-Status: No, score=2.554 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] 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 Aaf-0NBy+ak9 for ; Mon, 9 Jul 2012 20:42:40 -0700 (PDT) Received: from ustc.edu (smtp2.ustc.edu [202.141.160.101]) by ietfa.amsl.com (Postfix) with SMTP id 33A3511E8114 for ; Mon, 9 Jul 2012 20:42:38 -0700 (PDT) Received: from lenovo-09d60efa (unknown [202.38.84.142]) by mail.ustc.edu (Coremail) with SMTP id BxUW2rCrkjK4pPtPgrRYEg==.1168S2; Tue, 10 Jul 2012 11:43:03 +0800 (CST) Date: Mon, 9 Jul 2012 23:42:55 -0500 From: kpxue To: multipathtcp X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <2012070923424145304513@ustc.edu> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Coremail-Antispam: 1U3129KBjvJXoW7ur1kWrW7urykKry8tF4DCFg_yoW8CF47pr 4fKry3GFyDJFy5Xw18Gr4UJF15Cr4rt34UtF13try8X345Zr1Dtr1xJryrJryDXr93Xw1U tFyUWw1UAr1DArJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UU U0I7k0a2IF6w4xMc02F40EFcxC0VAKzVAqx4xG6I80ewAYFVCjjxCrM7AC8VAFwI0_Jr0_ Gr1l1I0E4x80FVCIwcAKzIAtM7C26IkvcIIF6IxKo4kEV4yl1IIY67AEw4v_Jr0_Jr4lYx 0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4UM4xvF2IEb7IF0Fy264kE 64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCjxxvEw4Wlc2IjII80xcxEwVAKI48JMxCjnVAKz4 kxMI8E67AF67kF1VAFwI0_Jrv_JF1lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aV CY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy70xZFpf9x07j_L05UUUUU= Subject: Re: [multipathtcp] Request comments ondraft-xue-mptcp-tmpp-unware-hosts-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: Tue, 10 Jul 2012 03:42:41 -0000 SGkgYWxsLA0KDQpBbm90aGVyIHRoaW5nIGZvciBNUFRDUCBQcm94eSBpcyBtYWludGVuYWNlIGlu IFRNUFAuIFRha2UgdGhlIGZpcnN0IHNjZW5hcmlvIHdoaWNoIEkgZGVzY3JpYmVkIGluIHRoZSBs YXN0IGVtYWlsLiBUaGUgZW5kLXRvLWVuZCBjb25uZWN0aW9uIGlzIHNwbGl0dGVkIGludG8gdHdv IFRDUCBzZWN0aW9ucyBhbmQgb25lIE1QVENQIHNlY3Rpb24sIHRoZSBjb3VwbGVzIG9mIFRNUFBz IGJlY29tZSB0aGUgZW5kIHBvaW50cyBmb3IgYWxsIGZ1cnRoZXIgc3ViZmxvd3MuIA0KVGhlc2Ug c3ViZmxvd3MgbWF5IGJlIGluaXRpYXRlZCBieSBUTVBQLCBhbmQgdG8gYXZvaWQgYmVpbmcgZXN0 YWJsaXNoZWQgd2l0aCB0aGUgTVBUQ1AtdW5hd2FyZSBob3N0cywgVE1QUHMgbXVzdCBpbmZvcm0g YWJvdXQgdGhlaXIgZXhpc3RlbmNlIGFuZCBJUCBhZGRyZXNzZXMgd2l0aCBlYWNoIG90aGVyLiBM aWtlIE5BVCwgVE1QUCBBIGFzc2lnbnMgdGhlIHJlY2VpdmVkIHBhY2tldHMgdG8gc3ViZmxvd3Mg YWxyZWFkeSBlc3RhYmxpc2hlZCBiZXR3ZWVuIFRNUFAgQSBhbmQgVE1QUCBCLCB0aGVuIGNoYW5n ZSBJUCBoZWFkIGFuZCBUQ1AgaGVhZC4gVE1QUCBBIG1haW50YWlucyB0aGUgdHJhbnNsYXRpb24g cmVsYXRpb25zaGlwIGFuZCBpbmZvcm0gdGhpcyBpbmZvcm1hdGlvbiB0byBUTVBQIEIuDQpXaXRo IHRoZSByZWNlcHRpb24gb2YgdGhlIHBhY2tldCBmcm9tIFRNUFAgQSwgVE1QUCBCIGFja25vd2xl ZGdlcyBpdCBhdCBzdWJmbG93IGxldmVsLCBzZW5kaW5nIEFDSyB0byBUTVBQIA0KQSAodGhlIEFD SyBudW1iZXIgaXMgYXQgc3ViZmxvdyBsZXZlbCkuDQpBdCB0aGUgc2FtZSB0aW1lLCBUTVBQIEIg cmVjb3ZlcnMgdGhlIGxvY2F0b3JzIHRvIHRob3NlIG9mIGhvc3QgQSwgcmVtb3ZlcyBNUFRDUCBv cHRpb24sIGFuZCBzZW5kcyB0aGUgcGFja2V0IHRvIGhvc3QgQi4NCkhvc3QgQSBhbmQgSG9zdCBC IGNhbiBiZSB1bmF3YXJlIG9mIE1QVENQIFByb2Nlc3NpbmcuDQoNCkFsc28gYW5vdGhlciBwcmFj dGljYWwgd2F5IGlzIHVzaW5nIHR1bm5lbC4gc3VjaCBhcyBGaWd1cmUyLiBJZiB1c2luZyB0aGlz IG1ldGhvZCwgVE1QUCBBIGRvZXMgbm90IG5lZWQgdG8gaW5mb3JtIHRoZSB0cmFuc2xhdGlvbiBy ZWxhdGlvbnNoaXAgdG8gVE1QUCBCLCBiZWNhdXNlIFRNUFAgQiBvbmx5IG5lZWQgdG8gcmVtb3Zl IHRoZSBvdXRzaWRlIGVuY2Fwc3VsYXRpb24uICANCg0KSWYgaXQgd2VyZSBmZWFzaWJsZSwgd2Ug d2lsbCBmdXRoZXIgZGVzaWduIGl0IGluIGRldGFpbHMgYXMgc29vbiBhcyBwb3NzaWJsZS4NCg0K DQoNCg0KICAgICAgICAgICAgICArLS0tLS0tLS0rX19fX19fX19fX19fX19fX19fX19fX19fKy0t LS0tLS0tKw0KICAgKy0tLS0tLSsgICB8ICAgICAgICB8IDogICAgICAgICAgOiAgICAgICAgIDog fCAgICAgICAgfCAgICstLS0tLS0rDQogICB8ICAgICAgfCAgIHwgQWNjZXNzIHxfX19fX19fX19f X19fX19fX19fX19fX198ICAgICAgICB8ICAgfCAgICAgIHwNCiAgIHwgSG9zdCB8ICAgfCBHYXRl d2F5fCA6ICAgICAgICAgIDogICAgICAgICA6IHwgQWNjZXNzIHwgICB8IEhvc3QgfA0KICAgfCAg ICAgIHwtLS18ICAgIEEgICB8X19fX19fX19fX19fX19fX19fX19fX19ffEdhdGV3YXkgfC0tLXwg ICAgICB8DQogICB8ICAgQSAgfCAgIHwgICAgICAgIHwgOiAgICAgICAgICA6ICAgICAgICAgOiB8 ICAgIEIgICB8ICAgfCAgIEIgIHwNCiAgIHwgICAgICB8ICAgfCAgICAgICAgfF9fX19fX19fX19f X19fX19fX19fX19fX3wgICAgICAgIHwgICB8ICAgICAgfA0KICAgKy0tLS0tLSsgICB8IChUTVBQ KSB8IDogICAgICAgICAgOiAgICAgICAgIDogfCAoVE1QUCkgfCAgICstLS0tLS0rDQogICAgICAg ICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0rDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgRmluZ3VyZSAxDQoNCiAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQogICAgICAgICAgICAgICAgICB8ICAgSVAgICAgfCAgIFRDUCAgIHwgIE1QVENQICB8 IFJlY2VpdmVkIElQIHBhY2tldCBGcm9tIGhvc3QgQSAgfA0KICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpbmd1cmUg Mg0KDQoNCi0tLS0tLS0tLS0tLQ0KS2FpcGluZyBYdWU= From Mahesh.M@citrix.com Wed Jul 11 11:54:56 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 1EBE921F865F for ; Wed, 11 Jul 2012 11:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=-2.376, 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 UcyQeMxqoF6i for ; Wed, 11 Jul 2012 11:54:55 -0700 (PDT) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7A821F8649 for ; Wed, 11 Jul 2012 11:54:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,569,1336363200"; d="scan'208,217";a="201841264" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 Jul 2012 14:55:05 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Wed, 11 Jul 2012 11:55:04 -0700 From: Mahesh M To: "multipathtcp@ietf.org" Date: Wed, 11 Jul 2012 11:55:02 -0700 Thread-Topic: MPTCP checksum Thread-Index: Ac1flZLu0WQvvzBnSDKgJ9GpUwswog== Message-ID: <6E004C34C1C59E45A35B4338808BC31501300E3FB8D6@SJCPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E004C34C1C59E45A35B4338808BC31501300E3FB8D6SJCPMAILBOX_" MIME-Version: 1.0 Subject: [multipathtcp] MPTCP checksum 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, 11 Jul 2012 18:54:56 -0000 --_000_6E004C34C1C59E45A35B4338808BC31501300E3FB8D6SJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, For internet checksum calculation either we can use 16bit, 32bit or 64bit w= ords and we need to fold the sum at the end and add the carry. For parallel= ism when we make choice of 32bit or 64bit accumulators, we usually we choos= e 64bit when native register size is 64bits. IPv4/IPv6 packet cannot go beyond 64KB (i.e. including IP and TCP headers),= so TCP checksum theoretically cannot wrap around 32bit value and use of 64= bit accumulator gives us parallelism. But MPTCP checksum mapping can be 64= KB-1 + 16bytes of pseudo header which can overflow 32bit value. If my under= standing is correct then we need to use 64bit accumulator if our checksum c= alculation. Any comments on this? Regards, Mahesh --_000_6E004C34C1C59E45A35B4338808BC31501300E3FB8D6SJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

For intern= et checksum calculation either we can use 16bit, 32bit or 64bit words and w= e need to fold the sum at the end and add the carry. For parallelism when w= e make choice of 32bit or 64bit accumulators, we usually we choose 64bit wh= en native register size is 64bits.

IPv4/= IPv6 packet cannot go beyond 64KB (i.e. including IP and TCP headers), so T= CP checksum theoretically cannot wrap around 32bit value and use of 64 bit = accumulator gives us parallelism. But MPTCP checksum mapping can be 64KB-1 = + 16bytes of pseudo header which can overflow 32bit value. If my understand= ing is correct then we need to use 64bit accumulator if our checksum calcul= ation.

 

Any comments on this?

&nbs= p;

Regards,

Mahesh

= --_000_6E004C34C1C59E45A35B4338808BC31501300E3FB8D6SJCPMAILBOX_-- From dreibh@iem.uni-due.de Thu Jul 12 13:08:29 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 1921521F85F4 for ; Thu, 12 Jul 2012 13:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 nW+qKDgBwOeM for ; Thu, 12 Jul 2012 13:08:28 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 914CF21F854B for ; Thu, 12 Jul 2012 13:08:22 -0700 (PDT) Received: from lupo.localnet ([132.252.151.188]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id q6CK8rOa004968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Jul 2012 22:08:54 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Thu, 12 Jul 2012 22:04:59 +0200 Message-ID: <2206673.Ut3UrXRfhB@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.8.4 (Linux/3.2.0-26-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: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: [multipathtcp] Call for Papers of the PAMS 2013 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, 12 Jul 2012 20:08:29 -0000 We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 3rd International Workshop on Protocols and Applications with Multi= -Homing=20 Support (PAMS 2013) In conjunction with the 27th IEEE International Conference on Advanced=20= Information Networkingand Applications (AINA 2013) Barcelona, Spain, March 25-28, 2013 http://simula.no/pams2013 The intent of our workshop is to bring together people from research an= d industry, in order to provide a discussion forum for state-of-the-art t= opics related to multi-homing on Network, Transport, Session and Application = Layers. The PAMS workshop will include full-paper sessions as well as a poster = session (with short presentations) to introduce preliminary ideas as well as wo= rk in progress. Workshops proceedings will be published by the IEEE CS Conference Publi= shing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimization for Multi-Homed Systems * Multi-Homing in the Context of Future Internet GENERAL CHAIRS: * Thomas Dreibholz, Simula Research Laboratory, Norway * Hakim Adhari, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Martin Becke, University of Duisburg-Essen, Germany * Thomas Dreibholz, Simula Research Laboratory, Norway PUBLICITY CHAIRS: * Glenford Mapp, Middlesex University, United Kingdom * Xing Zhou, Hainan University, China PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, ista International, Germany * Paul Amer, University of Delaware, U.S.A. * Holger Bleul, DB Systel, Germany * Anna Brunstr=F6m, Karlstad University, Sweden * Ahmed Elmokashfi, Simula Research Laboratory, Norway * Kristian Evensen, Simula Research Laboratory, Norway * Ernst Gunnar Gran, Simula Research Laboratory, Norway * Seok Joo Koh, Kyungpook National University, South Korea * Amund Kvalbein, Simula Research Laboratory, Norway * Glenford Mapp, Middlesex University, United Kingdom * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, Google, U.S.A. * Esbold Unurkhaan, Mongolian University of Science and Technology,= =20 Mongolia * Andreas Timm-Giel, TU Hamburg-Harburg, Germany * Alan Wagner, University of British Columbia, Canada * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: October 01, 2012 * Author Notification: December 01, 2012 * Camera-Ready Paper Submission: January 06, 2013 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE http://simula.no/pams2013 From ramin.khalili@epfl.ch Fri Jul 13 03:12:38 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 B7F5521F86D9 for ; Fri, 13 Jul 2012 03:12:38 -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.001, 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 2ADRn1YKYZDr for ; Fri, 13 Jul 2012 03:12:37 -0700 (PDT) Received: from smtp4.epfl.ch (smtp4.epfl.ch [128.178.224.218]) by ietfa.amsl.com (Postfix) with SMTP id B239A21F86D4 for ; Fri, 13 Jul 2012 03:12:35 -0700 (PDT) Received: (qmail 23782 invoked by uid 107); 13 Jul 2012 10:13:03 -0000 X-Virus-Scanned: ClamAV Received: from slb-nat-128-178-224-64.epfl.ch (HELO EWA4.intranet.epfl.ch) (192.26.45.64) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTP; Fri, 13 Jul 2012 12:13:04 +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; Fri, 13 Jul 2012 12:12:56 +0200 From: Khalili Ramin To: "multipathtcp@ietf.org" Thread-Topic: submitted draft: performance issues with MPTCP Thread-Index: Ac1g4BHM8AxOJhQMRBODU1Xb2hG88g== Date: Fri, 13 Jul 2012 10:12:55 +0000 Message-ID: Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.178.151.233] Content-Type: multipart/alternative; boundary="_000_B20442DB7A739B4CB083DA0F24635C2F29E806D0REXMEintranetep_" MIME-Version: 1.0 Subject: [multipathtcp] submitted draft: performance issues with MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 10:12:39 -0000 --_000_B20442DB7A739B4CB083DA0F24635C2F29E806D0REXMEintranetep_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, Please consider reviewing our submitted draft to the IETF: URL: http://www.ietf.org/internet-drafts/draft-khalili-mptcp-performance-i= ssues-00.txt Htmlized: http://tools.ietf.org/html/draft-khalili-mptcp-performance-issue= s-00 It discusses about the performance problems we identified with current MPTC= P implementation. We attribute these performance problems to the =93Linked = Increases=94 congestion control algorithm of the MPTCP. Our results show t= hat these problems are important and can be mitigated. We will present this draft at the IETF meeting in Vancouver. More results and analysis be found in our technical report: http://infosci= ence.epfl.ch/record/177901 Best regards, Ramin Khalili. Abstract: We show, by measurements over a testbed and by mathematical analysis, that = the current MPTCP suffers from two problems: (P1) Upgrading some TCP users = to MPTCP can reduce the throughput of others without any benefit to the upg= raded users; and (P2) MPTCP users can be excessively aggressive towards TCP= users. We attribute these problems to the "Linked Increases" Algorithm (LI= A) of MPTCP [4], and more specifically, to an excessive amount of traffic t= ransmitted over congested paths. Our results show that these problems are i= mportant and can be mitigated. We believe that the design of the congestion= control of MPTCP should be improved. --_000_B20442DB7A739B4CB083DA0F24635C2F29E806D0REXMEintranetep_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Folks,


Please consider reviewing our submi= tted draft to the IETF:


URL:  http://www.ietf.org/internet-dr= afts/draft-khalili-mptcp-performance-issues-00.txt


Htm= lized:  http://tools.ietf.org/html/draft-khalili-mptcp-performance-issues-00


It discusses about the performance = problems we identified with current MPTCP implementation. We attribute thes= e performance problems to the =93Linked Increases=94 congestion control algorithm of the MPTCP.  Our results show that these problems are important and can b= e mitigated.


We will present this draft at the I= ETF meeting in Vancouver.


More results and analysis be found = in our technical report:  http://infoscience.epfl.ch/record/177901=


Best regards,

Ramin Khalili.

 

Abstract:

We show, by measurements over a tes= tbed and by mathematical analysis, that the current MPTCP suffers from two = problems: (P1) Upgrading some TCP users to MPTCP can reduce the throughput of others without any benefit to the up= graded users; and (P2) MPTCP users can be excessively aggressive towards TC= P users. We attribute these problems to the "Linked Increases" Al= gorithm (LIA) of MPTCP [4], and more specifically, to an excessive amount of traffic transmitted over congested paths. Our re= sults show that these problems are important and can be mitigated. We belie= ve that the design of the congestion control of MPTCP should be improved.   

--_000_B20442DB7A739B4CB083DA0F24635C2F29E806D0REXMEintranetep_-- From Rolf.Winter@neclab.eu Mon Jul 16 07:36:18 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FFC21F85E6 for ; Mon, 16 Jul 2012 07:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 hwVwzi4XtZ70 for ; Mon, 16 Jul 2012 07:36:17 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7CE21F85E4 for ; Mon, 16 Jul 2012 07:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6186710185A for ; Mon, 16 Jul 2012 16:39:55 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spMC+mW9p3mb for ; Mon, 16 Jul 2012 16:39:55 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 4662A101859 for ; Mon, 16 Jul 2012 16:39:50 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.121]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 16:37:22 +0200 From: Rolf Winter To: multipathtcp Thread-Topic: new version of MPTCP for single-homed end systems Thread-Index: Ac1jYIFqoXaWyAuLTZynw3s9+PSEUQ== Date: Mon, 16 Jul 2012 14:37:20 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D32DFD85F@Polydeuces.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [multipathtcp] new version of MPTCP for single-homed end systems 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, 16 Jul 2012 14:36:18 -0000 Hi, we have just published a new version of the document that describes how to = allow single-homed MPTCP-capable end-systems to exploit multiple paths in t= he network. http://tools.ietf.org/id/draft-wr-mptcp-single-homed-03.txt Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From alanford@cisco.com Mon Jul 16 09:20: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 13DF021F8543 for ; Mon, 16 Jul 2012 09:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Uk6TwO7BlZP for ; Mon, 16 Jul 2012 09:20:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2139621F8533 for ; Mon, 16 Jul 2012 09:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=3273; q=dns/txt; s=iport; t=1342455684; x=1343665284; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jsqEeyHm54T5kYn+7b+s+2GXx1t/rsd5Si2+pS9UJuM=; b=HexI3za3KK7Yqw2TCF3q+vI/PhnpLKmlFeZceLfASwBOP3oRjvrI0ecC HlIlswdqfQzazBPYya0GMh/0Tul7lXIwYUcgHmwjCLdxTmTD7ShYeAv2t jBtxuFuXbe6ylaxgIx9S4LeepbiqvOR0yK12fV1yynilfxBvtdIEiprBe 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAE0+BFCtJXG+/2dsb2JhbABFuTmBB4IgAQEBBAEBAQ8BFEcLEgEIGAxJCyUCBA4FIodrC5wzn22LQIZHA4gWjSWBEo0OgWaCX4FWBQ X-IronPort-AV: E=Sophos;i="4.77,594,1336348800"; d="scan'208";a="102318014" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2012 16:21:23 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6GGLNQI003624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jul 2012 16:21:23 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.204]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 11:21:23 -0500 From: "Alan Ford (alanford)" To: Christoph Paasch , "Hampel, K Georg (K Georg)" Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1WI+Dp/haF4AVDRoS7OtIAVF6w+wA95giAAAyBLuD//6NNgP//+weAgAJz/YCAAF8iAIAACV+AgALaroCAABu7AIAAI/MAgAAE6YCAAYgQgIAAAf8AgBGDdYA= Date: Mon, 16 Jul 2012 16:21:21 +0000 Message-ID: In-Reply-To: <5163084.8fW8eOkCyj@cpaasch-mac> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.147.93.95] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.006 x-tm-as-result: No--43.023400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9420BDB4F96BBA4A80902C9AE536E90C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 16 Jul 2012 16:20:40 -0000 All, I've been considering how to reconcile the recent discussions in the draft as it stands. On Page 25 we already mention something in this area, but it does not cover all cases we have discussed. In particular, it currently says: Implementations MAY hold onto such unmapped data for a short while in the expectation that a mapping will arrive shortly. [...] If a mapping for that subflow-level sequence space does not arrive within a receive window of data, that subflow SHOULD be treated as broken, closed with an RST, and any unmapped data silently discarded. However, I'm not sure this really works. If a mapping was sent on a duplicate ACK, this may not be discovered in time (by the lack of a DATA ACK within said window). Maybe this actually needs to be one 2*receive_window? Given the recent feedback, it looks like we also need to add more constraints. For a simple requirement, how about we add: A mapping for subflow seqno x MUST not be sent before the mappings for subflow seqno 0 .. x-1 have been sent. This shouldn't affect normal operation, since in the event of lost packets the subflow will handle the re-ordering before it gets to MPTCP processing. Later requirements discussed included: a) A mapping MUST appear, at latest, in the segment where is the first byte it covers is. b) If a DSS-mapping goes from x -> y in the subflow-seqno space, the DSS-option MUST be on one of these segments. However, the latter of these prevents a duplicate ACK giving a mapping being used before the data; and the former prevents preemptive mappings entirely. I do not see we have reached a particular consensus of what restrictions we want to place on preemptive mappings. Can we refine anything here to ensure a manageable and deterministic behaviour? Regards, Alan On 05/07/2012 14:54, "Christoph Paasch" wrote: >On Thursday 05 July 2012 08:47:03 Hampel, K Georg wrote: >> It is not known how packet-re-segmenting middleboxes align DSS and >>payload. >> When packet-re-segmentation occurs the DSS mapping may arrive earlier at >> the receiver than the corresponding payload. > >How could this happen? Can you give an example with sequence-numbers, >where=20 >the DSS is not on one of the packets whose sequence-numbers he belongs to. > >What I mean is: > >If a packet with DSS-mapping x -> y and subflow-seq-no x comes at the >middlebox. >How could the middlebox resegment this packet so that the DSS-mapping is >on=20 >packet with subflow-seq-no x-1 ? >This is a very buggy middlebox in my opinion, as it is sending a segment >(x-1)=20 >that has already passed by this middlebox in the past. > > >Christoph > > >> Therefore, as long as we subscribe to the assumption that >> packet-re-segmenting middleboxes exist, the implementation needs to >>support >> preemptive mappings. > > > >--=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 >-- >_______________________________________________ >multipathtcp mailing list >multipathtcp@ietf.org >https://www.ietf.org/mailman/listinfo/multipathtcp From touch@isi.edu Mon Jul 16 14:04:07 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 5327311E80C9 for ; Mon, 16 Jul 2012 14:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26azntM7Jgvs for ; Mon, 16 Jul 2012 14:04:06 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7D91F11E80BD for ; Mon, 16 Jul 2012 14:04:06 -0700 (PDT) Received: from [75.248.108.153] (153.sub-75-248-108.myvzw.com [75.248.108.153]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q6GL4Pja004331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Jul 2012 14:04:32 -0700 (PDT) Message-ID: <500481DA.8060008@isi.edu> Date: Mon, 16 Jul 2012 14:04:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mahesh M References: <6E004C34C1C59E45A35B4338808BC31501300E3FB8D6@SJCPMAILBOX01.citrite.net> In-Reply-To: <6E004C34C1C59E45A35B4338808BC31501300E3FB8D6@SJCPMAILBOX01.citrite.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] MPTCP checksum 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, 16 Jul 2012 21:04:07 -0000 On 7/11/2012 11:55 AM, Mahesh M wrote: > Hi, > > For internet checksum calculation either we can use 16bit, 32bit or > 64bit words and we need to fold the sum at the end and add the carry. You need to add the carry back at each word you add as you accumulate the sum. > For parallelism when we make choice of 32bit or 64bit accumulators, we > usually we choose 64bit when native register size is 64bits. > > IPv4/IPv6 packet cannot go beyond 64KB (i.e. including IP and TCP > headers), so TCP checksum theoretically cannot wrap around 32bit value It sure can - it can wrap nearly every 32-bit value you add in. That's the carry that could happen at each word you sum in. > and use of 64 bit accumulator gives us parallelism. But MPTCP checksum > mapping can be 64KB-1 + 16bytes of pseudo header which can overflow > 32bit value. If my understanding is correct then we need to use 64bit > accumulator if our checksum calculation. You cannot overflow a 1's complement sum. You merely keep adding the carry back in. It's "circular". What you do is compute 64-bit ones-complement sums as you go, and then fold into a 16-bit sum later. That works because summation is commutative, even in 1's complement. See any of the numerous RFCs on computing the IP checksum for further information. Joe > > Any comments on this? > > Regards, > > Mahesh > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From nishida@sfc.wide.ad.jp Tue Jul 17 00:33:34 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 2BF0A21F8539 for ; Tue, 17 Jul 2012 00:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.602 X-Spam-Level: X-Spam-Status: No, score=-101.602 tagged_above=-999 required=5 tests=[AWL=0.374, 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 TokBmff2T1-S for ; Tue, 17 Jul 2012 00:33:33 -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 3656F21F8533 for ; Tue, 17 Jul 2012 00:33:30 -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 CE2D9278086 for ; Tue, 17 Jul 2012 16:34:14 +0900 (JST) Received: by lbbgo11 with SMTP id go11so295839lbb.31 for ; Tue, 17 Jul 2012 00:34:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.101.196 with SMTP id fi4mr715393lbb.67.1342510452005; Tue, 17 Jul 2012 00:34:12 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Tue, 17 Jul 2012 00:34:11 -0700 (PDT) Date: Tue, 17 Jul 2012 00:34:11 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=f46d0401682b995b2104c50192b1 Subject: [multipathtcp] agenda draft 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: Tue, 17 Jul 2012 07:33:34 -0000 --f46d0401682b995b2104c50192b1 Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, Below is the current plan for vancouver meeting. if you are planning to make a presentation other than this, or if you have some topics to be discussed at the meeting, please let us know. Thanks, -- Yoshifumi & Phil Draft agenda for MPTCP WG - Intro and status updates - Chairs - Updates for protocol and API doc - Alan Ford - MPTCP for single-homed end systems - Rolf Winter - Multipath TCP implementation in FreeBSD - Grenville Armitage - Performance Issues with MPTCP - Ramin Khalili ------- Reading: http://tools.ietf.org/html/draft-ietf-mptcp-api-05 http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-09 http://tools.ietf.org/html/draft-wr-mptcp-single-homed-03 http://tools.ietf.org/html/draft-khalili-mptcp-performance-issues-00 --f46d0401682b995b2104c50192b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Hi Folks,

Below is the current plan for vancouver meeting. 
=
if you are planning to make a presentation other than this, or if you have =
some topics to be discussed at the meeting, please let us know.

Thanks,
--
Yoshifumi & Phil


Draft agenda for MPTCP=
 WG

 - Intro and status updates - Chairs=20

 - Updates for protocol and API doc - Alan Ford

 - MPTCP for single-homed end systems - Rolf Winter

 - Multipath TCP=
 implementation in FreeBSD - Grenville Armitage

 - Performance Issue=
s with MPTCP - Ramin Khalili

-------
Reading:

http://tools=
.ietf.org/html/draft-ietf-mptcp-api-05 
http://tools.ietf.org/html/dr=
aft-ietf-mptcp-multiaddressed-09

http:=
//tools.ietf.org/html/draft-wr-mptcp-single-homed-03 
http://t=
ools.ietf.org/html/draft-khalili-mptcp-performance-issues-00

=A0
--f46d0401682b995b2104c50192b1-- From njwilliams@swin.edu.au Thu Jul 19 03:12:49 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F8021F87BD for ; Thu, 19 Jul 2012 03:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 HxD-9fhwfhSR for ; Thu, 19 Jul 2012 03:12:48 -0700 (PDT) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by ietfa.amsl.com (Postfix) with ESMTP id 79BE321F8769 for ; Thu, 19 Jul 2012 03:12:47 -0700 (PDT) Received: from [136.186.229.154] (nwilliams-laptop.caia.swin.edu.au [136.186.229.154]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id q6JADcnW024475 for ; Thu, 19 Jul 2012 20:13:39 +1000 Message-ID: <5007DDC3.1000003@swin.edu.au> Date: Thu, 19 Jul 2012 20:13:23 +1000 From: Nigel Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multipathtcp] Reasons DSS checksum including covered data 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, 19 Jul 2012 10:12:49 -0000 Hi all, Since this is my first post, a quick introduction. My name is Nigel Williams and I'm currently working at Swinburne University on our newTCP project [1]. As part of this project I am working on an implementation of MPTCP for FreeBSD. After looking through the draft [2] section on Data Sequence Mapping (3.3.1), it still isn't clear to me as to why a checksum needs to be calculated over the DSS psuedo header plus the data for that mapping. I understand why the pseudo header might require a checksum, just not why the data covered by the mapping needs it (given that the TCP checksum covers the payload in each transmitted packet). A similar question was raised in a previous thread as part of a different discussion [3], but going through the replies I wasn't able to find an exact answer: >> [GH] I was under the impression that the checksum applies to the packet >> only. In my opinion this would make things much simpler. Is there a >> specific reason to apply the checksum to the entire bulk rather than >> solely the packet? Things would get much simpler if the checksum were >> packet-specific. >If the DSS-mapping covers multiple packets, the checksum in the DSS-option is >on the whole payload of these packets plus the pseudo-header. I might be missing something here, so if anyone has some further detail that would be great. regards, nigel [1] caia.swin.edu.au/newtcp [2] draft-ietf-mptcp-multiaddressed-09 [3] http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01483.html From olivier.bonaventure@uclouvain.be Thu Jul 19 04:15:33 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 9B31E21F8776 for ; Thu, 19 Jul 2012 04:15:33 -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 fBOEEyWqjgbu for ; Thu, 19 Jul 2012 04:15:32 -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 B5B0021F8769 for ; Thu, 19 Jul 2012 04:15:32 -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 BF33811E798; Thu, 19 Jul 2012 13:16:15 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be BF33811E798 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1342696575; bh=EcfILbV8Db017ttFs/TGydwSshH1aov6dUEr/fhhSE0=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YV1RHLvWl+5I3B3qHCuiDJWq0ZyD4FVrS7zSMnafhbTNRxv2Z9a2gS7RzXvIExI1k m1h0EvTaR16PQBL6xfZftfFgmhDcMsgi7JAiGjbYmXBCTFdb4X7uTFqAJEqK+3c0yc 1JjR3Lij55sOOfG9ebMri2lE6zk/E3EeDMB8CgFE= Message-ID: <5007EC7F.6080300@uclouvain.be> Date: Thu, 19 Jul 2012 13:16:15 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nigel Williams References: <5007DDC3.1000003@swin.edu.au> In-Reply-To: <5007DDC3.1000003@swin.edu.au> X-Enigmail-Version: 1.4.2 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: BF33811E798.A448F X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] Reasons DSS checksum including covered data 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: Thu, 19 Jul 2012 11:15:33 -0000 Nigel, > > Since this is my first post, a quick introduction. My name is Nigel > Williams and I'm currently working at Swinburne University on our newTCP > project [1]. As part of this project I am working on an implementation > of MPTCP for FreeBSD. Nice to see this project started. > After looking through the draft [2] section on Data Sequence Mapping > (3.3.1), it still isn't clear to me as to why a checksum needs to be > calculated over the DSS psuedo header plus the data for that mapping. I > understand why the pseudo header might require a checksum, just not why > the data covered by the mapping needs it (given that the TCP checksum > covers the payload in each transmitted packet). > > A similar question was raised in a previous thread as part of a > different discussion [3], but going through the replies I wasn't able to > find an exact answer: The main motivation for having a DSS checksum that covers the payload is to handle NATs with an ALG. Consider a NAT that performs ALG for FTP. If MPTCP passes through this NAT, the ALG might modify the payload of the control connection of ftp to change the IP addresses. If the private address is 10.0.0.1 and the public one 123.145.167.189, then the payload will need to be expanded since ftp sends IP addresses in ASCII in the ftp-control connection. This would change the mapping between the subflow sequence number and the MPTCP DSS... The checksum is there to detect this case (and similar ones with other protocols than FTP) You can find an explanation of some of the design decisions for MPTCP in our NSDI12 paper https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Thu Jul 19 05:12:28 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997EB21F876A for ; Thu, 19 Jul 2012 05:12:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwtkUWtptwtT for ; Thu, 19 Jul 2012 05:12:27 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2D421F8759 for ; Thu, 19 Jul 2012 05:12:27 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6JCD1Yq014514 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Jul 2012 14:13:17 +0200 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Jul 2012 14:12:54 +0200 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.31]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 19 Jul 2012 08:12:51 -0400 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" , Nigel Williams Thread-Topic: [multipathtcp] Reasons DSS checksum including covered data Thread-Index: AQHNZZc1lgxY5dcGpESlM+kjJv3YkZcwt7KA///Ll9A= Date: Thu, 19 Jul 2012 12:12:50 +0000 Message-ID: References: <5007DDC3.1000003@swin.edu.au> <5007EC7F.6080300@uclouvain.be> In-Reply-To: <5007EC7F.6080300@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: multipathtcp Subject: Re: [multipathtcp] Reasons DSS checksum including covered data 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, 19 Jul 2012 12:12:28 -0000 Nigel, Olivier, all, Are there any other examples apart from FTP where payload rewriting is done= ? Are there any trials that show payload-rewriting? Thanks, Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Olivier Bonaventure Sent: Thursday, July 19, 2012 7:16 AM To: Nigel Williams Cc: multipathtcp Subject: Re: [multipathtcp] Reasons DSS checksum including covered data Nigel, >=20 > Since this is my first post, a quick introduction. My name is Nigel > Williams and I'm currently working at Swinburne University on our newTCP > project [1]. As part of this project I am working on an implementation > of MPTCP for FreeBSD. Nice to see this project started. > After looking through the draft [2] section on Data Sequence Mapping > (3.3.1), it still isn't clear to me as to why a checksum needs to be > calculated over the DSS psuedo header plus the data for that mapping. I > understand why the pseudo header might require a checksum, just not why > the data covered by the mapping needs it (given that the TCP checksum > covers the payload in each transmitted packet). >=20 > A similar question was raised in a previous thread as part of a > different discussion [3], but going through the replies I wasn't able to > find an exact answer: The main motivation for having a DSS checksum that covers the payload is to handle NATs with an ALG. Consider a NAT that performs ALG for FTP. If MPTCP passes through this NAT, the ALG might modify the payload of the control connection of ftp to change the IP addresses. If the private address is 10.0.0.1 and the public one 123.145.167.189, then the payload will need to be expanded since ftp sends IP addresses in ASCII in the ftp-control connection. This would change the mapping between the subflow sequence number and the MPTCP DSS... The checksum is there to detect this case (and similar ones with other protocols than FTP) You can find an explanation of some of the design decisions for MPTCP in our NSDI12 paper https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-i= mplementing-deployable-multipath-tcp Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nishida@sfc.wide.ad.jp Tue Jul 24 22:51:39 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF821F84F3 for ; Tue, 24 Jul 2012 22:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVs7oQpAJfld for ; Tue, 24 Jul 2012 22:51:39 -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 43EAD21F84EE for ; Tue, 24 Jul 2012 22:51:38 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3FFBE27808D for ; Wed, 25 Jul 2012 14:51:27 +0900 (JST) Received: by lagv3 with SMTP id v3so253191lag.31 for ; Tue, 24 Jul 2012 22:51:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.104.47 with SMTP id gb15mr24284261lab.45.1343195485737; Tue, 24 Jul 2012 22:51:25 -0700 (PDT) Received: by 10.112.131.39 with HTTP; Tue, 24 Jul 2012 22:51:25 -0700 (PDT) Date: Tue, 24 Jul 2012 22:51:25 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Cc: mptcp-chairs@tools.ietf.org Subject: [multipathtcp] MPTCP meeting agenda 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, 25 Jul 2012 05:51:39 -0000 Hello, I have uploaded the meeting agenda at: https://datatracker.ietf.org/meeting/84/agenda/mptcp/ For presenters, please send your slides to me & phil by Monday(7/30) afternoon. We appreciate your cooperation. Thanks, -- Yoshifumi & Phil From nishida@sfc.wide.ad.jp Thu Jul 26 00:23:36 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 C11D721F8606 for ; Thu, 26 Jul 2012 00:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.689 X-Spam-Level: X-Spam-Status: No, score=-101.689 tagged_above=-999 required=5 tests=[AWL=0.287, 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 tSusoHNJxJ7V for ; Thu, 26 Jul 2012 00:23:36 -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 14FB021F85D4 for ; Thu, 26 Jul 2012 00:23:35 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 37FBD27808D for ; Thu, 26 Jul 2012 16:23:32 +0900 (JST) Received: by lagv3 with SMTP id v3so1184280lag.31 for ; Thu, 26 Jul 2012 00:23:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.54.100 with SMTP id i4mr12952972lbp.97.1343287410596; Thu, 26 Jul 2012 00:23:30 -0700 (PDT) Received: by 10.112.131.39 with HTTP; Thu, 26 Jul 2012 00:23:30 -0700 (PDT) Date: Thu, 26 Jul 2012 00:23:30 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=bcaec55400eef09aee04c5b678f0 Subject: [multipathtcp] comments on 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, 26 Jul 2012 07:23:36 -0000 --bcaec55400eef09aee04c5b678f0 Content-Type: text/plain; charset=ISO-8859-1 Hello, I have read draft-khalili-mptcp-performance-issues-00. I think this draft contains interesting points. The followings are my comments on the draft. 1: Section 2: "The idea behind the algorithm is to transmit over a path r at a rate proportional to p_r^{-1/epsilon}, where p_r is the loss probability over this link and epsilon is a design parameter. " -> it seems to me that p_r is independent value on each path. So, I'm wondering how to adjust coupled algorithm by tweaking epsilon in this equation. Also, I'm not very sure how to determine the value where epsilon = 0 2: Have you tried larger number of connections? In the draft, the number of connections are less then 30. But, it might be better to see using large number can affect the results. 3: It is obviously not necessary to describe the detail logic in OLIA. But, I would like to see the basic essence of OLIA so that we can intuitively understand why OLIA can mitigate flappiness and unfairness. Thanks, -- Yoshifumi Nishida --bcaec55400eef09aee04c5b678f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I have read draft-khalili-mptcp-performance-issues-00.
I= think this draft contains interesting points. The followings are my commen= ts on the draft.

1:=A0 Section 2: "The idea behind the algorith= m is to transmit over a path r at a rate proportional to
=A0 =A0 =A0 =A0p_r^{-1/epsilon}, where p_r is the loss probability over thi= s link and epsilon is a design parameter. "
=A0
=A0=A0=A0 ->= it seems to me that p_r is independent value on each path. So, I'm won= dering how to adjust coupled algorithm by tweaking epsilon in this equation= . Also, I'm not very sure how to determine the value where epsilon =3D = 0

2: Have you tried larger number of connections? In the draft, the numbe= r of connections are less then 30.
=A0=A0=A0 But, it might be better to= see using large number can affect the results.

3: It is obviously n= ot necessary to describe the detail logic in OLIA. But, I would like to see= the basic essence of OLIA so that we can intuitively understand why OLIA c= an mitigate flappiness and unfairness.

Thanks,
--
Yoshifumi Nishida
--bcaec55400eef09aee04c5b678f0-- From ramin.khalili@epfl.ch Fri Jul 27 03:13:17 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 E0ED921F8629 for ; Fri, 27 Jul 2012 03:13:17 -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=[AWL=-0.000, 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 r0esI++BRgXc for ; Fri, 27 Jul 2012 03:13:17 -0700 (PDT) Received: from smtp0.epfl.ch (smtp0.epfl.ch [128.178.224.219]) by ietfa.amsl.com (Postfix) with SMTP id 0AD3021F85FC for ; Fri, 27 Jul 2012 03:13:15 -0700 (PDT) Received: (qmail 29180 invoked by uid 107); 27 Jul 2012 10:13:13 -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; Fri, 27 Jul 2012 12:13:13 +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; Fri, 27 Jul 2012 12:12:11 +0200 From: Khalili Ramin To: Yoshifumi Nishida , multipathtcp Thread-Topic: [multipathtcp] comments on draft-khalili-mptcp-performance-issues-00 Thread-Index: AQHNav958WJPAZJfyUGwM2UYnYZsnpc86dBC Date: Fri, 27 Jul 2012 10:11:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.178.151.233] Content-Type: multipart/alternative; boundary="_000_B20442DB7A739B4CB083DA0F24635C2F29EA2AC0REXMEintranetep_" MIME-Version: 1.0 Subject: Re: [multipathtcp] comments on 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: Fri, 27 Jul 2012 10:13:18 -0000 --_000_B20442DB7A739B4CB083DA0F24635C2F29EA2AC0REXMEintranetep_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Yoshifumi, Thanks for your comments and feedbacks. I think that we can easily incorpo= rate the answers to your first and last questions in a new version of the = draft. However, the second question would require more work (see below). 1. The design of the congestion control algorithm of MPTCP is described in = the slides http://www.ietf.org/proceedings/77/slides/mptcp-9.pdf: The actual implementation of the congestion control algorithm, called LIA, = increases the window size on each ACK of a quantity proportional to w_r /w_= tot (see [slide 3]). This results in sending a traffic proportional to 1/p_= r on a path that has a probability loss p_r. LIA is a trade off between load balancing and non-flappiness. It is one of = a family of multipath congestion control algorithms (see slide 9) that can = be indexed by a parameter epsilon\in(0,2) (phi in [slide 9]). These algorit= hms results in sending a traffic proportional to (1/p_r)^(1/epsilon). - If epsilon is very close to zero, then LIA would transmit only over the p= ath with smallest loss rate, e.g. if p2>p1then w2=3D0 and w1>0 (LIA transmi= ts only over path 1). - epsilon=3D2 corresponds to having uncoupled TCP flows on each of the path= . - epsilon=3D1 correspond to LIA and is described in (RFC6356 [4]). 2: Because of some practical issues, we did not study larger number of conn= ections in our testbed. However, we have mathematical results (using LIA=92= s loss-throughput formula [12]) as well as simulation results (using a flow= -level simulator) that confirm our observation for larger number of connections. 3. Similarly to LIA, OLIA couples the additive increases and uses unmodifie= d TCP behavior in the case of a loss. The difference between LIA and OLIA i= s in the increase part. OLIA's increase part two has terms: - The first term is an adaptation of the increase term of the optimal algor= ithm in [7]. This term is essential to provide congestion balancing and fai= rness. - The second term guarantees responsiveness and non-flappiness of OLIA. By = measuring the number of transmitted bytes since the last loss, it reacts to= events within the current window and adapts to changes faster than the fir= st term. Because OLIA is rooted in the optimal algorithm of [7], it can provide fair= ness and congestion balancing. Because of the second term, it is responsive= and non-flappy. I hope the answers are clear and I would be very happy to receive further q= uestions and comments about the work. Regards, Ramin. ________________________________ From: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] on beha= lf of Yoshifumi Nishida [nishida@sfc.wide.ad.jp] Sent: Thursday, July 26, 2012 9:23 AM To: multipathtcp Subject: [multipathtcp] comments on draft-khalili-mptcp-performance-issues-= 00 Hello, I have read draft-khalili-mptcp-performance-issues-00. I think this draft contains interesting points. The followings are my comme= nts on the draft. 1: Section 2: "The idea behind the algorithm is to transmit over a path r = at a rate proportional to p_r^{-1/epsilon}, where p_r is the loss probability over this link a= nd epsilon is a design parameter. " -> it seems to me that p_r is independent value on each path. So, I'm w= ondering how to adjust coupled algorithm by tweaking epsilon in this equati= on. Also, I'm not very sure how to determine the value where epsilon =3D 0 2: Have you tried larger number of connections? In the draft, the number of= connections are less then 30. But, it might be better to see using large number can affect the result= s. 3: It is obviously not necessary to describe the detail logic in OLIA. But,= I would like to see the basic essence of OLIA so that we can intuitively u= nderstand why OLIA can mitigate flappiness and unfairness. Thanks, -- Yoshifumi Nishida --_000_B20442DB7A739B4CB083DA0F24635C2F29EA2AC0REXMEintranetep_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Dear Yoshifumi,

Thanks for your comments and feedbacks. I think that we can easily  in= corporate the answers to your first and last questions in a new  versi= on of the draft. However, the second question would require more work (see = below).

1. The design of the congestion control algorithm of MPTCP is described in = the slides http://www.ietf.org/proceedi= ngs/77/slides/mptcp-9.pdf:

The actual implementation of the congestion control algorithm, called LIA, = increases the window size on each ACK of a quantity proportional to w_r /w_= tot (see [slide 3]). This results in sending a traffic proportional to 1/p_= r on a path that has a probability loss p_r.

LIA is a trade off between load balancing and non-flappiness. It is one of = a family of multipath congestion control algorithms (see slide 9) that can = be indexed by a parameter epsilon\in(0,2) (phi in [slide 9]). These algorit= hms results in sending a traffic proportional to (1/p_r)^(1/epsilon).
- If epsilon is very close to zero, then LIA would transmit only over the p= ath with smallest loss rate, e.g. if p2>p1then w2=3D0 and w1>0 (LIA t= ransmits only over path 1).
- epsilon=3D2 corresponds to having uncoupled TCP flows on each of the path= .
- epsilon=3D1 correspond to LIA and is described in (RFC6356 [4]).

2: Because of some practical issues, we did not study larger number of conn= ections in our testbed. However, we have mathematical results (using LIA=92= s loss-throughput formula [12]) as well as simulation results (using a flow= -level simulator) that confirm our observation for larger number
of connections.

3. Similarly to LIA, OLIA couples the additive increases and uses unmodifie= d TCP behavior in the case of a loss. The difference between LIA and OLIA i= s in the increase part.

OLIA's increase part two has terms:
- The first term is an adaptation of the increase term of the optimal algor= ithm in [7]. This term is essential to provide congestion balancing and fai= rness.
- The second term guarantees responsiveness and non-flappiness of OLIA. By = measuring the number of transmitted bytes since the last loss, it reacts to= events within the current window and adapts to changes faster than the fir= st term.

Because OLIA is rooted in the optimal algorithm of [7], it can provide fair= ness and congestion balancing. Because of the second term, it is responsive= and non-flappy.

I hope the answers are clear and I would be very happy to receive further q= uestions and comments about the work.

Regards,
Ramin.
From: multipathtcp-bounces@ietf.org [mult= ipathtcp-bounces@ietf.org] on behalf of Yoshifumi Nishida [nishida@sfc.wide= .ad.jp]
Sent: Thursday, July 26, 2012 9:23 AM
To: multipathtcp
Subject: [multipathtcp] comments on draft-khalili-mptcp-performance-= issues-00

Hello,

I have read draft-khalili-mptcp-performance-issues-00.
I think this draft contains interesting points. The followings are my comme= nts on the draft.

1:  Section 2: "The idea behind the algorithm is to transmit over= a path r at a rate proportional to
       p_r^{-1/epsilon}, where p_r is the loss probabil= ity over this link and epsilon is a design parameter. "
 
    -> it seems to me that p_r is independent value on ea= ch path. So, I'm wondering how to adjust coupled algorithm by tweaking epsi= lon in this equation. Also, I'm not very sure how to determine the value wh= ere epsilon =3D 0

2: Have you tried larger number of connections? In the draft, the number of= connections are less then 30.
    But, it might be better to see using large number can af= fect the results.

3: It is obviously not necessary to describe the detail logic in OLIA. But,= I would like to see the basic essence of OLIA so that we can intuitively u= nderstand why OLIA can mitigate flappiness and unfairness.

Thanks,
--
Yoshifumi Nishida
--_000_B20442DB7A739B4CB083DA0F24635C2F29EA2AC0REXMEintranetep_-- From mglt.ietf@gmail.com Sun Jul 29 21:59:56 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 4C65B11E8098; Sun, 29 Jul 2012 21:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[AWL=5.150, 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 ptel42S0Lg5N; Sun, 29 Jul 2012 21:59:55 -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 19CE711E808D; Sun, 29 Jul 2012 21:59:55 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9609513obb.31 for ; Sun, 29 Jul 2012 21:59:54 -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=zE2BOgMcSpohu0AoLjHeV/XRKjY3/49Dv5K3z1cJR48=; b=hXCXCgwPe/jpwPn+pACfBv8Kyn0AAk5gX+gKZqg4XrAL5cOaY72l3SIDVqXtsh4snN e3DkE87h/RQlOOrjoPaK8fb7ZZCcsJ73sZYxJQhHbX8RYdWcyZk2DlWnIN63mjXDqde1 xTinItLbZzVU6U6GQxNKKYYrVRScCQHoAe1fWckkIQHvnlnHGVRBrb4ap8ia2/op5KAR locmyhwnRAuDbeBhqL15yrS+sE0zuERCFsM1ujz2/mdaKARtU5hA5HrrpIqt7ImuC+Qo PvYnJPY0/olHAEg2zr0mhk1te1RXuy5a5mx0F0wPwKETmu3uzTI6Cd/lvXUgWCem6H2V dnVw== MIME-Version: 1.0 Received: by 10.182.225.100 with SMTP id rj4mr15428142obc.64.1343624394569; Sun, 29 Jul 2012 21:59:54 -0700 (PDT) Received: by 10.182.196.38 with HTTP; Sun, 29 Jul 2012 21:59:54 -0700 (PDT) In-Reply-To: <20120730045037.978.65071.idtracker@ietfa.amsl.com> References: <20120730045037.978.65071.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 06:59:54 +0200 Message-ID: From: Daniel Migault To: mif@ietf.org, ipsec@ietf.org, multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=14dae93993bbbff99004c604eed1 Subject: [multipathtcp] Fwd: 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: Mon, 30 Jul 2012 04:59:56 -0000 --14dae93993bbbff99004c604eed1 Content-Type: text/plain; charset=ISO-8859-1 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 --14dae93993bbbff99004c604eed1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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>
= 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: <= a href=3D"mailto:carlw@mcsr-labs.org">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: =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 -- Sec= urity
+33 6 70 72 69 58
--14dae93993bbbff99004c604eed1-- From iesg-secretary@ietf.org Tue Jul 31 10:34: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 8700521F880E; Tue, 31 Jul 2012 10:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 51PtfalrkWtM; Tue, 31 Jul 2012 10:34:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0459F21F8809; Tue, 31 Jul 2012 10:34:46 -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: <20120731173446.9707.33562.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2012 10:34:46 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] Last Call: (MPTCP Application Interface Considerations) to Informational 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: Tue, 31 Jul 2012 17:34:46 -0000 The IESG has received a request from the Multipath TCP WG (mptcp) to consider the following document: - 'MPTCP Application Interface Considerations' as Informational 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-14. 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 Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface which is a simple extension of TCP's interface for MPTCP-aware applications. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ballot/ No IPR declarations have been submitted directly on this I-D. From ietf-ipr@ietf.org Tue Jul 31 10:25:52 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 C4C7F21F8764; Tue, 31 Jul 2012 10:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 7g9ya59Tg2P3; Tue, 31 Jul 2012 10:25:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACB521F8726; Tue, 31 Jul 2012 10:25:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: alanford@cisco.com, costin.raiciu@cs.pub.ro, m.handley@cs.ucl.ac.uk, Olivier.Bonaventure@uclouvain.be X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120731172552.17220.80681.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2012 10:25:52 -0700 X-Mailman-Approved-At: Tue, 31 Jul 2012 10:58:04 -0700 Cc: multipathtcp@ietf.org, ipr-announce@ietf.org Subject: [multipathtcp] IPR Disclosure: Georg Hampel's Statement about IPR related to draft-ietf-mptcp-multiaddressed-09 belonging to Sun Microsystems X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:25:53 -0000 Dear Alan Ford, Costin Raiciu, Mark J. Handley, Olivier Bonaventure: An IPR disclosure that pertains to your Internet-Draft entitled "TCP Exten= sions for Multipath Operation with Multiple Addresses" (draft-ietf-mptcp- multiaddressed) was submitted to the IETF Secretariat on 2012-07-31 and has= been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1842/). The title of the IPR disclosure is "Georg Hampel's Statement about IPR related to draft-ietf-mptcp- multiaddressed-09 belonging to Sun Microsystems.""); The IETF Secretariat From ietf-ipr@ietf.org Tue Jul 31 15:13:29 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 BB57A11E8139; Tue, 31 Jul 2012 15:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 b8MJH+u2dSpt; Tue, 31 Jul 2012 15:13:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5285321F8867; Tue, 31 Jul 2012 15:13:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: alanford@cisco.com, costin.raiciu@cs.pub.ro, m.handley@cs.ucl.ac.uk, Olivier.Bonaventure@uclouvain.be X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120731221329.27662.70568.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2012 15:13:29 -0700 X-Mailman-Approved-At: Tue, 31 Jul 2012 15:33:14 -0700 Cc: multipathtcp@ietf.org, ipr-announce@ietf.org Subject: [multipathtcp] IPR Disclosure: Georg Hampel's Statement about IPR related to draft-ietf-mptcp-multiaddressed-09 belonging to Asankya Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:13:29 -0000 Dear Alan Ford, Costin Raiciu, Mark J. Handley, Olivier Bonaventure: An IPR disclosure that pertains to your Internet-Draft entitled "TCP Exten= sions for Multipath Operation with Multiple Addresses" (draft-ietf-mptcp- multiaddressed) was submitted to the IETF Secretariat on 2012-07-31 and has= been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1843/). The title of the IPR disclosure is "Georg Hampel's Statement about IPR related to draft-ietf-mptcp- multiaddressed-09 belonging to Asankya Networks.""); The IETF Secretariat From mark.j.handley@gmail.com Tue Jul 31 17:08:24 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 53FC221F872D for ; Tue, 31 Jul 2012 17:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 HKWlMCVz1T-7 for ; Tue, 31 Jul 2012 17:08:23 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 988DF21F8722 for ; Tue, 31 Jul 2012 17:08:23 -0700 (PDT) Received: by ggnc4 with SMTP id c4so7246759ggn.31 for ; Tue, 31 Jul 2012 17:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=XGKZ0AEgW2KgBYHv/E7vo13SYBw+9q0o4thPmOVc+cA=; b=FXdgY5Ih3w9tLB/TRxq3ynu+5F7xlDf/8SVG82tHfh3p1Q22ZQYxv02O1LnVtU3TmQ nUXMmNVSssmM25NARBGqvmma1MvPlDR7mfXzNeQTQ6jfwiFID9/6V5H09AXsZvbfOjFC C06eeHN67dPZYYucyMsGe1pIBtbRIwr/t8cj9s8BwEb/NoKzECx8BOxWUpoHovDZ2E/H tCBLCAimxGlsEGAvGBK50yQIZInRtzwufmKFeKOQbwYwvKYHdf90Lfg7D1EQDLx8qQuq WaV+1hp7DHkffbSa+BL22ZQQRHKdoDtiId/2OUBSDtsj99Q0MSpQR8uFYmLmQvd3ePst 8khg== Received: by 10.236.161.165 with SMTP id w25mr15480608yhk.22.1343779703206; Tue, 31 Jul 2012 17:08:23 -0700 (PDT) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.236.185.36 with HTTP; Tue, 31 Jul 2012 17:08:03 -0700 (PDT) In-Reply-To: <20120731221329.27662.70568.idtracker@ietfa.amsl.com> References: <20120731221329.27662.70568.idtracker@ietfa.amsl.com> From: Mark Handley Date: Wed, 1 Aug 2012 01:08:03 +0100 X-Google-Sender-Auth: ahdUz6NtMrhUBlHshWGCtW9f0Ho Message-ID: To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: costin.raiciu@cs.pub.ro Subject: Re: [multipathtcp] IPR Disclosure: Georg Hampel's Statement about IPR related to draft-ietf-mptcp-multiaddressed-09 belonging to Asankya Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mark@handley.org.uk 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 00:08:24 -0000 This one is United States Patent Application 20080062879 from Raghupathy Sivakumar et al. It seems unlikely that a pure end-system implementation of MPTCP would infringe the claims of this patent application, as they refer only to a transport-level proxy. If this patent were asserted against an MPTCP end-system implementation, the claim construction would have to be so broad that the mass of MPTCP prior art would be highly likely to invalidate the patent. Sivakumar was one of the authors of pTCP, from 2002 or so, that is part of that prior art. They don't cite pTCP, so they cannot believe it is directly relevant. A proxy implementation of MPTCP might infringe though. If the patent examiner is smart, he/she will reject the application because a conventional server load balancer would infringe claim 1 (and probably many of the other claims), and server load balancers pre-date the priority date by a lot. There seems to be plenty of other prior art too. For example: http://dl.acm.org/citation.cfm?id=1104348 But patent examiners don't really have time to search the literature. - Mark On 31 July 2012 23:13, IETF Secretariat wrote: > > Dear Alan Ford, Costin Raiciu, Mark J. Handley, Olivier Bonaventure: > > An IPR disclosure that pertains to your Internet-Draft entitled "TCP Extensions > for Multipath Operation with Multiple Addresses" (draft-ietf-mptcp- > multiaddressed) was submitted to the IETF Secretariat on 2012-07-31 and has been > posted on the "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1843/). The title of the IPR disclosure is > "Georg Hampel's Statement about IPR related to draft-ietf-mptcp- > multiaddressed-09 belonging to Asankya Networks.""); > > The IETF Secretariat > From alanford@cisco.com Tue Jul 31 17:37:29 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 637F121F88C8 for ; Tue, 31 Jul 2012 17:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSKBI5auWaz4 for ; Tue, 31 Jul 2012 17:37:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8E32221F88A7 for ; Tue, 31 Jul 2012 17:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=3768; q=dns/txt; s=iport; t=1343781448; x=1344991048; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rBfLePPmwwLX5IoTUsUfDcwYC71vwj8FDLjtOsNQvZQ=; b=lLwZL36xUY9HEOCLNDRZ28ZPcXbGj5Jqc+WYaEOaZVXLrxHRXVE4fgL4 ghkAhUmlyrVKU660oyPevCZ4Zf7EIO6eMDUPMO0dq+R+0w20Nvi+vCiFX i26xzpsaG8g8GipjirU32O2UWm3xPA/0SNAH1uk23//e0wJt/J5wVBF0X 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKR5GFCtJXG+/2dsb2JhbABFuXuBB4IgAQEBBAEBAQ8BFEcLEgEIGAxJCyUCBA4FIodrC5tgoFuLSYcJA4gYjS+BFI0TgWaCX4FWBQ X-IronPort-AV: E=Sophos;i="4.77,690,1336348800"; d="scan'208";a="107241889" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2012 00:37:28 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q710bSBb019759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 00:37:28 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.122]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 19:35:16 -0500 From: "Alan Ford (alanford)" To: Christoph Paasch , "Hampel, K Georg (K Georg)" Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1WI+Dp/haF4AVDRoS7OtIAVF6w+wA95giAAAyBLuD//6NNgP//+weAgAJz/YCAAF8iAIAACV+AgALaroCAABu7AIAAI/MAgAAE6YCAAYgQgIAAAf8AgBGDdYCAGB2hAA== Date: Wed, 1 Aug 2012 00:37:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.55.82.168] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.001 x-tm-as-result: No--49.021200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 01 Aug 2012 00:37:29 -0000 Hi all, As just mentioned in the MPTCP WG, this is one issue that it would be really good to come up with clarifications for the draft. So, apart from the in-order delivery of mappings, are there any other changes that we should make? What does implementation experience tell us here? Cheers, Alan On 16/07/2012 17:21, "Alan Ford (alanford)" wrote: >All, > >I've been considering how to reconcile the recent discussions in the draft >as it stands. > >On Page 25 we already mention something in this area, but it does not >cover all cases we have discussed. In particular, it currently says: > > Implementations MAY hold onto such unmapped data for a short while in > the expectation that a mapping will arrive shortly. [...] > If a mapping for that subflow-level sequence space does > not arrive within a receive window of data, that subflow SHOULD be > treated as broken, closed with an RST, and any unmapped data silently > discarded. > >However, I'm not sure this really works. If a mapping was sent on a >duplicate ACK, this may not be discovered in time (by the lack of a DATA >ACK within said window). Maybe this actually needs to be one >2*receive_window? > >Given the recent feedback, it looks like we also need to add more >constraints. For a simple requirement, how about we add: > > A mapping for subflow seqno x MUST not be sent before the mappings for > subflow seqno 0 .. x-1 have been sent. > >This shouldn't affect normal operation, since in the event of lost packets >the subflow will handle the re-ordering before it gets to MPTCP >processing. > > >Later requirements discussed included: > > a) A mapping MUST appear, at latest, in the segment where is the first > byte it covers is. > > b) If a DSS-mapping goes from x -> y in the subflow-seqno space, the > DSS-option MUST be on one of these segments. > > >However, the latter of these prevents a duplicate ACK giving a mapping >being used before the data; and the former prevents preemptive mappings >entirely. > >I do not see we have reached a particular consensus of what restrictions >we want to place on preemptive mappings. Can we refine anything here to >ensure a manageable and deterministic behaviour? > >Regards, >Alan > >On 05/07/2012 14:54, "Christoph Paasch" >wrote: > >>On Thursday 05 July 2012 08:47:03 Hampel, K Georg wrote: >>> It is not known how packet-re-segmenting middleboxes align DSS and >>>payload. >>> When packet-re-segmentation occurs the DSS mapping may arrive earlier >>>at >>> the receiver than the corresponding payload. >> >>How could this happen? Can you give an example with sequence-numbers, >>where=20 >>the DSS is not on one of the packets whose sequence-numbers he belongs >>to. >> >>What I mean is: >> >>If a packet with DSS-mapping x -> y and subflow-seq-no x comes at the >>middlebox. >>How could the middlebox resegment this packet so that the DSS-mapping is >>on=20 >>packet with subflow-seq-no x-1 ? >>This is a very buggy middlebox in my opinion, as it is sending a segment >>(x-1)=20 >>that has already passed by this middlebox in the past. >> >> >>Christoph >> >> >>> Therefore, as long as we subscribe to the assumption that >>> packet-re-segmenting middleboxes exist, the implementation needs to >>>support >>> preemptive mappings. >> >> >> >>--=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 >>-- >>_______________________________________________ >>multipathtcp mailing list >>multipathtcp@ietf.org >>https://www.ietf.org/mailman/listinfo/multipathtcp > From anumita_biswas@apple.com Tue Jul 31 21:44:55 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 E229921F87E2 for ; Tue, 31 Jul 2012 21:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.203 X-Spam-Level: X-Spam-Status: No, score=-109.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 mEVNxP+w3yvq for ; Tue, 31 Jul 2012 21:44:54 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id E42BA21F86D1 for ; Tue, 31 Jul 2012 21:44:54 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 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 <0M820063T6ZLEL70@mail-out.apple.com> for multipathtcp@ietf.org; Tue, 31 Jul 2012 21:44:50 -0700 (PDT) X-AuditID: 1180711d-b7f896d000004730-34-5018b44230ca Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id B8.6D.18224.244B8105; Tue, 31 Jul 2012 21:44:50 -0700 (PDT) Received: from [10.64.85.204] (mobile-198-228-212-203.mycingular.net [198.228.212.203]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0M8200EL67UNBS30@koseret.apple.com> for multipathtcp@ietf.org; Tue, 31 Jul 2012 21:44:50 -0700 (PDT) References: In-reply-to: Content-transfer-encoding: quoted-printable Message-id: <66708DC5-FC75-4865-A361-4D407E248415@apple.com> X-Mailer: iPhone Mail (10A5355d) From: Anumita Biswas Date: Tue, 31 Jul 2012 21:44:35 -0700 To: "Alan Ford (alanford)" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUiON1OXddpi0SAwYtlkhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrInf1gLHipVbN6/j7mBcYJMFyMnh4SAicT1PZPYIGwxiQv3 1gPZXBxCAp1MElNeHmOFcI4xSVz4sIwFpEpIQE9iyd3TrCA2r4C4xOujUxhBbE4BfYk5sx+w dzFycDALqEtMmZILEmYW0JZ48u4CVLmNxOdjM8AWMAt0MEkcXv6ZCWKzgkRLUxNYERvQnKOP bjCD2MICRhJLTjwHm88ioCrR92YuWFwEqObMrN8sExgFZiE5YxbC6llIVi9gZF7FKFiUmpNY aWisl1hQkJOql5yfu4kRFHoNhbI7GPf/5D/EKMDBqMTD26AmESDEmlhWXJl7iFGCg1lJhFct AijEm5JYWZValB9fVJqTWnyIUZqDRUmc99dyoQAhgfTEktTs1NSC1CKYLBMHp1QD44bnPkle 3WtO7G+Wiv9xq6RJ4IfhzI2bd7hMmcpU7bxpwlmWxd++SZ5l+7HijPS0DWX/QyK2Tj55e72x zJ0J2g3Ba+ObGz4/vyO7TKXT1W+xZp3X/L8C7HFR7ze2Pv557MOvyEeiMWH5W1m/n3T8c+z+ tp7s3ZfeC+T2iy1g+RW/+ndFf2BH1VQlluKMREMt5qLiRADikoChOQIAAA== Cc: "multipathtcp@ietf.org" , Mahesh M , =?utf-8?Q?Ilpo_J=C3=A4rvinen?= 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: Wed, 01 Aug 2012 04:44:56 -0000 A DSS option may not be sent with corresponding data if there isn't enough t= cp option space available such as due to the presence of SACK blocks.=20 On Jul 31, 2012, at 5:37 PM, "Alan Ford (alanford)" wro= te: > Hi all, >=20 > As just mentioned in the MPTCP WG, this is one issue that it would be > really good to come up with clarifications for the draft. >=20 > So, apart from the in-order delivery of mappings, are there any other > changes that we should make? What does implementation experience tell us > here? >=20 > Cheers, > Alan >=20 > On 16/07/2012 17:21, "Alan Ford (alanford)" wrote: >=20 >> All, >>=20 >> I've been considering how to reconcile the recent discussions in the draf= t >> as it stands. >>=20 >> On Page 25 we already mention something in this area, but it does not >> cover all cases we have discussed. In particular, it currently says: >>=20 >> Implementations MAY hold onto such unmapped data for a short while in >> the expectation that a mapping will arrive shortly. [...] >> If a mapping for that subflow-level sequence space does >> not arrive within a receive window of data, that subflow SHOULD be >> treated as broken, closed with an RST, and any unmapped data silently >> discarded. >>=20 >> However, I'm not sure this really works. If a mapping was sent on a >> duplicate ACK, this may not be discovered in time (by the lack of a DATA >> ACK within said window). Maybe this actually needs to be one >> 2*receive_window? >>=20 >> Given the recent feedback, it looks like we also need to add more >> constraints. For a simple requirement, how about we add: >>=20 >> A mapping for subflow seqno x MUST not be sent before the mappings for >> subflow seqno 0 .. x-1 have been sent. >>=20 >> This shouldn't affect normal operation, since in the event of lost packet= s >> the subflow will handle the re-ordering before it gets to MPTCP >> processing. >>=20 >>=20 >> Later requirements discussed included: >>=20 >> a) A mapping MUST appear, at latest, in the segment where is the first >> byte it covers is. >>=20 >> b) If a DSS-mapping goes from x -> y in the subflow-seqno space, the >> DSS-option MUST be on one of these segments. >>=20 >>=20 >> However, the latter of these prevents a duplicate ACK giving a mapping >> being used before the data; and the former prevents preemptive mappings >> entirely. >>=20 >> I do not see we have reached a particular consensus of what restrictions >> we want to place on preemptive mappings. Can we refine anything here to >> ensure a manageable and deterministic behaviour? >>=20 >> Regards, >> Alan >>=20 >> On 05/07/2012 14:54, "Christoph Paasch" >> wrote: >>=20 >>> On Thursday 05 July 2012 08:47:03 Hampel, K Georg wrote: >>>> It is not known how packet-re-segmenting middleboxes align DSS and >>>> payload. >>>> When packet-re-segmentation occurs the DSS mapping may arrive earlier >>>> at >>>> the receiver than the corresponding payload. >>>=20 >>> How could this happen? Can you give an example with sequence-numbers, >>> where=20 >>> the DSS is not on one of the packets whose sequence-numbers he belongs >>> to. >>>=20 >>> What I mean is: >>>=20 >>> If a packet with DSS-mapping x -> y and subflow-seq-no x comes at the >>> middlebox. >>> How could the middlebox resegment this packet so that the DSS-mapping is= >>> on=20 >>> packet with subflow-seq-no x-1 ? >>> This is a very buggy middlebox in my opinion, as it is sending a segment= >>> (x-1)=20 >>> that has already passed by this middlebox in the past. >>>=20 >>>=20 >>> Christoph >>>=20 >>>=20 >>>> Therefore, as long as we subscribe to the assumption that >>>> packet-re-segmenting middleboxes exist, the implementation needs to >>>> support >>>> preemptive mappings. >>>=20 >>>=20 >>>=20 >>> --=20 >>> IP Networking Lab --- http://inl.info.ucl.ac.be >>> MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be >>> Universit=C3=A9 Catholique de Louvain >>> -- >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp