From mark.j.handley@gmail.com Wed Jul 1 15:24:55 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D357F3A6B0D for ; Wed, 1 Jul 2009 15:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxCU+4umJBrh for ; Wed, 1 Jul 2009 15:24:55 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id E59603A68FA for ; Wed, 1 Jul 2009 15:24:54 -0700 (PDT) Received: by fxm18 with SMTP id 18so1121652fxm.37 for ; Wed, 01 Jul 2009 15:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=EYakEq/asfnoON8kMhzEaCBysRLERCqJQAP7iA2y160=; b=bg5fzM+Xr2Zxo8rY1a5dK7nZTGv5A+pWv7GR3Hj7Jly6bMF5F4QANor+KAL4+war0f xvKI0KtHQj/n/W8WZc1Mwalf7SMAkuYTChJdoesefMlF4nvz9RYeFxd6sa6SfhauBqT5 Pfyb5nXCCHl+PNKMjuSAOcLSkJVJ2Y+29IfRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; b=qQC6X86K8i7EKifSwj91m+JX+9U/kU/atVBrcRqQ9oJawpBh1aaWNdPj5Dn8uogPEt OBYKkaxSFcUEB4IlCl/bHzA5GkfQbPmcHySz0aILCMcin/Dz6WbUOvjndlfwP8YikgvH BYlYPXjmBtTYBw2sUSRlqSYXZyHOGPZm470e0= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.107.68 with SMTP id a4mr6733769fap.44.1246487114302; Wed, 01 Jul 2009 15:25:14 -0700 (PDT) From: Mark Handley Date: Wed, 1 Jul 2009 23:24:54 +0100 X-Google-Sender-Auth: 3f2226e7731f784e Message-ID: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multipathtcp] Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 22:24:55 -0000 Folks, We're rapidly approaching the Stockholm IETF, so here's our first attempt at an agenda for the BoF. Please let us know if there's something we have missed. We'll circulate a list of drafts and reading material after the I-D submission deadline. Cheers, Mark and Scott Draft Agenda, Multipath TCP BOF Chairs: Mark Handley, Scott Brim Introduction: Scope, Intention, Process Scott Brim 5 minutes Multipath TCP: =A0Goals and Background Mark Handley 25 minutes Multipath TCP Protocol Design Alan Ford 25 minutes Linked Congestion Control Costin Raiciu 20 minutes Rethinking the Transport Layer and Impact on Multipath TCP Janardhan Iyengar and Bryan Ford 10 minutes Technology Discussion Led by Mark Handley 15 minutes Charter Discussion Led by Scott Brim 20 minutes From iljitsch@muada.com Thu Jul 2 08:36:49 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12893A6DBB for ; Thu, 2 Jul 2009 08:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gjh3DOTsqABS for ; Thu, 2 Jul 2009 08:36:49 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF6B3A6DA9 for ; Thu, 2 Jul 2009 08:36:39 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n62Fb2wA016858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 2 Jul 2009 17:37:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> From: Iljitsch van Beijnum To: multipathtcp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 17:36:43 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:36:49 -0000 We have two security mechanisms in the IETF: IPsec and SSL/TLS. One is very secure, the other one is widely used. With IPsec, every packet is authenticated independently, which causes huge overhead but means we don't have any issues in the multipath case. SSL on the other hand exchanges blocks of data over TCP which are then authenticated. If there is an authentication failure you break the session and at least you know you didn't accept any bad data. However, in the multipath case we can do more: if we make sure that every block of SSL data is only sent over a single path, and then we get an authentication failure, we have the opportunity to shut down the path with the failure and keep the other one open. That would be more robust. However, this requires integrating SSL and MPTCP and we may also need a way to get SSL to retransmit the data that failed to authenticate over another path... This seems like a lot of work. Another interesting prospect: SSL comes with a PKI of sorts. If we can reuse the security stuff negotiated by SSL to secure MPTCP interactions we don't have to come up with new security infrastructure for the two-ended multipath TCP (when SSL is used, at least). From Michael.Tuexen@lurchi.franken.de Thu Jul 2 11:40:16 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849CB3A6B04 for ; Thu, 2 Jul 2009 11:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.954 X-Spam-Level: X-Spam-Status: No, score=0.954 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ua6BJ3QX-AMC for ; Thu, 2 Jul 2009 11:40:15 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 651AE3A6BC0 for ; Thu, 2 Jul 2009 11:40:15 -0700 (PDT) Received: from [192.168.1.100] (p508FE657.dip.t-dialin.net [80.143.230.87]) by mail-n.franken.de (Postfix) with ESMTP id 3C58E1C0B4070; Thu, 2 Jul 2009 20:40:35 +0200 (CEST) Message-Id: <6FAEA372-247B-4C95-8DD6-B98FA4222209@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Iljitsch van Beijnum In-Reply-To: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 20:40:33 +0200 References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 18:40:16 -0000 Hi Iljutsch, have you looked at running DTLS/MTCP? It has the similar security features than TLS but does not required in-sequence delivery and complete message transfer. We use it for securing SCTP traffic using multiple streams. Best regards Michael On Jul 2, 2009, at 5:36 PM, Iljitsch van Beijnum wrote: > We have two security mechanisms in the IETF: IPsec and SSL/TLS. One > is very secure, the other one is widely used. > > With IPsec, every packet is authenticated independently, which > causes huge overhead but means we don't have any issues in the > multipath case. SSL on the other hand exchanges blocks of data over > TCP which are then authenticated. If there is an authentication > failure you break the session and at least you know you didn't > accept any bad data. > > However, in the multipath case we can do more: if we make sure that > every block of SSL data is only sent over a single path, and then we > get an authentication failure, we have the opportunity to shut down > the path with the failure and keep the other one open. That would be > more robust. > > However, this requires integrating SSL and MPTCP and we may also > need a way to get SSL to retransmit the data that failed to > authenticate over another path... This seems like a lot of work. > > Another interesting prospect: SSL comes with a PKI of sorts. If we > can reuse the security stuff negotiated by SSL to secure MPTCP > interactions we don't have to come up with new security > infrastructure for the two-ended multipath TCP (when SSL is used, at > least). > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From scott.brim@gmail.com Fri Jul 3 11:25:02 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A2828C32F for ; Fri, 3 Jul 2009 11:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJHEfj7QJhVU for ; Fri, 3 Jul 2009 11:25:02 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id C02F53A63CB for ; Fri, 3 Jul 2009 11:23:43 -0700 (PDT) Received: by yxe12 with SMTP id 12so4029644yxe.29 for ; Fri, 03 Jul 2009 11:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8aahRO+IkeFOzCIt0SwAoujMZ2tjdWlmCecEjoJcqao=; b=Hk1mLBfLhd3EKXSlAdHPm+tqUYlgqyQoy2D0DoRDybGKVcUhf8HHvxfWekLa5MIkQs qZ6yMPSu3Up6e89q3IP+M/O+dC3VuVen/gXSMkmSM1aJUYBtJ3rv/BaC4JIMJeuRQaom wMyZZVwNLZq9v2TzcmNg+g8uCUD2QYUitl8lQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=immOJs2HZDOi+zcvQkksvZb3wsZNrSBP3gmcFgRqW/AVUGky0EqiKuPaibrB5uF1ub EuL3Qee0uuv84XHZzpOpYyN8ngAdSJbslTvrv+FwjB4ZatoXGnrvcWRmXejWZW0CpSiu RJ/pl4NItYtdtoJEh5uX4nFCUfyZLnVOIgooo= Received: by 10.90.120.17 with SMTP id s17mr1254989agc.109.1246645438696; Fri, 03 Jul 2009 11:23:58 -0700 (PDT) Received: from sbrim-mbp.local (cpe-67-241-43-66.twcny.res.rr.com [67.241.43.66]) by mx.google.com with ESMTPS id 4sm501126aga.56.2009.07.03.11.23.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Jul 2009 11:23:58 -0700 (PDT) Message-ID: <4A4E4CBC.5000703@gmail.com> Date: Fri, 03 Jul 2009 14:23:56 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Mark Handley References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> In-Reply-To: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 18:25:03 -0000 Mark Handley allegedly wrote on 07/01/2009 6:24 PM: > Introduction: Scope, Intention, Process > Scott Brim > 5 minutes Since we have very little free time in the BOF agenda, I wanted to do scope and logistics bashing on the mailing list if possible. Take a look at the BOF description at . The goal of this BOF is to evaluate support for a working group to develop multipath TCP. The working group would focus on multipath TCP protocol development, including API extensions. We expect that research on multipath transport and transport in general will continue in parallel, and may affect this WG, but they will not be done in this WG. A working group needs a clear initial focus on a few tasks. Later on, after actually accomplishing something, it can open up and do a little more broad multitasking. In particular this leaves out SCTP, for which I apologize, but I hope you agree with the need for focus. Also, during the presentations we will try to stick to clarifying questions only. After all the presentations are done, we can have a general discussion on the issues led by Mark. If you have any comments with any of this, please let the list know. Thanks ... Scott From magnus.westerlund@ericsson.com Mon Jul 6 05:07:24 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7829F3A6C6C for ; Mon, 6 Jul 2009 05:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjnwLOiR1EHK for ; Mon, 6 Jul 2009 05:07:23 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 28D5A3A69A2 for ; Mon, 6 Jul 2009 05:07:22 -0700 (PDT) X-AuditID: c1b4fb3c-b7c04ae0000036a1-9d-4a51e8d78fa4 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 23.5A.13985.7D8E15A4; Mon, 6 Jul 2009 14:06:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 14:06:46 +0200 Received: from [153.88.55.4] ([153.88.55.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 14:06:43 +0200 Message-ID: <4A51E8D2.4000600@ericsson.com> Date: Mon, 06 Jul 2009 14:06:42 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Scott Brim References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> In-Reply-To: <4A4E4CBC.5000703@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Jul 2009 12:06:44.0610 (UTC) FILETIME=[3ADC3620:01C9FE32] X-Brightmail-Tracker: AAAAAA== Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 12:07:24 -0000 Hi, I would like to point out that from my perspective one of the biggest goal of the BOF is to discuss the really high level questions that you can't trust a future WG to sort out. Thus details in the protocol proposals are maybe not relevant unless they really results in such diverse protocol results or have significant difference in how they impact the network. So, as Scott writes considering the description and commenting already know on what you think are question is really helpful. I do hope that we will see a charter proposal more than one week prior to the IETF meeting. Cheers Magnus Scott Brim skrev: > Mark Handley allegedly wrote on 07/01/2009 6:24 PM: >> Introduction: Scope, Intention, Process >> Scott Brim >> 5 minutes > > Since we have very little free time in the BOF agenda, I wanted to do > scope and logistics bashing on the mailing list if possible. > > Take a look at the BOF description at > . > The goal of this BOF is to evaluate support for a working group to > develop multipath TCP. The working group would focus on multipath TCP > protocol development, including API extensions. > > We expect that research on multipath transport and transport in general > will continue in parallel, and may affect this WG, but they will not be > done in this WG. A working group needs a clear initial focus on a few > tasks. Later on, after actually accomplishing something, it can open up > and do a little more broad multitasking. In particular this leaves out > SCTP, for which I apologize, but I hope you agree with the need for focus. > > Also, during the presentations we will try to stick to clarifying > questions only. After all the presentations are done, we can have a > general discussion on the issues led by Mark. > > If you have any comments with any of this, please let the list know. > > Thanks ... Scott > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jul 6 05:17:37 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56AF13A6CFD for ; Mon, 6 Jul 2009 05:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7XwJDKpfPb5 for ; Mon, 6 Jul 2009 05:17:36 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 849C33A6CFC for ; Mon, 6 Jul 2009 05:17:33 -0700 (PDT) X-AuditID: c1b4fb3c-b7c04ae0000036a1-69-4a51e7927e83 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id A7.99.13985.297E15A4; Mon, 6 Jul 2009 14:01:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 14:01:22 +0200 Received: from [153.88.55.4] ([153.88.55.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 14:01:21 +0200 Message-ID: <4A51E78F.4080000@ericsson.com> Date: Mon, 06 Jul 2009 14:01:19 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> In-Reply-To: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Jul 2009 12:01:21.0728 (UTC) FILETIME=[7A685400:01C9FE31] X-Brightmail-Tracker: AAAAAA== Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 12:17:37 -0000 Iljitsch van Beijnum skrev: > We have two security mechanisms in the IETF: IPsec and SSL/TLS. One is > very secure, the other one is widely used. > > With IPsec, every packet is authenticated independently, which causes > huge overhead but means we don't have any issues in the multipath case. > SSL on the other hand exchanges blocks of data over TCP which are then > authenticated. If there is an authentication failure you break the > session and at least you know you didn't accept any bad data. > > However, in the multipath case we can do more: if we make sure that > every block of SSL data is only sent over a single path, and then we get > an authentication failure, we have the opportunity to shut down the path > with the failure and keep the other one open. That would be more robust. > > However, this requires integrating SSL and MPTCP and we may also need a > way to get SSL to retransmit the data that failed to authenticate over > another path... This seems like a lot of work. > > Another interesting prospect: SSL comes with a PKI of sorts. If we can > reuse the security stuff negotiated by SSL to secure MPTCP interactions > we don't have to come up with new security infrastructure for the > two-ended multipath TCP (when SSL is used, at least). > _______________________________________________ Iljitsch, isn't TCP Authentication Option another possible mechanism that could be used by MP-TCP? It falls closer to IPsec in that it doesn't allow NATs to modify anything in the header. https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-auth-opt/ The keying of TCP AO is also question mark where several different approaches are possible but not really specified. Then at least we consider all the possible places to secure TCP, under it, in it and over it. I am certain that likely all models are going to be needed in the end. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From janardhan.iyengar@fandm.edu Mon Jul 6 15:45:04 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FFD28C3A2; Mon, 6 Jul 2009 15:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NcFmJhlKoXh; Mon, 6 Jul 2009 15:45:03 -0700 (PDT) Received: from zimfe2.fandm.edu (zimfe2.fandm.edu [155.68.1.75]) by core3.amsl.com (Postfix) with ESMTP id 100093A6819; Mon, 6 Jul 2009 15:45:02 -0700 (PDT) Received: from surutti.fandm.edu (pool-72-95-58-210.hrbgpa.east.verizon.net [72.95.58.210]) by zimfe2.fandm.edu (Postfix) with ESMTP id D1F0811687F8; Mon, 6 Jul 2009 18:44:43 -0400 (EDT) Message-ID: <4A527E5A.3090801@fandm.edu> Date: Mon, 06 Jul 2009 18:44:42 -0400 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: tsv-area@ietf.org, multipathtcp@ietf.org, tae@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multipathtcp] A Next Generation Transport Services Architecture X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: janardhan.iyengar@fandm.edu List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:45:04 -0000 (Apologies for cross-posting) Dear all, We have uploaded a draft describing our proposed transport re-architecture, with its relevance and implications to multipath transport. Our hope is that this draft starts (or continues?) a conversation on a refactoring of the transport layer to accomodate new services and network elements. We also hope that this draft serves as a starting point for discussions about multipath transport and for an architectural framework within which to place multipath-tcp work at the IETF. ----------- A Next Generation Transport Services Architecture http://www.ietf.org/internet-drafts/draft-iyengar-ford-tng-00.txt Abstract: While there is substantial community interest in next-generation multipath-capable Internet transports, evolutionary pressures have gradually eroded the simplicity of the Internet's original transport architecture to a point where it is no longer realistically applicable to new tranports. This document proposes a new architectural framework for next-generation multipath-capable transport protocols, focusing immediately on multipath TCP but taking care to allow for generalization to other multipath-capable transports. The architecture places emphasis on enabling new multipath features in a safe, TCP-friendly, and backward-compatible fashion, retaining full interoperability with both existing applications and existing network infrastructure, and enabling reuse of existing protocols as much as possible while providing incremental deployment paths to new, more powerful and/or more efficient protocols. The architecture re-establishes the long-lost principles of end-to-end reliability and fate sharing, in the presence of existing and future network middleboxes, and enables the deployment of transport-neutral end-to-end protection without interfering with these policy-enforcing or performance-enhancing middleboxes. This document describes architecture goals, a layering model supporting these goals, abstract properties of the interfaces between the architecture's new layers, general approaches to multipath congestion control and how they fit into the architecture, realistic protocol design and incremental deployment paths, and ways in which this document complements and relates to ongoing protocol design activities in the IETF. ------------ Comments and thoughts welcome! - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From iljitsch@muada.com Wed Jul 8 02:12:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F90428C3FB for ; Wed, 8 Jul 2009 02:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBnoCqMi9in6 for ; Wed, 8 Jul 2009 02:12:34 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 75FFE28C3F6 for ; Wed, 8 Jul 2009 02:12:34 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n689CIwe067827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jul 2009 11:12:23 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <22295105-AB52-42F5-BED3-9F2DE44FB399@muada.com> From: Iljitsch van Beijnum To: Lars Eggert , Magnus Westerlund Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 11:12:15 +0200 X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: [multipathtcp] Time slot swap X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 09:12:35 -0000 Lars, Magnus, The MPTCP BoF has been moved to Wednesday morning, which gives us 90 minutes rather than 120, while the agenda was already pretty full at 120. There's currently only 75 minutes allocated in the 120 minute TSVAREA slot on Monday afternoon. Perhaps it makes sense to swap the two sessions? Although then TSVAREA rather than MPTCP clashes with ICCRG... Another option would be to ask for both the tue afternoon 3 and wed afternoon 2 slots for MPTCP, which would be a total of 2 hours with no obvious conflicts and those two slots each have less than 8 sessions so there should be room. Iljitsch From magnus.westerlund@ericsson.com Wed Jul 8 08:31:32 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C1C3A680C for ; Wed, 8 Jul 2009 08:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9o1ptct148D for ; Wed, 8 Jul 2009 08:31:31 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5E5713A6B5C for ; Wed, 8 Jul 2009 08:31:27 -0700 (PDT) X-AuditID: c1b4fb3c-b7c04ae0000036a1-c5-4a54bbe89144 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 97.4F.13985.8EBB45A4; Wed, 8 Jul 2009 17:31:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 17:31:52 +0200 Received: from [153.88.49.65] ([153.88.49.65]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 17:31:51 +0200 Message-ID: <4A54BBE6.1040808@ericsson.com> Date: Wed, 08 Jul 2009 17:31:50 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <22295105-AB52-42F5-BED3-9F2DE44FB399@muada.com> In-Reply-To: <22295105-AB52-42F5-BED3-9F2DE44FB399@muada.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Jul 2009 15:31:51.0991 (UTC) FILETIME=[37750470:01C9FFE1] X-Brightmail-Tracker: AAAAAA== Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Time slot swap X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:31:32 -0000 Iljitsch van Beijnum skrev: > Lars, Magnus, > > The MPTCP BoF has been moved to Wednesday morning, which gives us 90 > minutes rather than 120, while the agenda was already pretty full at > 120. There's currently only 75 minutes allocated in the 120 minute > TSVAREA slot on Monday afternoon. Perhaps it makes sense to swap the two > sessions? Wednesday morning is 2,5 hours, not 1,5 hours. So you gained half an hour for the BOF. > > Although then TSVAREA rather than MPTCP clashes with ICCRG... > > Another option would be to ask for both the tue afternoon 3 and wed > afternoon 2 slots for MPTCP, which would be a total of 2 hours with no > obvious conflicts and those two slots each have less than 8 sessions so > there should be room. > > Iljitsch > So, is the issue the clash with ICCRG which is very unfortunate? Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From scott.brim@gmail.com Wed Jul 8 08:35:22 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395493A6BA2 for ; Wed, 8 Jul 2009 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhab84x5A92Y for ; Wed, 8 Jul 2009 08:35:20 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id C642C3A6B6B for ; Wed, 8 Jul 2009 08:35:20 -0700 (PDT) Received: by pzk36 with SMTP id 36so5641015pzk.29 for ; Wed, 08 Jul 2009 08:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=JtetZlF0guEGXSHnJFk9uJGyr4FYvGTZcvE3fwpV/5M=; b=oubAqSKL4yYF/KL5DExWzXlv9cs9+CwXDV8DSjtocO9rQqqoQ/jSgKxscIg5Gn635H xrHXn2uD50KemwyjvWAbFrKFxcH4kc+0rto5Wksl7I+R3ujJfjNidpGKrLgmd7TUMfPb v4Xbg61nR83t9OmYt9GS5SYmYOSxZ2yreWdNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=a0poL/DnJO/dcOy5NmEBwjF84XEkkSYq6rFoC05YKhW++h8NaZDH5b/aAAcWhJtw8e 4FnjowjIiUqKKOY7eaHIMKDMi0564ovLxyed7qWgTPtbqu8dwwKO92Dt9PuCka4oUvz5 igTl+7o9W/Tm4OzE/HBM/oUdhP3uf/vOFmgRU= Received: by 10.114.46.6 with SMTP id t6mr11491445wat.17.1247067345960; Wed, 08 Jul 2009 08:35:45 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id l30sm646059waf.0.2009.07.08.08.35.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Jul 2009 08:35:45 -0700 (PDT) Message-ID: <4A54BCCE.1080603@gmail.com> Date: Wed, 08 Jul 2009 11:35:42 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <22295105-AB52-42F5-BED3-9F2DE44FB399@muada.com> In-Reply-To: <22295105-AB52-42F5-BED3-9F2DE44FB399@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Time slot swap X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:35:22 -0000 This would work for me. swb Iljitsch van Beijnum allegedly wrote on 07/08/2009 5:12 AM: > Lars, Magnus, > > The MPTCP BoF has been moved to Wednesday morning, which gives us 90 > minutes rather than 120, while the agenda was already pretty full at > 120. There's currently only 75 minutes allocated in the 120 minute > TSVAREA slot on Monday afternoon. Perhaps it makes sense to swap the two > sessions? > > Although then TSVAREA rather than MPTCP clashes with ICCRG... > > Another option would be to ask for both the tue afternoon 3 and wed > afternoon 2 slots for MPTCP, which would be a total of 2 hours with no > obvious conflicts and those two slots each have less than 8 sessions so > there should be room. > > Iljitsch From iljitsch@muada.com Wed Jul 8 08:37:21 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234373A6B41 for ; Wed, 8 Jul 2009 08:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtVcq-KMxGXw for ; Wed, 8 Jul 2009 08:37:20 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 110163A6B3B for ; Wed, 8 Jul 2009 08:37:19 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n68FbATJ070038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jul 2009 17:37:10 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Magnus Westerlund In-Reply-To: <4A54BBE6.1040808@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 17:37:07 +0200 References: <22295105-AB52-42F5-BED3-9F2DE44FB399@muada.com> <4A54BBE6.1040808@ericsson.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Time slot swap X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:37:21 -0000 On 8 jul 2009, at 17:31, Magnus Westerlund wrote: > Wednesday morning is 2,5 hours, not 1,5 hours. So you gained half an > hour for the BOF. My apologies! > So, is the issue the clash with ICCRG which is very unfortunate? Well we are going to talk about congestion control trickery to make multipath fast but be too unfair (or unfair at all) towards other flows. Some input from the CC gurus would be helpful here. Iljitsch From magnus.westerlund@ericsson.com Wed Jul 8 09:14:23 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB943A6BFA for ; Wed, 8 Jul 2009 09:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojjkXbNFYEPu for ; Wed, 8 Jul 2009 09:14:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B9A363A6C59 for ; Wed, 8 Jul 2009 09:14:18 -0700 (PDT) X-AuditID: c1b4fb3c-b7c04ae0000036a1-6a-4a54c5f1caab Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 49.D1.13985.1F5C45A4; Wed, 8 Jul 2009 18:14:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 18:14:40 +0200 Received: from [153.88.49.65] ([153.88.49.65]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 18:14:40 +0200 Message-ID: <4A54C5EF.5070106@ericsson.com> Date: Wed, 08 Jul 2009 18:14:39 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <22295105-AB52-42F5-BED3-9F2DE44FB399@muada.com> In-Reply-To: <22295105-AB52-42F5-BED3-9F2DE44FB399@muada.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Jul 2009 16:14:40.0685 (UTC) FILETIME=[32849DD0:01C9FFE7] X-Brightmail-Tracker: AAAAAA== Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Time slot swap X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 16:14:23 -0000 Iljitsch van Beijnum skrev: > Lars, Magnus, > > The MPTCP BoF has been moved to Wednesday morning, which gives us 90 > minutes rather than 120, while the agenda was already pretty full at > 120. There's currently only 75 minutes allocated in the 120 minute > TSVAREA slot on Monday afternoon. Perhaps it makes sense to swap the two > sessions? > > Although then TSVAREA rather than MPTCP clashes with ICCRG... > > Another option would be to ask for both the tue afternoon 3 and wed > afternoon 2 slots for MPTCP, which would be a total of 2 hours with no > obvious conflicts and those two slots each have less than 8 sessions so > there should be room. > > Iljitsch > What about swapping MP-TCP from Wednesday to Thursday morning to the NFSv4 session? Has anyone that is charing or presenting or can see that would result in a bad conflict? Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dwing@cisco.com Wed Jul 8 21:12:28 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4C13A6F64 for ; Wed, 8 Jul 2009 21:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE3zC0mkWhO0 for ; Wed, 8 Jul 2009 21:12:27 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 74F563A6B93 for ; Wed, 8 Jul 2009 21:12:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,372,1243814400"; d="scan'208";a="211389728" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2009 04:12:55 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n694CtlB025496; Wed, 8 Jul 2009 21:12:55 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n694Cs2d029361; Thu, 9 Jul 2009 04:12:54 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , "'Iljitsch van Beijnum'" References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> Date: Wed, 8 Jul 2009 21:12:54 -0700 Message-ID: <018701ca004b$88831680$e5a36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acn+M9UsY6I/yFvoTNWE9Xnys2SS4gCFzPqw In-Reply-To: <4A51E78F.4080000@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3501; t=1247112775; x=1247976775; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[multipathtcp]=20Integration=20with=20S SL |Sender:=20; bh=63XBNSQf5plAYDRt8O4wAXI8YOtyvWEYk5QU8KxsEVk=; b=B0ApbZvdLRfygPNLAuQhGy3yfSGgCm6+IrH/nN0DzVnK913glWu9lQYe6v Aa8RyClLrWNtyrbRTLy9E37rP8K2MIBNIZ5bd0PqklLhq9S2OpR6JXzxKICQ wHOyGFYAmX; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 04:12:28 -0000 =20 > -----Original Message----- > From: multipathtcp-bounces@ietf.org=20 > [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: Monday, July 06, 2009 5:01 AM > To: Iljitsch van Beijnum > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] Integration with SSL >=20 > Iljitsch van Beijnum skrev: > > We have two security mechanisms in the IETF: IPsec and=20 > SSL/TLS. One is > > very secure, the other one is widely used. > >=20 > > With IPsec, every packet is authenticated independently,=20 > which causes > > huge overhead but means we don't have any issues in the=20 > multipath case. > > SSL on the other hand exchanges blocks of data over TCP=20 > which are then > > authenticated. If there is an authentication failure you break the > > session and at least you know you didn't accept any bad data. > >=20 > > However, in the multipath case we can do more: if we make sure that > > every block of SSL data is only sent over a single path,=20 > and then we get > > an authentication failure, we have the opportunity to shut=20 > down the path > > with the failure and keep the other one open. That would be=20 > more robust. > >=20 > > However, this requires integrating SSL and MPTCP and we may=20 > also need a > > way to get SSL to retransmit the data that failed to=20 > authenticate over > > another path... This seems like a lot of work. > >=20 > > Another interesting prospect: SSL comes with a PKI of=20 > sorts. If we can > > reuse the security stuff negotiated by SSL to secure MPTCP=20 > interactions > > we don't have to come up with new security infrastructure for the > > two-ended multipath TCP (when SSL is used, at least). > > _______________________________________________ >=20 > Iljitsch, isn't TCP Authentication Option another possible mechanism > that could be used by MP-TCP? It falls closer to IPsec in that it > doesn't allow NATs to modify anything in the header. >=20 > https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-auth-opt/ >=20 > The keying of TCP AO is also question mark where several different > approaches are possible but not really specified. TCP-AO doesn't work over NATs, which was a design decision to=20 reduce the complexity of the protocol and to avoid sending=20 additional bits on the wire. I objected to this decision, but consensus was to ignore NATs. http://tools.ietf.org/html/draft-ietf-tcpm-tcp-auth-opt-05#section-11.2 I expect multipath TCP wants to work over NATs, so if TCP-AO is on the table we would also need to enhance TCP-AO to work across NATs. -d > Then at least we consider all the possible places to secure TCP, under > it, in it and over it. I am certain that likely all models=20 > are going to be needed in the end. >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From touch@ISI.EDU Wed Jul 8 23:39:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60143A693D for ; Wed, 8 Jul 2009 23:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm8mjqEGUAQ8 for ; Wed, 8 Jul 2009 23:39:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A23583A6873 for ; Wed, 8 Jul 2009 23:39:58 -0700 (PDT) Received: from [128.9.176.73] (c3-vpn2.isi.edu [128.9.176.73] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n696cwcb026141; Wed, 8 Jul 2009 23:39:00 -0700 (PDT) Message-ID: <4A559082.1020608@isi.edu> Date: Wed, 08 Jul 2009 23:38:58 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dan Wing References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> In-Reply-To: <018701ca004b$88831680$e5a36b80@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 06:39:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Wing wrote: ... >> Iljitsch, isn't TCP Authentication Option another possible mechanism >> that could be used by MP-TCP? It falls closer to IPsec in that it >> doesn't allow NATs to modify anything in the header. >> >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-auth-opt/ >> >> The keying of TCP AO is also question mark where several different >> approaches are possible but not really specified. > > TCP-AO doesn't work over NATs, which was a design decision to > reduce the complexity of the protocol and to avoid sending > additional bits on the wire. I objected to this decision, > but consensus was to ignore NATs. > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-auth-opt-05#section-11.2 TCP-AO is intended to protect against the kind of modification a NAT performs. It can be encapsulated to traverse a NAT, just like nearly any other protocol including IPsec, however. Note that TCP-AO does permit the non-AO options to be ignored, which can help in traversing option-modifying middleboxes. > I expect multipath TCP wants to work over NATs, so if TCP-AO is > on the table we would also need to enhance TCP-AO to work across > NATs. It might be useful to show how multipath TCP makes sense over NATs first, since NATs could destroy the multipathing. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpVkIIACgkQE5f5cImnZruZTACg+MTglplwmjRkTRHZqsdb6S8b 3I8AoNdWlJeURjO9/oOKvCUwQhMFqV5Q =v0ul -----END PGP SIGNATURE----- From Michael.Tuexen@lurchi.franken.de Thu Jul 9 00:16:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0A328C15A for ; Thu, 9 Jul 2009 00:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.072 X-Spam-Level: ** X-Spam-Status: No, score=2.072 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM9Of-QlbQh6 for ; Thu, 9 Jul 2009 00:16:58 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id C79303A6897 for ; Thu, 9 Jul 2009 00:16:57 -0700 (PDT) Received: from [192.168.1.100] (p508FD440.dip.t-dialin.net [80.143.212.64]) by mail-n.franken.de (Postfix) with ESMTP id 06E721C0B4613; Thu, 9 Jul 2009 09:17:21 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Dan Wing In-Reply-To: <018701ca004b$88831680$e5a36b80@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 09:17:21 +0200 References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 07:16:59 -0000 On Jul 9, 2009, at 6:12 AM, Dan Wing wrote: > > >> -----Original Message----- >> From: multipathtcp-bounces@ietf.org >> [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Monday, July 06, 2009 5:01 AM >> To: Iljitsch van Beijnum >> Cc: multipathtcp@ietf.org >> Subject: Re: [multipathtcp] Integration with SSL >> >> Iljitsch van Beijnum skrev: >>> We have two security mechanisms in the IETF: IPsec and >> SSL/TLS. One is >>> very secure, the other one is widely used. >>> >>> With IPsec, every packet is authenticated independently, >> which causes >>> huge overhead but means we don't have any issues in the >> multipath case. >>> SSL on the other hand exchanges blocks of data over TCP >> which are then >>> authenticated. If there is an authentication failure you break the >>> session and at least you know you didn't accept any bad data. >>> >>> However, in the multipath case we can do more: if we make sure that >>> every block of SSL data is only sent over a single path, >> and then we get >>> an authentication failure, we have the opportunity to shut >> down the path >>> with the failure and keep the other one open. That would be >> more robust. >>> >>> However, this requires integrating SSL and MPTCP and we may >> also need a >>> way to get SSL to retransmit the data that failed to >> authenticate over >>> another path... This seems like a lot of work. >>> >>> Another interesting prospect: SSL comes with a PKI of >> sorts. If we can >>> reuse the security stuff negotiated by SSL to secure MPTCP >> interactions >>> we don't have to come up with new security infrastructure for the >>> two-ended multipath TCP (when SSL is used, at least). >>> _______________________________________________ >> >> Iljitsch, isn't TCP Authentication Option another possible mechanism >> that could be used by MP-TCP? It falls closer to IPsec in that it >> doesn't allow NATs to modify anything in the header. >> >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-auth-opt/ >> >> The keying of TCP AO is also question mark where several different >> approaches are possible but not really specified. > > TCP-AO doesn't work over NATs, which was a design decision to > reduce the complexity of the protocol and to avoid sending > additional bits on the wire. I objected to this decision, > but consensus was to ignore NATs. > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-auth-=20 > opt-05#section-11.2 > > I expect multipath TCP wants to work over NATs, so if TCP-AO is > on the table we would also need to enhance TCP-AO to work across > NATs. > > -d As said in an earlier e-mail: Have a look at DTLS/M-TCP. Use it similar to DTLS/SCTP, but with SCTP-AUTH, since MTCP does not have something like PR-SCTP. Best regards Michael > >> Then at least we consider all the possible places to secure TCP, =20 >> under >> it, in it and over it. I am certain that likely all models >> are going to be needed in the end. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From dwing@cisco.com Thu Jul 9 00:17:45 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB063A6897 for ; Thu, 9 Jul 2009 00:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0pvxQ-KukFA for ; Thu, 9 Jul 2009 00:17:44 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 48F403A6911 for ; Thu, 9 Jul 2009 00:17:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,372,1243814400"; d="scan'208";a="175610309" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2009 07:18:09 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n697I9Ui003539; Thu, 9 Jul 2009 00:18:09 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n697I9UH004325; Thu, 9 Jul 2009 07:18:09 GMT From: "Dan Wing" To: "'Joe Touch'" References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> Date: Thu, 9 Jul 2009 00:18:09 -0700 Message-ID: <01e901ca0065$6998a9f0$e5a36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoAYCKMUAdBUdC0QXCgrjs8ZSouiAABIZUw In-Reply-To: <4A559082.1020608@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1592; t=1247123889; x=1247987889; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[multipathtcp]=20Integration=20with=20S SL |Sender:=20; bh=Un/C2iFkMgkZf9xkpf9BHl7NXRABfQ7MFA5sLwM0QDs=; b=Q4Sf3tV23YSPJUxcEwtE7TnIhhzB62AjwHMHJuEKnEHYSCvFWh2Jl1AYE+ FPoXjgSkjNBtvW89cxB2FWafENIlQVrIb9bEnaqTHbsC9bjTJz4Z/byaV7OP a2RrqPiGGO; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 07:17:45 -0000 > Dan Wing wrote: > ... > >> Iljitsch, isn't TCP Authentication Option another possible > mechanism > >> that could be used by MP-TCP? It falls closer to IPsec in that it > >> doesn't allow NATs to modify anything in the header. > >> > >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-auth-opt/ > >> > >> The keying of TCP AO is also question mark where several different > >> approaches are possible but not really specified. > > > > TCP-AO doesn't work over NATs, which was a design decision to > > reduce the complexity of the protocol and to avoid sending > > additional bits on the wire. I objected to this decision, > > but consensus was to ignore NATs. > > > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-auth-opt-05#sec > tion-11.2 > > TCP-AO is intended to protect against the kind of modification a NAT > performs. It can be encapsulated to traverse a NAT, just like > nearly any other protocol including IPsec, however. Yes, I recall that argument. I still disagree with that argument. > Note that TCP-AO does permit the non-AO options to be > ignored, which can help in traversing option-modifying > middleboxes. > > > I expect multipath TCP wants to work over NATs, so if TCP-AO is > > on the table we would also need to enhance TCP-AO to work across > > NATs. > > It might be useful to show how multipath TCP makes sense over NATs > first, since NATs could destroy the multipathing. Iljitsch's one-ended multipath, draft-van-beijnum-1e-mp-tcp-00, would work with a NAT in front of the subscriber's computer. -d From iljitsch@muada.com Thu Jul 9 01:47:24 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019CB28C17F for ; Thu, 9 Jul 2009 01:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucNcO7BvGOz3 for ; Thu, 9 Jul 2009 01:47:23 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D8BBF28C0F7 for ; Thu, 9 Jul 2009 01:47:22 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n698l4Gc075838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jul 2009 10:47:05 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Dan Wing In-Reply-To: <01e901ca0065$6998a9f0$e5a36b80@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 10:47:02 +0200 References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 08:47:24 -0000 On 9 jul 2009, at 9:18, Dan Wing wrote: >> It might be useful to show how multipath TCP makes sense over NATs >> first, since NATs could destroy the multipathing. > Iljitsch's one-ended multipath, draft-van-beijnum-1e-mp-tcp-00, would > work with a NAT in front of the subscriber's computer. Right. As long as you avoid having different NAT applied on the different paths there are no issues. I've also been thinking about a way to extend the one-ended MPTCP into a simple two-ended MPTCP that can actually take advantage of NAT. In multi6/shim6 we used to talk about "basement multihomers", which would be people with two regular consumer type broadband connections, for instance, one cable and one ADSL. Those users would have two NATs for IPv4. An MPTCP would be able to take advantage of that by talking to the same destination through both NATs. It would work something like this: - client sends SYN over one path with MPTCP capability in it - server responds with SYN/ACK with the MPTCP capability in it - client ACKs the SYN/ACK and also sends a copy of the SYN over the other path - server sees that the other SYN belongs to the session created before, sends SYN/ACK - client ACKs the SYN/ACK - data packets are distributed over the two (or more paths) - every path is given a packet per window to advance the window This obviously requires both ends to be MPTCP but it doesn't require the complex address negotiation in Alan's draft. I think it can also work most of the time without a second sequence number space. It would be helpful if different capabilities, such as the ability to bond additional implicitly created "sessions" as per the above, the ability to negotiate addresses explicitly and the ability to have a second sequence number space all individually, so there is a smooth upgrade path from basic MPTCP to a more fully featured MPTCP, where implementations with different capabilities can work together. From scott.brim@gmail.com Thu Jul 9 04:02:54 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3502B3A6832 for ; Thu, 9 Jul 2009 04:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdNL2GjRPZmc for ; Thu, 9 Jul 2009 04:02:53 -0700 (PDT) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id 7309D3A67E3 for ; Thu, 9 Jul 2009 04:02:53 -0700 (PDT) Received: by gxk26 with SMTP id 26so95606gxk.13 for ; Thu, 09 Jul 2009 04:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=lX7DOEC3QrlBhqhonuUF4aGRD8Q4YaGHfBB71V9akc8=; b=ATlkSMpa4vkhZxqW0y+GbWoaDKPDXf7kQ18Qxw3yKU3I/uHo6cSbxcD4A6cg8fA+QU T0M03xUWIO6RdM/VDKeb7YXgRk8QeqVIM6T4HhIVY8LKU1yYVFrKPMF22qnN6qrFgD1P Qe32Dwt7BhhvBhdVcvnfsHgSr5vbKyOpkZ8WI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=W/Tl26riWjHmkAJtdS1rmhese6GZTxn747EE1wdOe16Qp+hOvBAwl0/Cro/m6vScLI hZkIJhrZHBP6W0oStDZzrtO09H4sIrz37IMgRjQixUvSwWXd8kqqfMDspePYeSRLR0xn af88wnp42wLLwRkJS9C46dUSw00GE3pzkGL2U= Received: by 10.90.63.11 with SMTP id l11mr585679aga.2.1247137399310; Thu, 09 Jul 2009 04:03:19 -0700 (PDT) Received: from sbrim-mbp.local (cpe-67-241-43-66.twcny.res.rr.com [67.241.43.66]) by mx.google.com with ESMTPS id 36sm4555667aga.14.2009.07.09.04.03.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Jul 2009 04:03:18 -0700 (PDT) Message-ID: <4A55CE75.9070107@gmail.com> Date: Thu, 09 Jul 2009 07:03:17 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Joe Touch References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> In-Reply-To: <4A559082.1020608@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:02:54 -0000 Joe Touch allegedly wrote on 07/09/2009 2:38 AM: > It might be useful to show how multipath TCP makes sense over NATs > first, since NATs could destroy the multipathing. Joe, what do you mean, "makes sense"? Do you mean how it would work? From touch@ISI.EDU Thu Jul 9 07:35:43 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32FE13A6BA9 for ; Thu, 9 Jul 2009 07:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P64MSfOmEEd8 for ; Thu, 9 Jul 2009 07:35:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E724328C219 for ; Thu, 9 Jul 2009 07:35:41 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n69EZf3q016213; Thu, 9 Jul 2009 07:35:43 -0700 (PDT) Message-ID: <4A56003D.1000001@isi.edu> Date: Thu, 09 Jul 2009 07:35:41 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:35:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: > On 9 jul 2009, at 9:18, Dan Wing wrote: > >>> It might be useful to show how multipath TCP makes sense over NATs >>> first, since NATs could destroy the multipathing. > >> Iljitsch's one-ended multipath, draft-van-beijnum-1e-mp-tcp-00, would >> work with a NAT in front of the subscriber's computer. > > Right. As long as you avoid having different NAT applied on the > different paths there are no issues. > > I've also been thinking about a way to extend the one-ended MPTCP into a > simple two-ended MPTCP that can actually take advantage of NAT. In > multi6/shim6 we used to talk about "basement multihomers", which would > be people with two regular consumer type broadband connections, for > instance, one cable and one ADSL. Those users would have two NATs for > IPv4. An MPTCP would be able to take advantage of that by talking to the > same destination through both NATs. It would work something like this: > > - client sends SYN over one path with MPTCP capability in it > - server responds with SYN/ACK with the MPTCP capability in it > - client ACKs the SYN/ACK and also sends a copy of the SYN over the > other path > - server sees that the other SYN belongs to the session created before, > sends SYN/ACK How does that happen? The first SYN was translated. What makes the second SYN look like the first one, i.e., it could be translated differently (by a different NAT or the same NAT)? > - client ACKs the SYN/ACK > - data packets are distributed over the two (or more paths) > - every path is given a packet per window to advance the window Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpWAD0ACgkQE5f5cImnZrvJRACfcfAJmj2x3CL2xpbyXe4xg9SL wPsAoNYZ2XXJxVtGUAA0fr6FrhUzYbGx =NprI -----END PGP SIGNATURE----- From iljitsch@muada.com Thu Jul 9 07:42:27 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A48A3A6C9D for ; Thu, 9 Jul 2009 07:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6gb0AiTbxib for ; Thu, 9 Jul 2009 07:42:26 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 6339C3A6CC9 for ; Thu, 9 Jul 2009 07:42:26 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n69EfcCh080299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jul 2009 16:42:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> From: Iljitsch van Beijnum To: Joe Touch In-Reply-To: <4A56003D.1000001@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 16:42:36 +0200 References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:42:27 -0000 On 9 jul 2009, at 16:35, Joe Touch wrote: >> - client sends SYN over one path with MPTCP capability in it >> - server responds with SYN/ACK with the MPTCP capability in it >> - client ACKs the SYN/ACK and also sends a copy of the SYN over the >> other path >> - server sees that the other SYN belongs to the session created >> before, >> sends SYN/ACK > How does that happen? The first SYN was translated. What makes the > second SYN look like the first one, i.e., it could be translated > differently (by a different NAT or the same NAT)? There would have to be a cookie in the SYN packet. From dwing@cisco.com Thu Jul 9 07:59:45 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31EAF28C232 for ; Thu, 9 Jul 2009 07:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUpcdmZHJ0bv for ; Thu, 9 Jul 2009 07:59:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 742C928C22A for ; Thu, 9 Jul 2009 07:59:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,374,1243814400"; d="scan'208";a="340641548" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2009 15:00:12 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n69F0CJA021972; Thu, 9 Jul 2009 08:00:12 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n69F0B7f025387; Thu, 9 Jul 2009 15:00:12 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" , "'Joe Touch'" References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> Date: Thu, 9 Jul 2009 08:00:11 -0700 Message-ID: <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoAo4JYnYdwl5EKTWauFqRL7DaI6gAAjHkg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1184; t=1247151612; x=1248015612; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[multipathtcp]=20Integration=20with=20S SL |Sender:=20; bh=RY6Ebc6L+XHOw2nzVTwHmroag7jaK816Ie4QLytj1Rk=; b=PKvISWwLCnK+UmtT40kIoL6IKK+2OeEdXdXTS1UkVup/V1jLfRUoL/3vpX 58XcFRBOKV7ILTnD5wQf+K+xnsaZxA7UUypmsDUggGWYnkydvduTj/ctRlfm ANJjWv8p+F; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:59:45 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, July 09, 2009 7:43 AM > To: Joe Touch > Cc: Dan Wing; multipathtcp@ietf.org > Subject: Re: [multipathtcp] Integration with SSL > > On 9 jul 2009, at 16:35, Joe Touch wrote: > > >> - client sends SYN over one path with MPTCP capability in it > >> - server responds with SYN/ACK with the MPTCP capability in it > >> - client ACKs the SYN/ACK and also sends a copy of the SYN over the > >> other path > >> - server sees that the other SYN belongs to the session created > >> before, > >> sends SYN/ACK > > > How does that happen? The first SYN was translated. What makes the > > second SYN look like the first one, i.e., it could be translated > > differently (by a different NAT or the same NAT)? > > There would have to be a cookie in the SYN packet. This isn't a problem created by NAT. The same problem (and solution) exists as without NAT, where the client system has two interfaces -- one interface (e.g., 802.11) with an IPv4 address from the ADSL provider and another interface (e.g., wired ethernet) from the cable provider. -d From touch@ISI.EDU Thu Jul 9 08:48:37 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AFE28C258 for ; Thu, 9 Jul 2009 08:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xvA+gJBHK+P for ; Thu, 9 Jul 2009 08:48:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DBA9F28C273 for ; Thu, 9 Jul 2009 08:48:36 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n69FmpdH004377; Thu, 9 Jul 2009 08:48:53 -0700 (PDT) Message-ID: <4A561163.3010608@isi.edu> Date: Thu, 09 Jul 2009 08:48:51 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dan Wing References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> In-Reply-To: <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 15:48:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Wing wrote: > > >> -----Original Message----- >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >> Sent: Thursday, July 09, 2009 7:43 AM >> To: Joe Touch >> Cc: Dan Wing; multipathtcp@ietf.org >> Subject: Re: [multipathtcp] Integration with SSL >> >> On 9 jul 2009, at 16:35, Joe Touch wrote: >> >>>> - client sends SYN over one path with MPTCP capability in it >>>> - server responds with SYN/ACK with the MPTCP capability in it >>>> - client ACKs the SYN/ACK and also sends a copy of the SYN over the >>>> other path >>>> - server sees that the other SYN belongs to the session created >>>> before, >>>> sends SYN/ACK >>> How does that happen? The first SYN was translated. What makes the >>> second SYN look like the first one, i.e., it could be translated >>> differently (by a different NAT or the same NAT)? >> There would have to be a cookie in the SYN packet. > > This isn't a problem created by NAT. > > The same problem (and solution) exists as without NAT, where the client system > has two interfaces -- one interface (e.g., 802.11) with an IPv4 address from > the ADSL provider and another interface (e.g., wired ethernet) from the cable > provider. In a system with two interfaces, you can know how to emit the SYN over the "other path". In a system with some NATs, it's not always possible to know where paths are. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpWEWMACgkQE5f5cImnZrvl9ACfeO18FR7D56NbfZIt8y8++pgm iFYAoOz3gBkf6rkn9PhteZnxvaqXu4BJ =JTmZ -----END PGP SIGNATURE----- From dwing@cisco.com Thu Jul 9 08:59:53 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AA33A6A15 for ; Thu, 9 Jul 2009 08:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl7cP6g-vLsd for ; Thu, 9 Jul 2009 08:59:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 852013A6BAD for ; Thu, 9 Jul 2009 08:59:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,374,1243814400"; d="scan'208";a="184435950" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2009 16:00:14 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n69G0EtI030001; Thu, 9 Jul 2009 09:00:14 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n69G0Eli003519; Thu, 9 Jul 2009 16:00:14 GMT From: "Dan Wing" To: "'Joe Touch'" References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> <4A561163.3010608@isi.edu> Date: Thu, 9 Jul 2009 09:00:13 -0700 Message-ID: <003601ca00ae$58544e30$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A561163.3010608@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoArMmXQc2VO1iBSgSrrQ6qFQExvgAAOPGA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2344; t=1247155214; x=1248019214; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[multipathtcp]=20Integration=20with=20S SL |Sender:=20; bh=XK4EaOix5dFiTAK+JPdsr29xHrH1xHSiySqJEEDUe/c=; b=Wx05qgy8bmOIBFzA7rfMDPoSe3uwDbZ4VBpXR6/Ghz8/I79Esou8St8Ze4 PrDLCYOYHVWoDHU/lzRjPw8vP7HK26Mn4DfrY1xdrtFHydpCLNo8surcmmZN KI0A/cl8XR; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 15:59:53 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Thursday, July 09, 2009 8:49 AM > To: Dan Wing > Cc: 'Iljitsch van Beijnum'; multipathtcp@ietf.org > Subject: Re: [multipathtcp] Integration with SSL > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Dan Wing wrote: > > > > > >> -----Original Message----- > >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > >> Sent: Thursday, July 09, 2009 7:43 AM > >> To: Joe Touch > >> Cc: Dan Wing; multipathtcp@ietf.org > >> Subject: Re: [multipathtcp] Integration with SSL > >> > >> On 9 jul 2009, at 16:35, Joe Touch wrote: > >> > >>>> - client sends SYN over one path with MPTCP capability in it > >>>> - server responds with SYN/ACK with the MPTCP capability in it > >>>> - client ACKs the SYN/ACK and also sends a copy of the > SYN over the > >>>> other path > >>>> - server sees that the other SYN belongs to the session created > >>>> before, > >>>> sends SYN/ACK > >>> How does that happen? The first SYN was translated. What makes the > >>> second SYN look like the first one, i.e., it could be translated > >>> differently (by a different NAT or the same NAT)? > >> There would have to be a cookie in the SYN packet. > > > > This isn't a problem created by NAT. > > > > The same problem (and solution) exists as without NAT, > > where the client system > > has two interfaces -- one interface (e.g., 802.11) with an > > IPv4 address from > > the ADSL provider and another interface (e.g., wired > > ethernet) from the cable provider. > > In a system with two interfaces, you can know how to emit the SYN over > the "other path". In a system with some NATs, it's not always possible > to know where paths are. I will agree with you all day that NATs break things and NATs add complexity. My point was that NATs do not create the need for Iljitsch's suggestion to put a cookie in the SYN; a PC with two interfaces to two ISPs (and no NAT on the path) will need to send the same cookie in the SYN. -d > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpWEWMACgkQE5f5cImnZrvl9ACfeO18FR7D56NbfZIt8y8++pgm > iFYAoOz3gBkf6rkn9PhteZnxvaqXu4BJ > =JTmZ > -----END PGP SIGNATURE----- From iljitsch@muada.com Thu Jul 9 09:09:17 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F13928C1CC for ; Thu, 9 Jul 2009 09:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGwa8mlZoFW2 for ; Thu, 9 Jul 2009 09:09:16 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 7717F3A6C70 for ; Thu, 9 Jul 2009 09:09:16 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n69G92HK080835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jul 2009 18:09:02 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Dan Wing" In-Reply-To: <003601ca00ae$58544e30$c4f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 18:08:59 +0200 References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> <4A561163.3010608@isi.edu> <003601ca00ae$58544e30$c4f0200a@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org, 'Joe Touch' Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:09:17 -0000 On 9 jul 2009, at 18:00, Dan Wing wrote: > My point was that NATs do not create the need for Iljitsch's > suggestion to put a cookie in the SYN; a PC with two interfaces to > two ISPs (and no NAT on the path) will need to send the same cookie > in the SYN. Indeed. The reason why I jumped on the NAT here is because if you want to do explicit address negotiation, the no NAT no firewall case is simple, but things get complex fast when you add middleboxes. With the implicit system I outlined, NAT doesn't introduce additional complexities. From touch@ISI.EDU Thu Jul 9 09:32:42 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15203A6D14 for ; Thu, 9 Jul 2009 09:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEQdR+zcpOvJ for ; Thu, 9 Jul 2009 09:32:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 10B9528C206 for ; Thu, 9 Jul 2009 09:32:39 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n69GWWgk015316; Thu, 9 Jul 2009 09:32:34 -0700 (PDT) Message-ID: <4A561B9D.10606@isi.edu> Date: Thu, 09 Jul 2009 09:32:29 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dan Wing References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> <4A561163.3010608@isi.edu> <003601ca00ae$58544e30$c4f0200a@cisco.com> In-Reply-To: <003601ca00ae$58544e30$c4f0200a@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:32:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Wing wrote: ... >> My point was that NATs do not create the need for Iljitsch's suggestion to put >> a cookie in the SYN; a PC with two interfaces to two ISPs (and no NAT on the >> path) will need to send the same cookie in the SYN. I'm wondering if the ISN is the cookie you need or if you need a longer one? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpWG50ACgkQE5f5cImnZrs9+QCgwCUyzyX7lzEnEnmivuPSSVq2 UxAAoPTLL93dKAeGcT3g9zmPgwGZ3gio =iJQA -----END PGP SIGNATURE----- From dwing@cisco.com Thu Jul 9 10:04:46 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1AA628C1FD for ; Thu, 9 Jul 2009 10:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVGVcu9YSvqC for ; Thu, 9 Jul 2009 10:04:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0BBBF28C268 for ; Thu, 9 Jul 2009 10:04:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,374,1243814400"; d="scan'208";a="175783207" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2009 17:05:08 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n69H58TM014951; Thu, 9 Jul 2009 10:05:08 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n69H57o3009223; Thu, 9 Jul 2009 17:05:07 GMT From: "Dan Wing" To: "'Joe Touch'" References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> <4A561163.3010608@isi.edu> <003601ca00ae$58544e30$c4f0200a@cisco.com> <4A561B9D.10606@isi.edu> Date: Thu, 9 Jul 2009 10:05:07 -0700 Message-ID: <00aa01ca00b7$696a4db0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A561B9D.10606@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoAsvBYhkidsd/aTjuz3vdZgx+HUgAA+KVQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=703; t=1247159108; x=1248023108; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[multipathtcp]=20Integration=20with=20S SL |Sender:=20; bh=kLMPelm83ORegS5/scfExHr3lKyj1N9+5j6bHMBXi6E=; b=d6IjYIWnH+ifsCBpedHua0AEG/vBkDYNUVK3nMMJ7lnY6MOdyR6mzhuFr+ d9r40aAhFVd7KFUGGQK4G38tYT2iUvQ7dH7FaQEUO8X0QtITADjPGJ0ahyma ktHKSNhLft; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:04:46 -0000 > Dan Wing wrote: > ... > >> My point was that NATs do not create the need for > Iljitsch's suggestion to put > >> a cookie in the SYN; a PC with two interfaces to two ISPs > (and no NAT on the > >> path) will need to send the same cookie in the SYN. > > I'm wondering if the ISN is the cookie you need or if you > need a longer one? IPv4 addresses are also 32 bits long and many things use IPv4 addresses as 'identity'. So the ISN could be sufficient. I notice that both Windows and FreeBSD send the initial SYN with the ACK=0. I don't know if there is a reason or purpose for setting ACK=0 in the initial SYN; but that might be a safe place to encode another 32 bits. -d From touch@ISI.EDU Thu Jul 9 10:36:15 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90DE28C245 for ; Thu, 9 Jul 2009 10:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edB60y-cdfQ1 for ; Thu, 9 Jul 2009 10:36:14 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B6E4228C236 for ; Thu, 9 Jul 2009 10:36:14 -0700 (PDT) Received: from [70.213.111.148] (148.sub-70-213-111.myvzw.com [70.213.111.148]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n69Ha7np000548; Thu, 9 Jul 2009 10:36:09 -0700 (PDT) Message-ID: <4A562A87.20606@isi.edu> Date: Thu, 09 Jul 2009 10:36:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dan Wing References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> <4A561163.3010608@isi.edu> <003601ca00ae$58544e30$c4f0200a@cisco.com> <4A561B9D.10606@isi.edu> <00aa01ca00b7$696a4db0$c4f0200a@cisco.com> In-Reply-To: <00aa01ca00b7$696a4db0$c4f0200a@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:36:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Wing wrote: >> Dan Wing wrote: >> ... >>>> My point was that NATs do not create the need for >> Iljitsch's suggestion to put >>>> a cookie in the SYN; a PC with two interfaces to two ISPs >> (and no NAT on the >>>> path) will need to send the same cookie in the SYN. >> I'm wondering if the ISN is the cookie you need or if you >> need a longer one? > > IPv4 addresses are also 32 bits long and many things use > IPv4 addresses as 'identity'. So the ISN could be sufficient. IP/port pair is 6 bytes, though (see below) there might be another place for the port. That presumes only the source IP/port is altered, though. > I notice that both Windows and FreeBSD send the initial > SYN with the ACK=0. I don't know if there is a reason or > purpose for setting ACK=0 in the initial SYN; but that > might be a safe place to encode another 32 bits. The Urgent field too, when URG=0. That presumes that implementations correctly ignore these fields, rather than making assumptions about them ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpWKocACgkQE5f5cImnZrvF3ACfb7rt9tkpegJFPfqg0mw9+Is1 AZkAnjlJ7KvUmG27RWiCcsBhe7Di1vay =HRtR -----END PGP SIGNATURE----- From touch@ISI.EDU Thu Jul 9 11:30:14 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD85C28C2A2 for ; Thu, 9 Jul 2009 11:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIRqPYL2yUFr for ; Thu, 9 Jul 2009 11:30:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D387F28C29F for ; Thu, 9 Jul 2009 11:30:13 -0700 (PDT) Received: from [75.215.61.103] (103.sub-75-215-61.myvzw.com [75.215.61.103]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n69IU7Rw014583; Thu, 9 Jul 2009 11:30:10 -0700 (PDT) Message-ID: <4A56372F.10007@isi.edu> Date: Thu, 09 Jul 2009 11:30:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Scott Brim References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <4A55CE75.9070107@gmail.com> In-Reply-To: <4A55CE75.9070107@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:30:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Brim wrote: > Joe Touch allegedly wrote on 07/09/2009 2:38 AM: >> It might be useful to show how multipath TCP makes sense over NATs >> first, since NATs could destroy the multipathing. > > Joe, what do you mean, "makes sense"? Do you mean how it would work? How it would work is a solution. Makes sense just requires explaining how a solution could exist. If you multipath and both paths go through a NAT, even if the paths have different properties, the question is whether you can detect the existence of the different paths, and whether you can control the segments you send to determine which path they would use. If you can't do both, a solution isn't worth looking for, AFAICT. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpWNy8ACgkQE5f5cImnZrtsnwCcDMljKJFhXiWTggyr36ZdHnL9 I64AnjhqOmIUzmDrzkKUnpuL0u20fJCc =rTUb -----END PGP SIGNATURE----- From ayourtch@cisco.com Fri Jul 10 20:25:38 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26BB3A69FD for ; Fri, 10 Jul 2009 20:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO2G5Mb1kY0y for ; Fri, 10 Jul 2009 20:25:37 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 559DE3A69E7 for ; Fri, 10 Jul 2009 20:25:37 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6B3Q3KN017303; Sat, 11 Jul 2009 05:26:04 +0200 (CEST) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6B3Q1IM000702; Sat, 11 Jul 2009 05:26:01 +0200 (CEST) Date: Sat, 11 Jul 2009 05:27:24 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Dan Wing In-Reply-To: <00aa01ca00b7$696a4db0$c4f0200a@cisco.com> Message-ID: References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> <4A561163.3010608@isi.edu> <003601ca00ae$58544e30$c4f0200a@cisco.com> <4A561B9D.10606@isi.edu> <00aa01ca00b7$696a4db0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: multipathtcp@ietf.org, 'Joe Touch' Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 03:25:39 -0000 On Thu, 9 Jul 2009, Dan Wing wrote: >> Dan Wing wrote: >> ... >>>> My point was that NATs do not create the need for >> Iljitsch's suggestion to put >>>> a cookie in the SYN; a PC with two interfaces to two ISPs >> (and no NAT on the >>>> path) will need to send the same cookie in the SYN. >> >> I'm wondering if the ISN is the cookie you need or if you >> need a longer one? > > IPv4 addresses are also 32 bits long and many things use > IPv4 addresses as 'identity'. So the ISN could be sufficient. ...unless there's a firewall in the middle randomizing the ISN. What about the TSVal within the timestamp option ? (Probably the TSVal in the second SYN would need to go via a PRF, and via the reverse PRF on the receiver side to do a check - because we can't assume the timestamps are uniformly distributed?). thanks, andrew From ayourtch@cisco.com Fri Jul 10 20:37:53 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616BC3A6A5F for ; Fri, 10 Jul 2009 20:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6BmLby+nucd for ; Fri, 10 Jul 2009 20:37:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 6D0133A6A28 for ; Fri, 10 Jul 2009 20:37:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6B3cJKt021431; Sat, 11 Jul 2009 05:38:19 +0200 (CEST) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6B3cHda005041; Sat, 11 Jul 2009 05:38:17 +0200 (CEST) Date: Sat, 11 Jul 2009 05:39:41 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Dan Wing In-Reply-To: Message-ID: References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> <4A561163.3010608@isi.edu> <003601ca00ae$58544e30$c4f0200a@cisco.com> <4A561B9D.10606@isi.edu> <00aa01ca00b7$696a4db0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: multipathtcp@ietf.org, 'Joe Touch' Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 03:37:53 -0000 On Sat, 11 Jul 2009, Andrew Yourtchenko wrote: > On Thu, 9 Jul 2009, Dan Wing wrote: > >> > Dan Wing wrote: >> > ... >> > > > My point was that NATs do not create the need for >> > Iljitsch's suggestion to put >> > > > a cookie in the SYN; a PC with two interfaces to two ISPs >> > (and no NAT on the >> > > > path) will need to send the same cookie in the SYN. >> > >> > I'm wondering if the ISN is the cookie you need or if you >> > need a longer one? >> >> IPv4 addresses are also 32 bits long and many things use >> IPv4 addresses as 'identity'. So the ISN could be sufficient. > > ...unless there's a firewall in the middle randomizing the ISN. > > What about the TSVal within the timestamp option ? > > (Probably the TSVal in the second SYN would need to go via a PRF, and via the > reverse PRF on the receiver side to do a check - because we can't assume the > timestamps are uniformly distributed?). ugh. re-reading my own mail - the presence or absence of PRF won't change a thing. So if the TSVal received from the different peers is not distributed randomly, too bad. thanks, andrew From dwing@cisco.com Sun Jul 12 13:56:58 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6303A6807 for ; Sun, 12 Jul 2009 13:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1kmu3bJFz5J for ; Sun, 12 Jul 2009 13:56:57 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 602BB3A6C83 for ; Sun, 12 Jul 2009 13:56:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,387,1243814400"; d="scan'208";a="85563078" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 12 Jul 2009 20:57:27 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6CKvR9M026664; Sun, 12 Jul 2009 13:57:27 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6CKvRPZ023252; Sun, 12 Jul 2009 20:57:27 GMT From: "Dan Wing" To: References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> <4A56003D.1000001@isi.edu> <360BA35E-F53A-47DC-8C6B-31B7408D5FDA@muada.com> <00ae01ca00a5$f5b5d9e0$c4f0200a@cisco.com> <4A561163.3010608@isi.edu> <003601ca00ae$58544e30$c4f0200a@cisco.com> <4A561B9D.10606@isi.edu> <00aa01ca00b7$696a4db0$c4f0200a@cisco.com> Date: Sun, 12 Jul 2009 13:57:26 -0700 Message-ID: <01a401ca0333$5d301c90$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoB11KqR03sYRviSvWQfyCo77BGvQBXAZLQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1193; t=1247432247; x=1248296247; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[multipathtcp]=20Integration=20with=20S SL |Sender:=20; bh=FYbYu1hi/2rQEADsmcsrH8nlIfp0MRk7Vw13dJEwiEY=; b=C2FtxmQrlPDB/4Ppm35VN63qIvEiGV9D4R67c8LAEh4yGMJ3byeLp8F6U+ VgbzuplrNFfJLGxumzFUaPMLkeH43IxSgyW+dk6bsxS0HnXKSYblmAgdIE2L moLc9fMhFo; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: multipathtcp@ietf.org, 'Joe Touch' Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 20:56:58 -0000 > -----Original Message----- > From: Andrew Yourtchenko [mailto:ayourtch@cisco.com] > Sent: Friday, July 10, 2009 8:27 PM > To: Dan Wing > Cc: 'Joe Touch'; multipathtcp@ietf.org > Subject: Re: [multipathtcp] Integration with SSL > > On Thu, 9 Jul 2009, Dan Wing wrote: > > >> Dan Wing wrote: > >> ... > >>>> My point was that NATs do not create the need for > >> Iljitsch's suggestion to put > >>>> a cookie in the SYN; a PC with two interfaces to two ISPs > >> (and no NAT on the > >>>> path) will need to send the same cookie in the SYN. > >> > >> I'm wondering if the ISN is the cookie you need or if you > >> need a longer one? > > > > IPv4 addresses are also 32 bits long and many things use > > IPv4 addresses as 'identity'. So the ISN could be sufficient. > > ...unless there's a firewall in the middle randomizing the ISN. Ugh. Good point. -d > What about the TSVal within the timestamp option ? > > (Probably the TSVal in the second SYN would need to go via a PRF, and > via the reverse PRF on the receiver side to do a check - > because we can't > assume the timestamps are uniformly distributed?). > > thanks, > andrew > From alan.ford@roke.co.uk Tue Jul 14 01:29:15 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149C13A6E52 for ; Tue, 14 Jul 2009 01:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0TMHGW+5Yhn for ; Tue, 14 Jul 2009 01:29:14 -0700 (PDT) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id AF6963A6AEB for ; Tue, 14 Jul 2009 01:28:50 -0700 (PDT) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id n6E8SWD5019116 for ; Tue, 14 Jul 2009 09:28:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA045D.126ABBD9" Date: Tue, 14 Jul 2009 09:28:29 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D68080B3EE6@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ford-mptcp-multiaddressed-01.txt Thread-Index: AcoEXREHpxqkurUFRnGL5gVmJ20hLg== From: "Ford, Alan" To: X-roke-co-uk-MailScanner-ID: n6E8SWD5019116 X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Subject: [multipathtcp] FW: I-D Action:draft-ford-mptcp-multiaddressed-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 08:29:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA045D.126ABBD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We have submitted a new version of our MPTCP design draft - please see details below. We have made numerous changes based upon feedback received on and off list (including consolidating address management, removal of resync, and many other clarifications), as well as adding new discussion about congestion control. This is the version we intend to present and discuss in Stockholm. Regards, Alan -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 13 July 2009 20:00 To: i-d-announce@ietf.org Subject: I-D Action:draft-ford-mptcp-multiaddressed-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TCP Extensions for Multipath Operation with Multiple Addresses Author(s) : A. Ford, et al. Filename : draft-ford-mptcp-multiaddressed-01.txt Pages : 31 Date : 2009-07-13 Often endpoints are connected by multiple paths, but the nature of TCP/IP restricts communications to a single path per socket. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through higher throughput and improved resilience to network failure. This document presents extensions to TCP in order to transparently provide this multi-path functionality at the transport layer, if at least one endpoint is multi-addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ford-mptcp-multiaddressed-01.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01CA045D.126ABBD9 Content-Type: application/octet-stream; name="draft-ford-mptcp-multiaddressed-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ford-mptcp-multiaddressed-01.URL Content-Disposition: attachment; filename="draft-ford-mptcp-multiaddressed-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1mb3JkLW1wdGNwLW11bHRpYWRkcmVzc2VkLTAxLnR4dA0K ------_=_NextPart_001_01CA045D.126ABBD9 Content-Type: text/plain; name="ATT8841658.txt" Content-Transfer-Encoding: base64 Content-Description: ATT8841658.txt Content-Disposition: attachment; filename="ATT8841658.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01CA045D.126ABBD9-- From iljitsch@muada.com Tue Jul 14 10:21:22 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A87D3A6EE4 for ; Tue, 14 Jul 2009 10:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+mVHuyztQTH for ; Tue, 14 Jul 2009 10:21:21 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2233A6A22 for ; Tue, 14 Jul 2009 10:21:21 -0700 (PDT) Received: from [192.168.2.4] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6EHJg3H040714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Jul 2009 19:19:43 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <56D082B7-7822-4255-9FF3-AFBBBEC0AF03@muada.com> From: Iljitsch van Beijnum To: "Ford, Alan" In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D68080B3EE6@rsys005a.comm.ad.roke.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 19:19:41 +0200 References: <2181C5F19DD0254692452BFF3EAF1D68080B3EE6@rsys005a.comm.ad.roke.co.uk> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] FW: I-D Action:draft-ford-mptcp-multiaddressed-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 17:21:22 -0000 On 14 jul 2009, at 10:28, Ford, Alan wrote: > This is the version we intend to present and discuss in Stockholm. Hang on, I was under the impression that there wouldn't be presentations of the drafts in Stockholm to keep the discussion high- level? From alan.ford@roke.co.uk Tue Jul 14 16:29:39 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B4F3A677D for ; Tue, 14 Jul 2009 16:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhXNtn+Y1SDL for ; Tue, 14 Jul 2009 16:29:38 -0700 (PDT) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id C028A3A6868 for ; Tue, 14 Jul 2009 16:28:54 -0700 (PDT) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id n6ENISmC027234; Wed, 15 Jul 2009 00:18:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2009 00:18:25 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D68080B40D8@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <56D082B7-7822-4255-9FF3-AFBBBEC0AF03@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] FW: I-D Action:draft-ford-mptcp-multiaddressed-01.txt Thread-Index: AcoEp5tJ9Vyem4LARgO2Ag4M78s3igAMFyrA References: <2181C5F19DD0254692452BFF3EAF1D68080B3EE6@rsys005a.comm.ad.roke.co.uk> <56D082B7-7822-4255-9FF3-AFBBBEC0AF03@muada.com> From: "Ford, Alan" To: "Iljitsch van Beijnum" X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] FW: I-D Action:draft-ford-mptcp-multiaddressed-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 23:29:39 -0000 Iljitsch, Yes, my apologies, that was a poor choice of words. We will not be _presenting_ the draft per se, however it does contain the gist of many of the topics that I will be talking about. It also now includes some of the congestion control aspects that Costin will be covering. As regarding discussion - we are also, of course, very keen to discuss anything in this draft in Stockholm, outside the BOF itself! Regards, Alan > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: 14 July 2009 18:20 > To: Ford, Alan > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] FW: I-D Action:draft-ford-mptcp-multiaddressed- > 01.txt >=20 > On 14 jul 2009, at 10:28, Ford, Alan wrote: >=20 > > This is the version we intend to present and discuss in Stockholm. >=20 > Hang on, I was under the impression that there wouldn't be > presentations of the drafts in Stockholm to keep the discussion high- > level? From rrs@lakerest.net Sat Jul 18 07:00:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5443A69E2 for ; Sat, 18 Jul 2009 07:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.871 X-Spam-Level: X-Spam-Status: No, score=0.871 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3fcSGXYEM+q for ; Sat, 18 Jul 2009 07:00:39 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 05FDA3A687E for ; Sat, 18 Jul 2009 07:00:37 -0700 (PDT) Received: from mobile-166-129-072-095.mycingular.net ([166.129.72.95]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n6IDaIdO090975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 18 Jul 2009 09:37:33 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1247924329; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=Es/rso8O5PhdZVAJPMKlywR7eNi8gHbEfgrQ1fXjoc8afvOoBzyOEiW H+tUtrZ7UXVRbrbrOT8H8CaWi4fVQbQ== Message-Id: From: Randall Stewart To: Magnus Westerlund In-Reply-To: <4A51E8D2.4000600@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 18 Jul 2009 09:35:47 -0400 References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org, Scott Brim Subject: Re: [multipathtcp] Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 14:00:40 -0000 Magnus/Scott: I have long wanted to write a post to this mailing list but have never had the time to read through all the threads and drafts here... just too many other things to do... sorry... I guess I never will so before this becomes a wg I think I better say my 2 cents... I must say some of the topics intrigue me, such as: "We don't need to detect shared bottlenecks"... Shared bottlenecks is the only reason the FreeBSD version of SCTP does =20= not have CMT (Jana's work... i.e. multipath-sctp) turned on by default. So yes these are interesting questions. Questions that I would like to see the answers too. These questions do need a broader answer then what would be done in this BOF/WG... but the deployable work of this WG would definitely be dependent on the answers to those questions IMO. Now, as far as multi-path TCP goes, I really don't understand it. To me the IETF is doing the same thing it did with NAT and IPV6. Here about 10 years ago we standardize a new transport protocol (SCTP) it has three principle features beyond what TCP offers: - multi-homing (and with Jana's work multi-path) - multi-streaming (to get rid of head of line blocking) - message boundary preservation. And in fact we just finished another one to replace UDP, DCCP adding congestion control to that protocol. In both of these cases we did the architecturally "right" thing and =20 just went ahead and built a new protocol to do what we wanted to do. So what happens a bit later... we decide that we need to get the multi-path/homing feature and hack it into TCP. So I pose the question why? The answer, proponents will say, is that really SCTP and DCCP are not deployable due to NAT. After all you have to get every vendor to change all the NAT and F/W =20 implementations to deal with SCTP and DCCP. This is just an impossible task and it rules out any other transport ever being built.... (I disagree.. but =20 Jonathan and others have made this point). Maybe we should expand the charter a bit and add multi-streaming to this work as well? After all this is another issue with TCP as well.. and =20 in fact one more obvious to the user.... (take a look at Preethi's work on web traffic and multi-streaming if you doubt me) and as long as were at it =20= lets go ahead and get some message boundaries applied .. we did a half job of that in =20 RDDP with their framing RFC's... lets make that more useable to the TCP programmer.. That way, in the end, we will have cannibalized SCTP and =20= morphed TCP into something else... It probably would have been easier just to re-use protocol ID 6 but hey we can hack it together... it will be a mess... it won't be as efficient as doing it right (see Jana's original work if you dis-believe me).. but at least we kept those NAT's happy... ;-( Just like V6 we will once again let the tail (NAT) wag the dog =20 (Transport Protocols). With V6 it was time pressures, now its just this "embedded" base of =20 NAT's... R On Jul 6, 2009, at 8:06 AM, Magnus Westerlund wrote: > Hi, > > I would like to point out that from my perspective one of the biggest > goal of the BOF is to discuss the really high level questions that you > can't trust a future WG to sort out. Thus details in the protocol > proposals are maybe not relevant unless they really results in such > diverse protocol results or have significant difference in how they > impact the network. > > So, as Scott writes considering the description and commenting already > know on what you think are question is really helpful. > > I do hope that we will see a charter proposal more than one week prior > to the IETF meeting. > > Cheers > > Magnus > > Scott Brim skrev: >> Mark Handley allegedly wrote on 07/01/2009 6:24 PM: >>> Introduction: Scope, Intention, Process >>> Scott Brim >>> 5 minutes >> >> Since we have very little free time in the BOF agenda, I wanted to do >> scope and logistics bashing on the mailing list if possible. >> >> Take a look at the BOF description at >> . >> The goal of this BOF is to evaluate support for a working group to >> develop multipath TCP. The working group would focus on multipath =20= >> TCP >> protocol development, including API extensions. >> >> We expect that research on multipath transport and transport in =20 >> general >> will continue in parallel, and may affect this WG, but they will =20 >> not be >> done in this WG. A working group needs a clear initial focus on a =20= >> few >> tasks. Later on, after actually accomplishing something, it can =20 >> open up >> and do a little more broad multitasking. In particular this leaves =20= >> out >> SCTP, for which I apologize, but I hope you agree with the need for =20= >> focus. >> >> Also, during the presentations we will try to stick to clarifying >> questions only. After all the presentations are done, we can have a >> general discussion on the issues led by Mark. >> >> If you have any comments with any of this, please let the list know. >> >> Thanks ... Scott >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> > > > --=20 > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From iljitsch@muada.com Sat Jul 18 07:32:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15E43A6945 for ; Sat, 18 Jul 2009 07:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV+w+1GNZzbI for ; Sat, 18 Jul 2009 07:32:35 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id BF6D13A69DE for ; Sat, 18 Jul 2009 07:29:16 -0700 (PDT) Received: from [192.168.2.4] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6IESkqH073211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Jul 2009 16:28:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Randall Stewart In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 18 Jul 2009 16:28:51 +0200 References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 14:32:35 -0000 On 18 jul 2009, at 15:35, Randall Stewart wrote: > Here about 10 years ago we standardize a new transport protocol (SCTP) > it has three principle features beyond what TCP offers: > - multi-homing (and with Jana's work multi-path) > - multi-streaming (to get rid of head of line blocking) > - message boundary preservation. It also has: - a dumb keepalive mechanism on the additional address pairs that generates unnecessary traffic - a complex chunk structure that is much harder to implement with low overhead - a checksum that is expensive to calculate in software - no provisions for migration from TCP to SCTP The multipath that is currently in SCTP assumes the use of different addresses on both sides to make the packets flow over different paths. While that is certainly a useful approach, it's not the only one. As such, even in a world without NAT SCTP wouldn't be a very good way to deploy multipath transport across the internet. Which isn't surprising, because it wasn't designed for that. From rrs@lakerest.net Sat Jul 18 08:33:49 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCA13A695D for ; Sat, 18 Jul 2009 08:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39Cs0Wlm5FNA for ; Sat, 18 Jul 2009 08:33:39 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 3F9C53A6A99 for ; Sat, 18 Jul 2009 08:33:38 -0700 (PDT) Received: from mobile-166-129-072-095.mycingular.net ([166.129.72.95]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n6IFXL8r003279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 18 Jul 2009 11:33:34 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1247931215; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=Qiu9rIltYOrtiJfc57WMnjOStS+Vj7m5JZskiV6JPPq3A07h/9fDWAk JTcxg9lDm1K9E9l1I9Ug/HIKVWMjbmA== Message-Id: <9967A796-050D-4BCD-86E6-648738EEDA7F@lakerest.net> From: Randall Stewart To: Iljitsch van Beijnum In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 18 Jul 2009 11:32:50 -0400 References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 15:33:49 -0000 On Jul 18, 2009, at 10:28 AM, Iljitsch van Beijnum wrote: > On 18 jul 2009, at 15:35, Randall Stewart wrote: > >> Here about 10 years ago we standardize a new transport protocol >> (SCTP) >> it has three principle features beyond what TCP offers: >> - multi-homing (and with Jana's work multi-path) >> - multi-streaming (to get rid of head of line blocking) >> - message boundary preservation. > > It also has: > > - a dumb keepalive mechanism on the additional address pairs that > generates unnecessary traffic Which is completely configurable by the user if they want it or not.. very similar in some respects to TCP-KeepAlive. Only real difference is that SCTP is on by default and TCP is off by default. > - a complex chunk structure that is much harder to implement with > low overhead I won't argue implementation issues... I have seen TCP stacks that are rather obtuse as well ;-) > - a checksum that is expensive to calculate in software And there is now hardware that does it (just like TCP).. and by the way this is also a feature since data corruption is often an issue and TCP will often let bad data through that passes its weak checksum. > - no provisions for migration from TCP to SCTP Thats strange you say this, since with 1 minor change one can move to SCTP from TCP i.e. instead of sd = socket(AF_INET, SOCK_STREAM, 0); you do sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); I don't know how much easier you can make it.. unless you want it transparent .. and that was done too by Ryan Bickhart at the Univ of Delaware as well.. Completely redesigning a protocol to do things it was not intended calls for a new protocol, not hacking up an existing one.. As Joe used to say in the RDDP debates... protocol ID 6 is taken choose another one ;-) R > > The multipath that is currently in SCTP assumes the use of different > addresses on both sides to make the packets flow over different > paths. While that is certainly a useful approach, it's not the only > one. > > As such, even in a world without NAT SCTP wouldn't be a very good > way to deploy multipath transport across the internet. Which isn't > surprising, because it wasn't designed for that. > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From iljitsch@muada.com Sat Jul 18 08:53:28 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62DE3A6857 for ; Sat, 18 Jul 2009 08:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.522 X-Spam-Level: X-Spam-Status: No, score=-4.522 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MjQTSEBP2gy for ; Sat, 18 Jul 2009 08:53:28 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D0B6D3A6831 for ; Sat, 18 Jul 2009 08:53:27 -0700 (PDT) Received: from [192.168.2.4] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6IFo8sI073753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Jul 2009 17:50:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <7EEE9DF7-BB3F-4044-9CA1-9FF8EC9D6335@muada.com> From: Iljitsch van Beijnum To: Randall Stewart In-Reply-To: <9967A796-050D-4BCD-86E6-648738EEDA7F@lakerest.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 18 Jul 2009 17:50:13 +0200 References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> <9967A796-050D-4BCD-86E6-648738EEDA7F@lakerest.net> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 15:53:28 -0000 On 18 jul 2009, at 17:32, Randall Stewart wrote: [...] I'd be happy to argue the individual points, but the conclusion is plain and simple: the tradeoffs that SCTP makes are different than the ones TCP makes, which renders it a non-starter for many purposes. >> - no provisions for migration from TCP to SCTP > Thats strange you say this, since with 1 minor change one can > move to SCTP from TCP i.e. You're missing the point. Which is that if a client wants to talk to a server, the client has no way of knowing if the server uses TCP or SCTP. (Of course if the client did know it still wouldn't know if there was a middlebox that breaks SCTP in the middle.) > Completely redesigning a protocol to do things it was not intended > calls > for a new protocol, not hacking up an existing one.. In the case of the one-ended multipath TCP that seems a rather curious remark as it interoperates with unmodified TCP implementations at the other end, that hardly suggests a protocol number change is in order. From Michael.Tuexen@lurchi.franken.de Sat Jul 18 10:29:45 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0FA3A68B4 for ; Sat, 18 Jul 2009 10:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.908 X-Spam-Level: ** X-Spam-Status: No, score=2.908 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXLao6y3wnc0 for ; Sat, 18 Jul 2009 10:29:44 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 5A82F3A689A for ; Sat, 18 Jul 2009 10:29:44 -0700 (PDT) Received: from [192.168.1.100] (p508FE9F5.dip.t-dialin.net [80.143.233.245]) by mail-n.franken.de (Postfix) with ESMTP id A08BF1C0B4613; Sat, 18 Jul 2009 19:29:39 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Iljitsch van Beijnum In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 18 Jul 2009 19:29:38 +0200 References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 17:29:45 -0000 On Jul 18, 2009, at 4:28 PM, Iljitsch van Beijnum wrote: > On 18 jul 2009, at 15:35, Randall Stewart wrote: > >> Here about 10 years ago we standardize a new transport protocol >> (SCTP) >> it has three principle features beyond what TCP offers: >> - multi-homing (and with Jana's work multi-path) >> - multi-streaming (to get rid of head of line blocking) >> - message boundary preservation. > > It also has: > > - a dumb keepalive mechanism on the additional address pairs that > generates unnecessary traffic > - a complex chunk structure that is much harder to implement with > low overhead > - a checksum that is expensive to calculate in software > - no provisions for migration from TCP to SCTP Are you talking here about the API level or the network level? Does multi-path TCP provide the same server as TCP: a byte stream where each byte is delivered exactly once to the user at the receiving side in the same sequence as sent by the user at the sending side? > > The multipath that is currently in SCTP assumes the use of different > addresses on both sides to make the packets flow over different > paths. While that is certainly a useful approach, it's not the only > one. > > As such, even in a world without NAT SCTP wouldn't be a very good > way to deploy multipath transport across the internet. Which isn't > surprising, because it wasn't designed for that. > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From mark.j.handley@gmail.com Mon Jul 20 02:35:25 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A9F3A6D1C for ; Mon, 20 Jul 2009 02:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdC2wcVo4fOm for ; Mon, 20 Jul 2009 02:35:25 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id C65553A6CA2 for ; Mon, 20 Jul 2009 02:35:24 -0700 (PDT) Received: by bwz28 with SMTP id 28so1842626bwz.37 for ; Mon, 20 Jul 2009 02:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=U3L9PxB4gmDHgkSlVmzz/kLy3+PLc8pckNCUZTEq7aU=; b=rEj0w+fA5KspfwbYoprLflDw+XSQPFDxDYuX6+f+s9xVeHNmTvTeoYi7EdQ0IAk65M PtZz4rRKP16GoPxJ/BjFHA5E0Iy0VzlcrfApay8LFaxq8L0NeIPlf5e0KJk7JQJA8KzY 2Gk70pbel2PG3VoNLiRjVJWk3Bc2YIzw959bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=hI9nsu8Yav3CE47Mq5yayalpn7FgzISTPIiqYO1bG2SeZulhlWTSnBY5VVgsp1hFXt Nh+bZPcN03puTQmXwwuEY8H/XRo1g6XTGlOFw+ht4vKOD296DBRiaLR/nWJfxEzQjNJV p+aEnvqlcrr1YFL6zFeLoDHPBSfkQzGiRuQZg= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.116.195 with SMTP id n3mr1130772faq.12.1248082122617; Mon, 20 Jul 2009 02:28:42 -0700 (PDT) In-Reply-To: References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> From: Mark Handley Date: Mon, 20 Jul 2009 10:28:22 +0100 X-Google-Sender-Auth: 088771f5fdcf544c Message-ID: <84a612dd0907200228h73ad733fp6550cd1bad32d4a7@mail.gmail.com> To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:35:25 -0000 On Sat, Jul 18, 2009 at 6:29 PM, Michael T=FCxen wrote: > Does multi-path TCP provide the same server as TCP: a byte stream > where each byte is delivered exactly once to the user at the receiving si= de > in the same sequence as sent by the user at the sending side? Yes. The intent is for unmodified apps to just work better. This does not preclude API extensions to allow new apps to have more control, especially over latency, but it must be the case that no existing TCP application needs to be changed. - Mark From Michael.Tuexen@lurchi.franken.de Mon Jul 20 04:40:51 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98EC23A6D38 for ; Mon, 20 Jul 2009 04:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.908 X-Spam-Level: ** X-Spam-Status: No, score=2.908 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z9eg6U6eMvT for ; Mon, 20 Jul 2009 04:40:48 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id AA3653A6D3B for ; Mon, 20 Jul 2009 04:40:47 -0700 (PDT) Received: from [192.168.1.100] (p508FC184.dip.t-dialin.net [80.143.193.132]) by mail-n.franken.de (Postfix) with ESMTP id 85DAD1C0B4624; Mon, 20 Jul 2009 13:40:43 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Mark Handley In-Reply-To: <84a612dd0907200228h73ad733fp6550cd1bad32d4a7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 13:40:42 +0200 References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> <84a612dd0907200228h73ad733fp6550cd1bad32d4a7@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 11:40:51 -0000 On Jul 20, 2009, at 11:28 AM, Mark Handley wrote: > On Sat, Jul 18, 2009 at 6:29 PM, Michael > T=FCxen wrote: >> Does multi-path TCP provide the same server as TCP: a byte stream >> where each byte is delivered exactly once to the user at the =20 >> receiving side >> in the same sequence as sent by the user at the sending side? > > Yes. The intent is for unmodified apps to just work better. > > This does not preclude API extensions to allow new apps to have more > control, especially over latency, but it must be the case that no > existing TCP application needs to be changed. Hi Mark, thanks for the answer. So you will have multiple "paths" below a single TCP socket, right? The MTCP stack below distributes the data over multiple paths and the receiver sides puts everything in the correct order and delivers is to a single socket. Right? Best regards Michael > > - Mark > From iljitsch@muada.com Mon Jul 20 05:25:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D6528C157 for ; Mon, 20 Jul 2009 05:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEgYyRTIhklY for ; Mon, 20 Jul 2009 05:25:34 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 174BE3A6D42 for ; Mon, 20 Jul 2009 05:25:33 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6KCPGRZ087026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Jul 2009 14:25:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <915BC570-ED0E-4835-84F4-70CBE32577E9@muada.com> From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 14:25:21 +0200 References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> <84a612dd0907200228h73ad733fp6550cd1bad32d4a7@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 12:25:35 -0000 On 20 jul 2009, at 13:40, Socrates wrote: > So you will have multiple "paths" below a single TCP socket, right? > The MTCP stack below distributes the data over multiple paths and > the receiver sides puts everything in the correct order and delivers > is to a single socket. Right? No, apparently you missed the part in the draft where it explains that the application is now required to handle the data in the order it is received from the network. From michael.tuexen@lurchi.franken.de Mon Jul 20 05:56:50 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010C628C17B for ; Mon, 20 Jul 2009 05:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.908 X-Spam-Level: ** X-Spam-Status: No, score=2.908 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUCEhkYG9Tdl for ; Mon, 20 Jul 2009 05:56:43 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 00EAD28C101 for ; Mon, 20 Jul 2009 05:56:42 -0700 (PDT) Received: from [192.168.1.100] (p508FC184.dip.t-dialin.net [80.143.193.132]) by mail-n.franken.de (Postfix) with ESMTP id 511671C0B4617; Mon, 20 Jul 2009 14:56:41 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Iljitsch van Beijnum In-Reply-To: <915BC570-ED0E-4835-84F4-70CBE32577E9@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 14:56:40 +0200 References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> <84a612dd0907200228h73ad733fp6550cd1bad32d4a7@mail.gmail.com> <915BC570-ED0E-4835-84F4-70CBE32577E9@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 12:56:50 -0000 On Jul 20, 2009, at 2:25 PM, Iljitsch van Beijnum wrote: > On 20 jul 2009, at 13:40, Socrates wrote: > >> So you will have multiple "paths" below a single TCP socket, right? >> The MTCP stack below distributes the data over multiple paths and >> the receiver sides puts everything in the correct order and delivers >> is to a single socket. Right? > > No, apparently you missed the part in the draft where it explains > that the application is now required to handle the data in the order > it is received from the network. > Well, I still need to read it... So sorry for the dump question. But this means that the application gets a service different from the service TCP is providing and therefore needs to be modified. This is contradicts with what Mark said. Or am I missing something? Best regards Michael From c.raiciu@cs.ucl.ac.uk Mon Jul 20 06:00:52 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FD63A69F8 for ; Mon, 20 Jul 2009 06:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvj97lDoaF0e for ; Mon, 20 Jul 2009 06:00:46 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id DDAF43A6A38 for ; Mon, 20 Jul 2009 06:00:45 -0700 (PDT) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1MSsGy-000Djz-Q8; Mon, 20 Jul 2009 13:47:16 +0100 In-Reply-To: References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> <84a612dd0907200228h73ad733fp6550cd1bad32d4a7@mail.gmail.com> <915BC570-ED0E-4835-84F4-70CBE32577E9@muada.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Costin Raiciu Date: Mon, 20 Jul 2009 14:00:21 +0100 To: =?ISO-8859-1?Q?Michael_T=FCxen?= X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 13:00:52 -0000 Hi, I assume Iljitsch was joking; Mark gave the straight answer: the =20 application still get in-order, byte-addressed, reliable delivery. Costin On 20 Jul 2009, at 13:56, Michael T=FCxen wrote: > On Jul 20, 2009, at 2:25 PM, Iljitsch van Beijnum wrote: > >> On 20 jul 2009, at 13:40, Socrates wrote: >> >>> So you will have multiple "paths" below a single TCP socket, right? >>> The MTCP stack below distributes the data over multiple paths and >>> the receiver sides puts everything in the correct order and delivers >>> is to a single socket. Right? >> >> No, apparently you missed the part in the draft where it explains =20 >> that the application is now required to handle the data in the =20 >> order it is received from the network. >> > Well, I still need to read it... So sorry for the dump question. > But this means that the application gets a service different from > the service TCP is providing and therefore needs to be modified. > This is contradicts with what Mark said. Or am I missing something? > > Best regards > Michael > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From iljitsch@muada.com Mon Jul 20 06:00:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3224C3A69F8 for ; Mon, 20 Jul 2009 06:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mNDSrleVIpa for ; Mon, 20 Jul 2009 06:00:58 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 37C123A6D5F for ; Mon, 20 Jul 2009 06:00:58 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6KD0cjB087355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Jul 2009 15:00:39 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <5F0A758C-7BD5-4C58-B637-30567FFF4D3A@muada.com> From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 15:00:43 +0200 References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> <84a612dd0907200228h73ad733fp6550cd1bad32d4a7@mail.gmail.com> <915BC570-ED0E-4835-84F4-70CBE32577E9@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 13:00:59 -0000 On 20 jul 2009, at 14:56, Michael T=FCxen wrote: > Well, I still need to read it... So sorry for the dump question. > But this means that the application gets a service different from > the service TCP is providing and therefore needs to be modified. > This is contradicts with what Mark said. Or am I missing something? Yes, the sarcasm. :-) As Mark wrote, the point is that for applications, it's still TCP as =20 usual. In the one-ended approach this goes so far that even to the =20 receiving TCP it's TCP as usual, except that packets will be reordered =20= somewhat more than usual.= From michael.tuexen@lurchi.franken.de Mon Jul 20 06:04:14 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755963A6D74 for ; Mon, 20 Jul 2009 06:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.908 X-Spam-Level: ** X-Spam-Status: No, score=2.908 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRkkUkudvZwT for ; Mon, 20 Jul 2009 06:04:08 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id A07E53A6D70 for ; Mon, 20 Jul 2009 06:04:08 -0700 (PDT) Received: from [192.168.1.100] (p508FC184.dip.t-dialin.net [80.143.193.132]) by mail-n.franken.de (Postfix) with ESMTP id 2E6371C0B4617; Mon, 20 Jul 2009 15:04:05 +0200 (CEST) Message-Id: <5A256396-1F01-4A4D-9E80-7F6574C06332@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Iljitsch van Beijnum In-Reply-To: <5F0A758C-7BD5-4C58-B637-30567FFF4D3A@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 15:04:04 +0200 References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> <84a612dd0907200228h73ad733fp6550cd1bad32d4a7@mail.gmail.com> <915BC570-ED0E-4835-84F4-70CBE32577E9@muada.com> <5F0A758C-7BD5-4C58-B637-30567FFF4D3A@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] SCTP, was: Re: Draft agenda for Stockholm BoF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 13:04:14 -0000 On Jul 20, 2009, at 3:00 PM, Iljitsch van Beijnum wrote: > On 20 jul 2009, at 14:56, Michael T=FCxen wrote: > >> Well, I still need to read it... So sorry for the dump question. >> But this means that the application gets a service different from >> the service TCP is providing and therefore needs to be modified. >> This is contradicts with what Mark said. Or am I missing something? > > Yes, the sarcasm. :-) > > As Mark wrote, the point is that for applications, it's still TCP as =20= > usual. In the one-ended approach this goes so far that even to the =20 > receiving TCP it's TCP as usual, except that packets will be =20 > reordered somewhat more than usual. OK, thanks. Best regards Michael From c.raiciu@cs.ucl.ac.uk Tue Jul 21 03:06:37 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318CA3A6AB7 for ; Tue, 21 Jul 2009 03:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAVhri0wsAWi for ; Tue, 21 Jul 2009 03:06:36 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 6BD493A6452 for ; Tue, 21 Jul 2009 03:06:36 -0700 (PDT) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1MTC0B-000E0C-8d for multipathtcp@ietf.org; Tue, 21 Jul 2009 10:51:15 +0100 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <5A256396-1F01-4A4D-9E80-7F6574C06332@lurchi.franken.de> References: <84a612dd0907011524n1e1d8913pecefae066247d10a@mail.gmail.com> <4A4E4CBC.5000703@gmail.com> <4A51E8D2.4000600@ericsson.com> <84a612dd0907200228h73ad733fp6550cd1bad32d4a7@mail.gmail.com> <915BC570-ED0E-4835-84F4-70CBE32577E9@muada.com> <5F0A758C-7BD5-4C58-B637-30567FFF4D3A@muada.com> <5A256396-1F01-4A4D-9E80-7F6574C06332@lurchi.franken.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <79E7EBD8-B56A-4861-BB69-D3B9A8C4DA73@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Tue, 21 Jul 2009 11:04:46 +0100 To: multipathtcp@ietf.org X-Mailer: Apple Mail (2.753.1) Subject: [multipathtcp] Multipath TCP documentation X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 10:06:37 -0000 Hi, We've revised the two-ended multipath TCP draft (current version is 01) to include comments we've received on this mailing list. The main changes from the previous version are: - addition of a size field to the data sequence number, to protect against middleboxes that fragment and reassemble TCP segments - convergence on a single proposal to do address management, that is based on "add address/remove address" tcp options. We've also created an additional document on design decisions for multipath TCP: this briefly explains why we multipath TCP looks as it does today. Despite a large solution space, real-world requirements have steered the design of the protocol to something really specific and narrow; we believe there are few alternative designs that meet the same requirements, but are of course more than willing to hear your thoughts and proposals. Both docs are referenced from the multipath wiki page: http:// trac.tools.ietf.org/area/tsv/trac/wiki/MultipathTcp See you at the IETF, Costin From scott.brim@gmail.com Sat Jul 25 02:13:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928073A6847 for ; Sat, 25 Jul 2009 02:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3lUN-knHSII for ; Sat, 25 Jul 2009 02:13:58 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 8ECFE3A67F1 for ; Sat, 25 Jul 2009 02:13:57 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so1187885qwd.31 for ; Sat, 25 Jul 2009 02:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=RxoMAvmLV4ijU74qGOxreeN4Tmc9SxIVBGdd0eqvdbk=; b=o/CyCrxj4QrtjLQQHwP/sz9w0rdEot4PtePOBQusGubvpqVVNa3yKft+XpmtZmael4 yIYRn5lUI4QPBYS6oSf5u9VNWxC3rSVEfEbvfI58TxQUA6XSNdS5rS+bzlSTCaYJ4z6h SfVMiGgsq4rtYfzGgkdhRXv0TRCy2Kk4YZ6/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=mVFARTmxwZ1mCDJ7NV2bx4p+VNXY5FDotcoDbGLNnkZw2NTG5+mon//0qVYwEdtzbH e2R/dOfDj9tkXZPsQj3gUbUbUmHZTO5D3A7Sed3ld+myKI91QKf+XokgHBqpBO645vvS bK6VRgZyQccp7SaNWvClUFNMFJqCMIpETo3a8= Received: by 10.224.74.13 with SMTP id s13mr4123010qaj.324.1248513235844; Sat, 25 Jul 2009 02:13:55 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 6sm6471007qwd.42.2009.07.25.02.13.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Jul 2009 02:13:55 -0700 (PDT) Message-ID: <4A6ACCD1.9050901@gmail.com> Date: Sat, 25 Jul 2009 11:13:53 +0200 From: Scott Brim User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] scribes and note takers - volunteer now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 09:13:59 -0000 It would be great if we could have meeting note takers and jabber scribes all lined up before we get to the Multipath TCP BOF. Otherwise we won't be able to start on time. Volunteers please? Unicast replies are fine. Scott From scott.brim@gmail.com Sat Jul 25 02:17:55 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42ED328C1DF for ; Sat, 25 Jul 2009 02:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MitD5mbZmM6F for ; Sat, 25 Jul 2009 02:17:54 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 81EC328C100 for ; Sat, 25 Jul 2009 02:17:54 -0700 (PDT) Received: by qyk41 with SMTP id 41so2797880qyk.29 for ; Sat, 25 Jul 2009 02:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=WW1/qAmQuhnAFtFSZZhok6btB6OGCIwaNboN/tR40PU=; b=NdAYCFJVcWQZmNP+HJHRDcTlCg1/Yqp+5WShhTL99HnKx0sYKfnjKtG54k8gOZsy/3 Xjv2cdFxe79SScG2UiCnc+Yl6/Jj5Dfjeldrx9mNdMITP5ShcqJZH559v4cAfBHUVm83 zRQfaERXWw8cZBH7CDYaCJ6fJzw5dVv+nQk1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=B3klp+TvIquZfJymLtnR8Ic7GIriOBx2UkB6FjOhaf3eaYxEiPAiEpvwk03djZ9t4D Nk3uRJGlHrmCv+HIgBBZLCGilT8rfsIB51CwbrUy8R++wBG/XAqS6DqM+AQM6qnskzAZ cpUWdRdby499NMBnmIdX3kmoLo5bU3fgSlMdM= Received: by 10.224.19.193 with SMTP id c1mr4248285qab.105.1248513473020; Sat, 25 Jul 2009 02:17:53 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 6sm6469679qwk.24.2009.07.25.02.17.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Jul 2009 02:17:52 -0700 (PDT) Message-ID: <4A6ACDBE.8030005@gmail.com> Date: Sat, 25 Jul 2009 11:17:50 +0200 From: Scott Brim User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] draft charter for Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 09:17:55 -0000 As a starting point for a draft charter, see http://trac.tools.ietf.org/area/tsv/trac/wiki/MpTcpBofDescription It lacks milestones, but those can be filled in once we agree on the work. Comments please. From jari.arkko@piuha.net Sun Jul 26 09:38:38 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BFB53A6843 for ; Sun, 26 Jul 2009 09:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuLqbwiLpY-v for ; Sun, 26 Jul 2009 09:38:37 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B3F673A6A04 for ; Sun, 26 Jul 2009 09:38:36 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4E256198714; Sun, 26 Jul 2009 19:38:37 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id C4516198660; Sun, 26 Jul 2009 19:38:36 +0300 (EEST) Message-ID: <4A6C868A.2050707@piuha.net> Date: Sun, 26 Jul 2009 19:38:34 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Scott W Brim Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] draft charter for Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 16:38:38 -0000 Scott, > Recent research has suggested that by making better use of the > multiple paths between endpoints we can better utilise the resources > within the network and thus improve resource pooling. In particular, > recent results include models of how multipath-capable end-systems > might respond to congestion signals, and what the potential benefits > might be (see [1] for a more details and references). > > If end systems could spread their load across multiple paths in the > right way, with the right reaction to the right congestion signals > from the network, then traffic would quickly move away from congested > or failed links in favor of available uncongested links. > > It is fairly intuitive to see that when multipath transport is used in > conjunction with congestion-dependent load-distribution, it is > possible to push more traffic through the network and to achieve > enhanced fault tolerance. Traffic will flow throught any available > path that has spare capacity, filling unused resources, while moving > away from failures and congested resources. The result is a more > flexible network, capable of functioning well, even when the actual > traffic matrix differs substantially from the traffic matrix envisaged > when the network was designed for. > > Currently used transport protocols use only one path at a time for > sending data. In particular TCP and DCCP use only one path and they > respond to congestion reducing their sending rate. SCTP on the other > hand, is aware of multiple paths, but it uses only one at the time, > reserving the alternative paths as backups in case of failure. All good. > The proposed work is to define the mechanisms to enable transport > protocols to use multiple paths simultaneously and to distribute the > load among the subflows of each path based on congestion. I know that you are going to be more specific in the next paragraph, but the above sounds like a general purpose transport work, and I would really like to see the MP-TCP work be specific to TCP. We have a very specific proposal that has the potential to be useful. Lets be clear about the focus being on that. The draft charter does not mention the ability/requirement for multipath TCP to pass through legacy NATs and work with legacy applications. These are important, and I think they should be mentioned. > In particular, the proposed work is to extend TCP to support > simultaneous data exchange through multiple paths. Two complementary > approaches are proposed: On one hand, to define a two-ended multipath > TCP that uses multiple addresses a-la SCTP to obtain multiple paths > and that requires support from both endpoints to use them. On the > other hand, single ended multipath TCP, where only one of the > endpoints involved in the communication is multipath aware and relies > on multipath routing capabilities provided by the IP routing to > deliver data towards a legacy TCP endpoint. These two approaches > provide a smooth deployment model, starting with the one-ended > multipath TCP, that only requires one end to deploy it and it results > in immediate benefits, and then when multipath TCP support becomes > pervasive, using the two-ended multipath TCP to obtain all the > potential benefits. I have my doubts about the one ended approach, but this is a good topic for the BOF to talk about -- what type of multipath TCP do we want to specify? > The proposed work items are: > > * A set of architectural guidelines for congestion dependent > multipath transport protocols. Since different transport protocols can > potentially benefit from this approach, this document describes the > motivations and the general approach that should be followed to enable > congestion dependent multipath transport. > * Extensions to current TCP to support the one-ended mutipath TCP. > * Extensions to current TCP to support the two-ended mutipath TCP. "mutipath" > * A threat analysis for multipath TCP Perhaps this should come first, and it should be understood that the two solution documents above need to include security mechanisms that deal with the threats. > * An extended API describing how applications can use multipath > transport. The API should also provide access to multipath information > and enable the control of the usage. Is this a mandatory or optional piece of the architecture? I think it would be very useful to have an API, but I also think it is central for the deployment of multipath TCP that it can work with unchanged applications. > The initial goal is that the documents produced by the WG will be > either experimental or informational. However, if when the documents > are ready the technology seems mature enough, the WG will consider if > it is appropriate to ask the IESG to advance the document as a > Proposed Standard. This is a little handwavy, but may be OK at this stage. One way to make progress in this question is to break down the required work into components, and see how ambitious they are. I suspect there are pieces which might be stable enough to become PS. But there certainly are other pieces that are for sure experimental at this stage. Here's one way to break the work down: - framework for understanding multipath transports (informational) - threats analysis (informational) - TCP extensions to support two-sided multipath TCP - security mechanisms - simple congestion algorithm, e.g., follow regular TCP for each subpath - advanced congestion algorithm > With respect to the work on the support for multipath in TCP, the only > acceptable modifications to the TCP packet format are in the form of > new TCP options. Ok Jari From ayourtch@gmail.com Sun Jul 26 21:10:44 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052643A6BCC for ; Sun, 26 Jul 2009 21:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts7iw1xzc4L9 for ; Sun, 26 Jul 2009 21:10:43 -0700 (PDT) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by core3.amsl.com (Postfix) with ESMTP id 02AA83A6BEE for ; Sun, 26 Jul 2009 21:10:42 -0700 (PDT) Received: by bwz12 with SMTP id 12so8570bwz.37 for ; Sun, 26 Jul 2009 21:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=LHRLneyQaqs7ysRgix4myUu8Ta+NB21PIScAaThzPOs=; b=o/kJuwyiqB++StK2EBjE3PdwX6ez5oou5EHdk5ngXeSjTprvxJ7HMHO49oAOd8Yfun 7U+UohD/FXQ88GO0amDuUHHrKjSu5q4eqf2ZauncKT8vaQDyZ66M6dCkp8+v29UP56gY z079V2jtZCohwQTugRjqyiFMdWYtAJOzEzY+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=tCtPNNxgLtZ6GsVg3PwFXluctROS1F1H9rfKs0lzp2ukDABjSerSf/X8RoBPFp2iQW FX+l93jFzbl1xAY9N4F/F6jTqKnl07X6KZfmxgMiFRpftVA5rqkoKu559pfvg0uBksas EbSMOAaaYwWoXuBZ2Ziv/Ifs+YNdMnhIMy2t8= MIME-Version: 1.0 Received: by 10.103.168.12 with SMTP id v12mr3036230muo.67.1248667840153; Sun, 26 Jul 2009 21:10:40 -0700 (PDT) Date: Mon, 27 Jul 2009 06:10:40 +0200 Message-ID: <530c5af60907262110wc59ec32yd01c38c0576300e1@mail.gmail.com> From: Andrew Yourtchenko To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] Multipath by using TLS - in scope or out of scope ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 04:10:44 -0000 There were some discussions earlier on the list about this, but I did not see the 100% concluded answer, and yesterday after a chat with Iljitsch I figured I'd send it - Using (appropriately extended) TLS as a mux/demux layer for multipath over plain unmodified TCP connections, is that something we consider in-scope ? thanks, andrew From Scott.Brim@gmail.com Sun Jul 26 22:18:50 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4EB83A6898 for ; Sun, 26 Jul 2009 22:18:50 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNTYiaZxe44E for ; Sun, 26 Jul 2009 22:18:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 099023A682E for ; Sun, 26 Jul 2009 22:18:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACXWbEpAZnme/2dsb2JhbAC4IYcIjnGEDQU X-IronPort-AV: E=Sophos;i="4.43,274,1246838400"; d="scan'208";a="51885466" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2009 05:18:49 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6R5InjB012551 for ; Mon, 27 Jul 2009 01:18:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6R5In8p004098 for ; Mon, 27 Jul 2009 05:18:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 01:18:48 -0400 Received: from cisco.com ([10.86.250.242]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 01:18:47 -0400 Date: Mon, 27 Jul 2009 07:18:44 +0200 From: Scott Brim To: multipathtcp@ietf.org Message-ID: <20090727051844.GF2693@cisco.com> Mail-Followup-To: Scott Brim , multipathtcp@ietf.org References: <4A6ACCD1.9050901@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A6ACCD1.9050901@gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 27 Jul 2009 05:18:48.0688 (UTC) FILETIME=[B8BFA700:01CA0E79] Authentication-Results: rtp-dkim-1; header.From=Scott.Brim@gmail.com; dkim=neutral Subject: Re: [multipathtcp] scribes and note takers - volunteer now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 05:18:50 -0000 Once again, we need volunteers to take notes and jabberscribe for the MPTCP BOF. We can't start the meeting without them, so please volunteer now to save us time. Scott From mark.j.handley@gmail.com Mon Jul 27 01:08:06 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA363A6C0F for ; Mon, 27 Jul 2009 01:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK+VGVQ71ySd for ; Mon, 27 Jul 2009 01:08:06 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id C08AA3A6C0E for ; Mon, 27 Jul 2009 01:08:05 -0700 (PDT) Received: by bwz21 with SMTP id 21so64038bwz.37 for ; Mon, 27 Jul 2009 01:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=ij4NkiSelF2iDpAQ/D3yYH9e0S2pq3IYD+lRuTG/x+g=; b=ZZVIDDZrQ7nDGiGcL6WFnxKCGVfV5KalDC2I/UOXQcNvMZwYd1+n51dZt7kL+gmdRZ KccSIcvWuYdeqsqikSfjOxhcgU3Lnd+cmrP/zmBxfUb+7dfVb3HZDkjLNQ8kU7RJV09/ eZZdrlNVF9gaUtd6GDyYUuXwKMaVDvH1VU8gQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; b=sLSllXXHLfBk+UICMcuj5MsTlgERcxnE9k4zyjTjQAlXorCytDRWOi76NY0wZyp39w iqkxPguf5dOpHWMj8bws2eoIKHFZeSvsGh3UDOtRZJxbkISaYothJc/SeRhf66JvwM+0 8pyOCsNtME60cwhNI9+9UjQqWz0Iz0X/0Mzg0= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.108.75 with SMTP id e11mr2429497fap.51.1248682084177; Mon, 27 Jul 2009 01:08:04 -0700 (PDT) From: Mark Handley Date: Mon, 27 Jul 2009 09:07:44 +0100 X-Google-Sender-Auth: 26694dfeb2143a4f Message-ID: <84a612dd0907270107j47f49de8g75dfb2614cfd7b70@mail.gmail.com> To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] Multipath congestion control X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:08:06 -0000 We finished a paper on Saturday on how to link the congestion controllers of the subflows in a multipath TCP session. Basically we: - link the increases of the subflows to the *total* window (not the subflow window) to achieve reasonable resource pooling in the network - compensate for differing RTTs, which would otherwise cause a multipath flow to do worse than a single-path flow. - use the additive increase constant as an aggressiveness controller, to ensure we do at least as well (in terms of rate) as a single-path flow, while ensuring we impose no more load on any single bottleneck than a single-path TCP would. I'm sure this won't be the last word on multi-path congestion control, but it does show that there is a conservative solution that works well and is safe enough for deployment. Costin Raiciu will talk briefly about this problem and how to solve it on Thursday. As the paper is under anonymous submission, I'm reluctant to send it directly to this list, but if you want a copy privately, please send me email. - Mark From c.raiciu@cs.ucl.ac.uk Mon Jul 27 05:59:03 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CF63A6994 for ; Mon, 27 Jul 2009 05:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWCrMe4Rr4Dd for ; Mon, 27 Jul 2009 05:59:02 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 325F63A6BEB for ; Mon, 27 Jul 2009 05:58:37 -0700 (PDT) Received: from dhcp-1373.meeting.ietf.org ([130.129.19.115]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1MVPWA-000HkQ-Bb; Mon, 27 Jul 2009 13:41:26 +0100 In-Reply-To: References: <4AFB7156-9AE7-4563-B613-D06BC736061A@muada.com> <4A51E78F.4080000@ericsson.com> <018701ca004b$88831680$e5a36b80@cisco.com> <4A559082.1020608@isi.edu> <01e901ca0065$6998a9f0$e5a36b80@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1EA98911-1122-4A5D-96DA-505E4825047E@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Mon, 27 Jul 2009 14:58:24 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Integration with SSL X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 12:59:03 -0000 Iljitsch, Please read the design decisions document we've made available. The reason we've included the complex looking explicit address signaling is because implicit signaling as you propose below does not work in all cases; fixing it to work in all cases effectively requires explicit signaling. As for the separation of sequence numbers, this has been a long- standing discussion. We know there are cases where using a single sequence number space does not work. Why are we still talking about this in the 2-ended case? In the single ended case, where there is no choice to have multiple sequence spaces, we have to live with single seq space. As for integrating one-ended with two ended, the difference resulting from one sequence space vs multiple sequence spaces is big enough that you effectively need "switch" from one to the other. The only way I see is to make them working together is to use the MPTCP negotiation in the beginning. For instance: 1. Start with MTCP capable option in the SYN 2. If the other end replies with MPATH capable, then use 2-ended algorithm. 3. If the other end doesn't include MPATH capable in his SYN, use one- ended mpath if you can. Is there more to that? Cheers Costin > I've also been thinking about a way to extend the one-ended MPTCP > into a simple two-ended MPTCP that can actually take advantage of > NAT. In multi6/shim6 we used to talk about "basement multihomers", > which would be people with two regular consumer type broadband > connections, for instance, one cable and one ADSL. Those users > would have two NATs for IPv4. An MPTCP would be able to take > advantage of that by talking to the same destination through both > NATs. It would work something like this: > > - client sends SYN over one path with MPTCP capability in it > - server responds with SYN/ACK with the MPTCP capability in it > - client ACKs the SYN/ACK and also sends a copy of the SYN over the > other path > - server sees that the other SYN belongs to the session created > before, sends SYN/ACK > - client ACKs the SYN/ACK > - data packets are distributed over the two (or more paths) > - every path is given a packet per window to advance the window > > This obviously requires both ends to be MPTCP but it doesn't > require the complex address negotiation in Alan's draft. I think it > can also work most of the time without a second sequence number space. > > It would be helpful if different capabilities, such as the ability > to bond additional implicitly created "sessions" as per the above, > the ability to negotiate addresses explicitly and the ability to > have a second sequence number space all individually, so there is a > smooth upgrade path from basic MPTCP to a more fully featured > MPTCP, where implementations with different capabilities can work > together. > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From scott.brim@gmail.com Mon Jul 27 07:01:57 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E855628C1AF for ; Mon, 27 Jul 2009 07:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i389985b9cHL for ; Mon, 27 Jul 2009 07:01:57 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 22A5428C1F6 for ; Mon, 27 Jul 2009 07:01:51 -0700 (PDT) Received: by ewy26 with SMTP id 26so3174677ewy.37 for ; Mon, 27 Jul 2009 07:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=sEsqVMUUJvnPuBrmR7+V9X6CNGBS9ESRI8tYDSrKCUA=; b=w8cUBevavCgJJsMp72iUNauiGceibB4eJFV00kJzCtjd6HFYYh0RIkZSc3PgL9mU1e yy3VWGCkCcR+YTuSNfmq0zmfsqi4pOg1NLfdBB9bBmT/YEaZGGNwbrk0AzNHjZcmrnEK 4gVAe0PzV8/1sTtNzsM3jy/1M8VKAbVZplc3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=AlQa2Enm9Ilt4bJTJLbeSKrtefz60/g1hF5epn39njgHAIVRkILOnZF/hyKZon43BM AKcEmxzCOQqycWnACZIB8TH4YghIicQa7QVAJTrMsHFWh4xL5yRjLJI3dS7btcoycavS Y2q0uHlV7ieHkdRlx+HZDE8/SesU3SpSuL7mg= Received: by 10.216.45.71 with SMTP id o49mr1627404web.57.1248703306170; Mon, 27 Jul 2009 07:01:46 -0700 (PDT) Received: from dhcp-57f7.meeting.ietf.org ([130.129.87.247]) by mx.google.com with ESMTPS id i6sm21113528gve.22.2009.07.27.07.01.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 07:01:43 -0700 (PDT) Message-ID: <4A6DB343.4070107@gmail.com> Date: Mon, 27 Jul 2009 16:01:39 +0200 From: Scott Brim User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Andrew Yourtchenko References: <530c5af60907262110wc59ec32yd01c38c0576300e1@mail.gmail.com> In-Reply-To: <530c5af60907262110wc59ec32yd01c38c0576300e1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath by using TLS - in scope or out of scope ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 14:01:58 -0000 Andrew Yourtchenko allegedly wrote on 07/27/2009 6:10 AM: > There were some discussions earlier on the list about this, but I did not see > the 100% concluded answer, and yesterday after a chat with Iljitsch I > figured I'd > send it - > > Using (appropriately extended) TLS as a mux/demux layer for multipath > over plain unmodified TCP connections, is that something we consider > in-scope ? Andrew: IMHO the purpose of the BOF is to decide whether to launch a WG for Multipath TCP. Other work can proceed in parallel. If you think the charter needs to include something, please say so. Scott From scott.brim@gmail.com Wed Jul 29 06:36:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 746653A709F for ; Wed, 29 Jul 2009 06:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSMK71Top83m for ; Wed, 29 Jul 2009 06:36:39 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 856443A709B for ; Wed, 29 Jul 2009 06:36:39 -0700 (PDT) Received: by bwz21 with SMTP id 21so692012bwz.37 for ; Wed, 29 Jul 2009 06:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=KUkn3g0y4rAuw8r3jGzIkmoSpCTRXxIq00KsUGFXats=; b=xfcWNZwK9nzYJcLENw5QQAPfUbbMiKAGW1tKfS75HT3t3adqbXfjdkRYscwyLij9m1 uomitURAm6jzSRI7CPmliix9U1liL0ArNp5qMn5eptImYZU2yjKhf7HWWLFiwrtPRdl5 0fcWiWAnxDScwt8SjZiZhRnCoxW711zeUcBW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=pbijj9gQ+9ufHfxXltP2gfeI1k09GGb7InG7A8F7rJ9wSQA9KGTQQTI3mNeDqTUY5K 0s5fnbDZ2NfWyilQ8e2D+VnnW5mh1c+UL7dLsNeRrKOD9gTKN4dJje2m48ZV0PKTCMox RZ1ssucwxojdOlAM3adc9GJxG1vbY1ArSonc0= Received: by 10.103.251.3 with SMTP id d3mr4412094mus.99.1248874577017; Wed, 29 Jul 2009 06:36:17 -0700 (PDT) Received: from dhcp-55fa.meeting.ietf.org ([130.129.85.250]) by mx.google.com with ESMTPS id i5sm1628203mue.55.2009.07.29.06.36.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 06:36:16 -0700 (PDT) Message-ID: <4A70504E.7020801@gmail.com> Date: Wed, 29 Jul 2009 15:36:14 +0200 From: Scott Brim User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] no note takers? no meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 13:36:40 -0000 Folks, we have a jabber scribe but no note takers. The meeting will not start until we have at least one note taker. Please volunteer today. Scott From scott.brim@gmail.com Wed Jul 29 07:09:11 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B233B3A6FB6 for ; Wed, 29 Jul 2009 07:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIiDpcmxwWvh for ; Wed, 29 Jul 2009 07:09:11 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id D6A803A703C for ; Wed, 29 Jul 2009 07:09:04 -0700 (PDT) Received: by fxm18 with SMTP id 18so413749fxm.37 for ; Wed, 29 Jul 2009 07:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=ws22kfSYLpMTG7/AhnXJ1zI9tBFVMqbMm11Nthi4o9I=; b=ZNGZqJNHkJ1QKoWaYFIrtUWhLJE3ePnzpGzWc2/Z6NdlKDXHjQlBdtB/05RYC9rP8o BGy8Q8gPafyj6ZU3+9pUwcxO9JePd3zCprgRylv3fif1WUYmpRJpizls+1q0IYpNgG8u KkVBm9xQv+9a45bxpUoIfpBPu9K47rdIheXX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=ECpgQCKcrHdRAmtP5ch1RbXz/PbTytge1l0C9jkDTt36ehRnhpW562RbN8UE0nwx0E 8cDeFeU1q+FcSJFAFoSXi84vlOy273m2UsQ61iXBF+NSAE2KptRJjZA0nzvmy8N5AwZX 6uaP43y3PGchYpVx3z1AMRY6q4e7WfOXTHIhY= Received: by 10.103.8.3 with SMTP id l3mr4653533mui.104.1248876542107; Wed, 29 Jul 2009 07:09:02 -0700 (PDT) Received: from dhcp-55fa.meeting.ietf.org ([130.129.85.250]) by mx.google.com with ESMTPS id 14sm5559472muo.3.2009.07.29.07.09.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 07:09:01 -0700 (PDT) Message-ID: <4A7057FA.6010705@gmail.com> Date: Wed, 29 Jul 2009 16:08:58 +0200 From: Scott Brim User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] materials uploaded X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 14:09:11 -0000 About half the presentations have been uploaded. Go to https://datatracker.ietf.org/meeting/75/materials.html Scott From daniel@haxx.se Wed Jul 29 13:34:09 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FDEE3A6CBB for ; Wed, 29 Jul 2009 13:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.059 X-Spam-Level: X-Spam-Status: No, score=-4.059 tagged_above=-999 required=5 tests=[AWL=-1.810, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qhmO7Lov0aD for ; Wed, 29 Jul 2009 13:34:08 -0700 (PDT) Received: from kluster1.contactor.se (kluster1.contactor.se [91.191.140.11]) by core3.amsl.com (Postfix) with ESMTP id 702263A6B96 for ; Wed, 29 Jul 2009 13:33:41 -0700 (PDT) Received: from linux2.contactor.se (linux2.contactor.se [91.191.140.14]) by kluster1.contactor.se (8.13.8/8.13.8/Debian-3) with ESMTP id n6TKXfHM019168 for ; Wed, 29 Jul 2009 22:33:41 +0200 Date: Wed, 29 Jul 2009 22:36:55 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@linux2.contactor.se To: multipathtcp@ietf.org In-Reply-To: <4A7057FA.6010705@gmail.com> Message-ID: References: <4A7057FA.6010705@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [multipathtcp] BOF where? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 20:34:09 -0000 hey people Where's that BOF going to take place at 9am tomorrow morning? http://www.ietf.org/proceedings/75/agenda/mptcp.txt mentions no location! -- / daniel.haxx.se From christian.vogt@ericsson.com Wed Jul 29 14:00:06 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9183A6BC3; Wed, 29 Jul 2009 14:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoYd5cTUT3y1; Wed, 29 Jul 2009 14:00:05 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 4B1993A6B48; Wed, 29 Jul 2009 14:00:05 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n6TKxvKR032510; Wed, 29 Jul 2009 15:59:57 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 15:58:59 -0500 Received: from [10.16.1.9] ([164.48.124.45]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 15:58:59 -0500 Message-Id: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> From: Christian Vogt To: IETF Discussion Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 22:58:54 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jul 2009 20:58:59.0938 (UTC) FILETIME=[654CCC20:01CA108F] Cc: Multipath TCP Mailing List Subject: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 21:00:06 -0000 Dear all - Since I won't make it to tomorrow's Multipath TCP BOF unfortunately, I would like to express my support for this effort by email. Multipath TCP promises to enable an attractive set of new features -- ranging from automatic fail-over, to load-balancing, to mobility support. Even though there are, of course, important challenges to be surmounted, early analyses indicate the feasibility of the concept as such. And the strong academic background and support from key IETF folks ensures that people with clue and sufficient time will work on it. Therefore, personally, I believe this BOF should be given a thumbs-up for working group establishment. - Christian From scott.brim@gmail.com Wed Jul 29 14:00:08 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10873A6F84 for ; Wed, 29 Jul 2009 14:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJmiUDRCt00V for ; Wed, 29 Jul 2009 14:00:08 -0700 (PDT) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id A47C03A6F80 for ; Wed, 29 Jul 2009 14:00:07 -0700 (PDT) Received: by ewy7 with SMTP id 7so337281ewy.42 for ; Wed, 29 Jul 2009 14:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=avR20XQQ3xYN/ns0lnugqKNBQHGGN5l+0RUCcryhPbk=; b=LgUlS24kqdakqE6TaYpcVaqHnmNBr94cK0hDpnH/ES0IaVHs/o2pSm69akf260yatI zQ0cTWsuAVKny7J08zZ3VT4UPx5UqBiozWZijFC9ydzZWIPYvpsVJiT8vhQzrk7Pe9gT fSh7LyTgpLukrxmMILyruPVBxietISSY53iWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=K9ehh4HZTYEeLxTIKQdBLEROPh3xCEvKtGWqPsecjNzvKYyKivVGIuAy9tkhrUnmKo rmvjTwpjxtSpCokMEV8nQN/cFy6G4YopHp93Xf7BddFOSlrA3/h+B8yXYr2SaYdhXDQ3 /jmAgerusp11BrY71EdTQv8cC3A51NbYDIQ7g= Received: by 10.210.86.1 with SMTP id j1mr320719ebb.61.1248901200860; Wed, 29 Jul 2009 14:00:00 -0700 (PDT) Received: from sbrim-mbp.local ([77.241.97.148]) by mx.google.com with ESMTPS id 5sm488eyf.44.2009.07.29.13.59.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 13:59:59 -0700 (PDT) Message-ID: <4A70B84C.6040803@gmail.com> Date: Wed, 29 Jul 2009 22:59:56 +0200 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Daniel Stenberg References: <4A7057FA.6010705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] BOF where? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 21:00:08 -0000 Daniel Stenberg allegedly wrote on 07/29/2009 22:36 GMT+02:00: > hey people > > Where's that BOF going to take place at 9am tomorrow morning? > > http://www.ietf.org/proceedings/75/agenda/mptcp.txt mentions no location! > https://datatracker.ietf.org/meeting/75/agenda.html -> Congresshall A From Rolf.Winter@nw.neclab.eu Thu Jul 30 01:53:09 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF833A6834 for ; Thu, 30 Jul 2009 01:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD+zcPb53vgY for ; Thu, 30 Jul 2009 01:53:08 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2D6DE3A718A for ; Thu, 30 Jul 2009 01:53:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 8B7802C00C521; Thu, 30 Jul 2009 10:53:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKtlyiSH4WXW; Thu, 30 Jul 2009 10:53:09 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 5F2F92C00C51F; Thu, 30 Jul 2009 10:52:59 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 30 Jul 2009 10:52:52 +0200 Message-ID: <547F018265F92642B577B986577D671CADE585@VENUS.office> In-Reply-To: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] On Thursday's Multipath TCP BOF Thread-Index: AcoQj5YBwK9RWjO3QT+hUmzAENllQQAYw9aQ References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> From: "Rolf Winter" To: "Christian Vogt" Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:53:09 -0000 +1 NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 =20 > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of Christian Vogt > Sent: Mittwoch, 29. Juli 2009 22:59 > To: IETF Discussion Mailing List > Cc: Multipath TCP Mailing List > Subject: [multipathtcp] On Thursday's Multipath TCP BOF >=20 > Dear all - >=20 > Since I won't make it to tomorrow's Multipath TCP BOF unfortunately, I > would like to express my support for this effort by email. >=20 > Multipath TCP promises to enable an attractive set of new features -- > ranging from automatic fail-over, to load-balancing, to mobility > support. Even though there are, of course, important challenges to be > surmounted, early analyses indicate the feasibility of the concept as > such. And the strong academic background and support from key IETF > folks ensures that people with clue and sufficient time will work on = it. >=20 > Therefore, personally, I believe this BOF should be given a thumbs-up > for working group establishment. >=20 > - Christian >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From gurtov@cs.helsinki.fi Thu Jul 30 01:59:30 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C933C3A71B4 for ; Thu, 30 Jul 2009 01:59:30 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4d8WyEPIa48 for ; Thu, 30 Jul 2009 01:59:29 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 43A2B3A7196 for ; Thu, 30 Jul 2009 01:58:36 -0700 (PDT) Received: from [130.129.23.156] (dhcp-179c.meeting.ietf.org [130.129.23.156]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 30 Jul 2009 11:58:36 +0300 id 00063DFB.4A7160BC.00003F8A Message-ID: <4A7160BA.5030606@cs.helsinki.fi> Date: Thu, 30 Jul 2009 11:58:34 +0300 From: Andrei Gurtov User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Multipath TCP Mailing List X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Shepard Subject: [multipathtcp] multipath TCP/HIP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:59:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I agree with Tim Shepard's comment on BOF that it would be nice to see how multipath TCP efforts fit with HIP/shim6 multihoming. Because HIP/shim6 can fix many security and middlebox traversal issues for multipath without a need to modify application API (or even transport layer). In a BROADNETS paper below, we've sketched such architecture as well as did some simulations on this approach in ns2. Your comments and opinions appreciated! http://www.cs.helsinki.fi/u/gurtov/papers/broadnets09.pdf Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpxYLoACgkQP7jp0uceFkSOQQCfb1dwT+wn1URX3pUYCi8jYdL0 6g8AoLPkkgoH/qad3kO9m50K2IBI5QFi =Or26 -----END PGP SIGNATURE----- From fred@cisco.com Thu Jul 30 02:11:25 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F4E28C1F1; Thu, 30 Jul 2009 02:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.098 X-Spam-Level: X-Spam-Status: No, score=-110.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJhhAIMGdq+O; Thu, 30 Jul 2009 02:11:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F38F828C250; Thu, 30 Jul 2009 02:11:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQAAEcAcUqQ/uCKe2dsb2JhbACBUpg6FiQGnkqIJ5AVBYQR X-IronPort-AV: E=Sophos;i="4.43,294,1246838400"; d="scan'208";a="46121329" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2009 09:11:24 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6U9BO9S014371; Thu, 30 Jul 2009 11:11:24 +0200 Received: from dhcp-56c8.meeting.ietf.org (dhcp-10-61-100-240.cisco.com [10.61.100.240]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6U9BOhN022105; Thu, 30 Jul 2009 09:11:24 GMT Message-Id: <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> From: Fred Baker To: Multipath TCP Mailing List In-Reply-To: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 11:11:24 +0200 References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3396; t=1248945084; x=1249809084; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20On=20Thursday's=20Multipath=20TCP=20BOF |Sender:=20; bh=eVUT7qixUAd1X4mMShWjWV/Uw5IxSGyvSS0wKfRByRM=; b=OspD8k+1iI4rBmLSQrGel3UYtTl3aosBscDOl4RJO+suN7A6Du/gTqdwQa PHS1COQ3vP3OSyeZuquICoUA36tTFdDRvoPvFaTdSaCAg9iZP/pBh4EPJTXO x7ozNCTgOb; Authentication-Results: ams-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF Discussion Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 09:11:25 -0000 +1. I likewise will be unable to attend. But I think it is valuable and important. I do question whether perhaps it should be an IRTF effort rather than an IETF effort, but I think there is value in it and would support it being looked into. It seems to me that there are several aspects that need consideration. One is the concept of multiple disparate routes being selected by the end station; in the Internet, the end station doesn't know anything about routing. In this respect, I think there are three important observations that could be made. a) if there were some way to cleanly do so, such as a use of the flow label in some appropriate way TBD as a "route me different" flag, it would be nice to have the end station be able to request that the network deliberately spread the traffic in a stream across multiple routes. In the end system, if it has several appropriate addresses and/ or its peer does, that would include the end station sending data from/ to the cross product of those addresses. In the network proper, routers could randomly distribute traffic across equal-cost-load- shared paths fairly easily, and could look into less salubrious paths in at least some cases. In that last there be dragons, but it deserves looking into. b) The set of paths so chosen will have different RTT and potentially other parameters. The end station will want to be aware of the impacts of these, and somehow prune routes (cross-products, uses of the "route me different" flag, etc) that aren't being helpful. c) rather than even thinking about variations on the fast retransmit heuristic or SACK as currently defined, I think we need some form of explicit request for retransmission. One example of such an algorithm would be for the sender to include not only the send sequence number but cwnd (sender's window estimate, not receiver's buffer size) or SSN- cwnd in its transport header. The implication for the receiver is that if it receives segment SSN and is still waiting for a segment earlier than SSN-cwnd, it should NACK the older segment to trigger its retransmission. Clearly, the sender can probe for such by sending an empty segment that specifies cwnd=0, such as when it is terminating a transmission burst or has been waiting more than an RTT for an ACK and hasn't received it. I'm thinking along DCCP lines, therefore, in the use of the ACK. On Jul 29, 2009, at 10:58 PM, Christian Vogt wrote: > Dear all - > > Since I won't make it to tomorrow's Multipath TCP BOF unfortunately, I > would like to express my support for this effort by email. > > Multipath TCP promises to enable an attractive set of new features -- > ranging from automatic fail-over, to load-balancing, to mobility > support. Even though there are, of course, important challenges to be > surmounted, early analyses indicate the feasibility of the concept as > such. And the strong academic background and support from key IETF > folks ensures that people with clue and sufficient time will work on > it. > > Therefore, personally, I believe this BOF should be given a thumbs-up > for working group establishment. > > - Christian > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From julienl@qualcomm.com Thu Jul 30 04:51:47 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0D928C1FE for ; Thu, 30 Jul 2009 04:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.69 X-Spam-Level: X-Spam-Status: No, score=-103.69 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adH-SNC0mKhG for ; Thu, 30 Jul 2009 04:51:46 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C66F628C17B for ; Thu, 30 Jul 2009 04:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1248954708; x=1280490708; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Andrei=20Gurtov=20,=0D=0A =20=20=20=20=20=20=20=20Multipath=20TCP=20Mailing=20List =0D=0A=09|CC:=20Tim=20Shepard=20|Date:=20Thu,=2030=20Jul=202009=2004:51: 37=20-0700|Subject:=20RE:=20[multipathtcp]=20multipath=20 TCP/HIP|Thread-Topic:=20[multipathtcp]=20multipath=20TCP/ HIP|Thread-Index:=20AcoQ9CLzQUuExEgBTMeQkrYnxtbiIQAF5GcA |Message-ID:=20|References:=20<4A7160BA.50 30606@cs.helsinki.fi>|In-Reply-To:=20<4A7160BA.5030606@cs .helsinki.fi>|Accept-Language:=20en-US|Content-Language: =20en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5692"=3B=20a=3D"21447498"; bh=1LMWONDcc0vlOkAGnfRCECqffl2MfVotFBZeoBEzlJ0=; b=lPbZCu4nHcGUFRWJKJJg6tou96AHVi12Gj245ClQfibMFSe47yxviSqk 1OYxpRDBH9TuH44Qu6PslJBj9sjUg+K/5R7olYAZFwClSzKhxcKi6IOYT aLsPiRQ8wyHVLa0gebKBfzr+KhSDpHBbNaDV7RTXJbhuiJGiV8IqoD6JX Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5692"; a="21447498" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jul 2009 04:51:48 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6UBpmw2001904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Jul 2009 04:51:48 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6UBpeEL021563 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jul 2009 04:51:41 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 30 Jul 2009 04:51:40 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Thu, 30 Jul 2009 04:51:40 -0700 From: "Laganier, Julien" To: Andrei Gurtov , Multipath TCP Mailing List Date: Thu, 30 Jul 2009 04:51:37 -0700 Thread-Topic: [multipathtcp] multipath TCP/HIP Thread-Index: AcoQ9CLzQUuExEgBTMeQkrYnxtbiIQAF5GcA Message-ID: References: <4A7160BA.5030606@cs.helsinki.fi> In-Reply-To: <4A7160BA.5030606@cs.helsinki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tim Shepard Subject: Re: [multipathtcp] multipath TCP/HIP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 11:51:48 -0000 If interactions with SHIM6 & HIP are worth to be considered, I think the sa= me is true for MIPV6 and its multiple care-of address extensions. --julien > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of Andrei Gurtov > Sent: Thursday, July 30, 2009 1:59 AM > To: Multipath TCP Mailing List > Cc: Tim Shepard > Subject: [multipathtcp] multipath TCP/HIP >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi, >=20 > I agree with Tim Shepard's comment on BOF that it would be nice to see > how multipath TCP efforts fit with HIP/shim6 multihoming. Because > HIP/shim6 can fix many security and middlebox traversal issues for > multipath without a need to modify application API (or even transport > layer). In a BROADNETS paper below, we've sketched such architecture as > well as did some simulations on this approach in ns2. Your comments and > opinions appreciated! >=20 > http://www.cs.helsinki.fi/u/gurtov/papers/broadnets09.pdf >=20 > Andrei > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkpxYLoACgkQP7jp0uceFkSOQQCfb1dwT+wn1URX3pUYCi8jYdL0 > 6g8AoLPkkgoH/qad3kO9m50K2IBI5QFi > =3DOr26 > -----END PGP SIGNATURE----- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From Michael.Tuexen@lurchi.franken.de Thu Jul 30 04:54:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E284828C155 for ; Thu, 30 Jul 2009 04:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHPpwssEFZYQ for ; Thu, 30 Jul 2009 04:54:35 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id BDF0C28C236 for ; Thu, 30 Jul 2009 04:54:03 -0700 (PDT) Received: from [IPv6:2001:df8::16:224:36ff:feef:67d1] (unknown [IPv6:2001:df8:0:16:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 730021C0C0BD8 for ; Thu, 30 Jul 2009 13:54:02 +0200 (CEST) Message-Id: <8690449D-48A7-4082-B8B1-5E1AFC41AEB3@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: multipathtcp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 13:54:01 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [multipathtcp] Split of documents / work items X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 11:54:36 -0000 Dear all, I think that separating several issues in different work items and possible documents make a lot of sense. This was pointed out already at the mic. One particular item is the multi path specific congestion control considerations. They also apply to other transport protocols which a multi path capable. Best regards Michael From john@jlc.net Thu Jul 30 05:03:26 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302723A6BB1 for ; Thu, 30 Jul 2009 05:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOgJSYmTBJLy for ; Thu, 30 Jul 2009 05:03:25 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 1DB2D3A69DF for ; Thu, 30 Jul 2009 05:03:25 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4666233C38; Thu, 30 Jul 2009 08:03:21 -0400 (EDT) Date: Thu, 30 Jul 2009 08:03:21 -0400 From: John Leslie To: Michael T?xen Message-ID: <20090730120321.GN9935@verdi> References: <8690449D-48A7-4082-B8B1-5E1AFC41AEB3@lurchi.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8690449D-48A7-4082-B8B1-5E1AFC41AEB3@lurchi.franken.de> User-Agent: Mutt/1.4.1i Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Split of documents / work items X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 12:03:26 -0000 Michael T?xen wrote: > > I think that separating several issues in different work items > and possible documents make a lot of sense... I agree. In particular, I found the existing I-Ds a bit long; and IMHO several folks talking during the BoF didn't seem to have a full grasp of them. > One particular item is the multi path specific congestion control > considerations. They also apply to other transport protocols > which a multi path capable. I would definitely like to see that as a separate draft. (BTW, I envision multipath TCP eventually being as rich an area for experimental congestion-control as plain TCP has proven.) -- John Leslie From iljitsch@muada.com Thu Jul 30 05:03:34 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A753A69DF for ; Thu, 30 Jul 2009 05:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAjEEefTBzoU for ; Thu, 30 Jul 2009 05:03:33 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7443A68A9 for ; Thu, 30 Jul 2009 05:03:33 -0700 (PDT) Received: from dhcp-55f3.meeting.ietf.org (dhcp-55f3.meeting.ietf.org [130.129.85.243] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6UC34o4098150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jul 2009 14:03:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Andrei Gurtov In-Reply-To: <4A7160BA.5030606@cs.helsinki.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 14:03:22 +0200 References: <4A7160BA.5030606@cs.helsinki.fi> X-Mailer: Apple Mail (2.935.3) Cc: Multipath TCP Mailing List , Tim Shepard Subject: Re: [multipathtcp] multipath TCP/HIP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 12:03:34 -0000 On 30 jul 2009, at 10:58, Andrei Gurtov wrote: > I agree with Tim Shepard's comment on BOF that it would be nice to see > how multipath TCP efforts fit with HIP/shim6 multihoming. On some level it would make sense to reuse Shim6 as the mechanism to negotiate additional addresses when MPTCP runs over IPv6. Obviously this isn't so hot for IPv4. However, I don't know if it's possible to make a seamless integration between the two-ended MPTCP in the current draft and a Shim6MPTCP in such a way that it would seamlessly bond IPv4 and IPv6 paths. Iljitsch From gurtov@cs.helsinki.fi Thu Jul 30 06:32:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5352B3A6C57 for ; Thu, 30 Jul 2009 06:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKXitRKtvFo5 for ; Thu, 30 Jul 2009 06:32:58 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 521AD3A6921 for ; Thu, 30 Jul 2009 06:32:58 -0700 (PDT) Received: from [130.129.23.156] (dhcp-179c.meeting.ietf.org [130.129.23.156]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 30 Jul 2009 16:32:58 +0300 id 00063E96.4A71A10A.00004CDF Message-ID: <4A71A108.9010503@cs.helsinki.fi> Date: Thu, 30 Jul 2009 16:32:56 +0300 From: Andrei Gurtov User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <4A7160BA.5030606@cs.helsinki.fi> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Multipath TCP Mailing List , Tim Shepard Subject: Re: [multipathtcp] multipath TCP/HIP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 13:32:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: > On 30 jul 2009, at 10:58, Andrei Gurtov wrote: > >> I agree with Tim Shepard's comment on BOF that it would be nice to see >> how multipath TCP efforts fit with HIP/shim6 multihoming. > > On some level it would make sense to reuse Shim6 as the mechanism to > negotiate additional addresses when MPTCP runs over IPv6. Obviously this > isn't so hot for IPv4. However, I don't know if it's possible to make a > seamless integration between the two-ended MPTCP in the current draft > and a Shim6MPTCP in such a way that it would seamlessly bond IPv4 and > IPv6 paths. For two-ended multipath TCP it makes more sense to use HIP than shim6. Then there is no IPv4/IPv6 issues - in fact you could mix such paths together to receive their aggregate bandwidth. Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpxoQgACgkQP7jp0uceFkQhhwCgtidiFNmdlLgmaroO9tke0zqU 39QAn3WVp2X+50ZRVp6yRNuHvOLqXusg =GXE/ -----END PGP SIGNATURE----- From john@jlc.net Thu Jul 30 07:05:20 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197983A6C71 for ; Thu, 30 Jul 2009 07:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Gm9K+71ey2U for ; Thu, 30 Jul 2009 07:05:19 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id C648B3A71B4 for ; Thu, 30 Jul 2009 07:05:13 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 81F4233C53; Thu, 30 Jul 2009 10:05:10 -0400 (EDT) Date: Thu, 30 Jul 2009 10:05:10 -0400 From: John Leslie To: Andrei Gurtov Message-ID: <20090730140510.GP9935@verdi> References: <4A7160BA.5030606@cs.helsinki.fi> <4A71A108.9010503@cs.helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A71A108.9010503@cs.helsinki.fi> User-Agent: Mutt/1.4.1i Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] multipath TCP/HIP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 14:05:20 -0000 Andrei Gurtov wrote: > > For two-ended multipath TCP it makes more sense to use HIP than shim6. > Then there is no IPv4/IPv6 issues - in fact you could mix such paths > together to receive their aggregate bandwidth. May I suggest you give a brief tutorial on how to do this? (HIP would appear to be a work in progress, and I doubt we'd all make the same guesses where it will end up.) -- John Leslie From brian.e.carpenter@gmail.com Thu Jul 30 15:46:57 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25723A6A30 for ; Thu, 30 Jul 2009 15:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xr9wYtVAgaYG for ; Thu, 30 Jul 2009 15:46:57 -0700 (PDT) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by core3.amsl.com (Postfix) with ESMTP id 0974F3A687E for ; Thu, 30 Jul 2009 15:46:57 -0700 (PDT) Received: by pzk14 with SMTP id 14so702511pzk.29 for ; Thu, 30 Jul 2009 15:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VIOmnMWxvjJ7Qu4fHzvmZBTmhdhEnC811y+WtNjkASI=; b=EitDWZQU/1jwR0cFSERLDa1N8wSs5O39/DkM+w7w6fxAvZZV24vSYNpUetelxpNNhO 6hLiFJntclF9DhGsqklglyCIFzCOL4D9AoT1WzfcOcNbT2HJrGx5WpiHCFuf5p8ZJmjV +PcedQtITXOyhQ183g0gJ2veJG0u3TrT4RHwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=bGXIX1/upW4O+iSAlzTtcg2/6OyeoWb+Svr85iTcNq+8ZxPDlkhwD/wnGgGHGWiuyy 7J6u5eAnQf1BgomZ9NQU4e3erinHtoFJB2DhCkFMUpaF+ks9dhLipIBy2Np33wciMw0P NCGtYq8bvAAs+kJZ4tmfBTpXg1Al7zyG4Vb0Q= Received: by 10.114.76.13 with SMTP id y13mr2381050waa.116.1248994016800; Thu, 30 Jul 2009 15:46:56 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k37sm3848083waf.7.2009.07.30.15.46.55 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 15:46:56 -0700 (PDT) Message-ID: <4A7222DD.20401@gmail.com> Date: Fri, 31 Jul 2009 10:46:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> In-Reply-To: <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 22:46:57 -0000 On 2009-07-30 21:11, Fred Baker wrote: ... > a) if there were some way to cleanly do so, such as a use of the flow > label in some appropriate way TBD as a "route me different" flag, Actually the flow label rules specified in RFC3697 cause a bit of an issue with any form of multipath (including SCTP and SHIM6 as well as multipath TCP). Do we want all threads of the same connection to carry the same flow label even if the source or destination addresses vary? I don't have an easy answer to that, and we ducked it in 3697. Shim6 does say "the in-path devices need to know about the use of the new locators even though the Flow Label stays the same." So it's kind-of assumed that the flow label isn't changed, but a strict interpretation of 3697 would define each {source locator, flow label} 2-uple as a separate flow, even if the flow label is the same. Brian From fred@cisco.com Thu Jul 30 21:30:18 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845733A6AB9 for ; Thu, 30 Jul 2009 21:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.711 X-Spam-Level: X-Spam-Status: No, score=-109.711 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vClPVadF-+SM for ; Thu, 30 Jul 2009 21:30:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 46C8F3A6B37 for ; Thu, 30 Jul 2009 21:30:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgAAGIQckqQ/uCLe2dsb2JhbACaGQEBFiQGnn+IJ5A7BYQXgU4 X-IronPort-AV: E=Sophos;i="4.43,299,1246838400"; d="scan'208";a="46176209" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2009 04:30:18 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6V4UHNc005406; Fri, 31 Jul 2009 06:30:17 +0200 Received: from [10.43.1.21] (ams3-vpn-dhcp8102.cisco.com [10.61.95.165]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6V4UGQ4018662; Fri, 31 Jul 2009 04:30:17 GMT Message-Id: From: Fred Baker To: Brian E Carpenter In-Reply-To: <4A7222DD.20401@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 06:30:14 +0200 References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> <4A7222DD.20401@gmail.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1121; t=1249014617; x=1249878617; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20On=20Thursday's=20Multipath=20TCP=20BOF |Sender:=20; bh=ITVbTKtTuZCEMAvA7P1yk8WxJE8OYcb1HEbjDXnwALc=; b=aFdwRGgWpziQdsgOxd+pHRA8xx/QmN3e7rGBn2n1sXTFHScvsBOxmxk0Lq /QKf9XJZZtU4YfHGqEDtsb5TjLAimEJ0sTIu+pDIYevN4OPXK8vF10nI7wYA 8EQpNmAQ0b; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 04:30:18 -0000 Well, the flow label being something that we have never actually used, maybe we should change the rules to make it something useful... On Jul 31, 2009, at 12:46 AM, Brian E Carpenter wrote: > On 2009-07-30 21:11, Fred Baker wrote: > ... >> a) if there were some way to cleanly do so, such as a use of the flow >> label in some appropriate way TBD as a "route me different" flag, > > Actually the flow label rules specified in RFC3697 cause a bit of > an issue with any form of multipath (including SCTP and SHIM6 as > well as multipath TCP). Do we want all threads of the same connection > to carry the same flow label even if the source or destination > addresses vary? I don't have an easy answer to that, and we ducked > it in 3697. > > Shim6 does say "the in-path devices need to know about the use of > the new locators even though the Flow Label stays the same." So it's > kind-of assumed that the flow label isn't changed, but a strict > interpretation of 3697 would define each {source locator, flow label} > 2-uple as a separate flow, even if the flow label is the same. > > Brian From brian.e.carpenter@gmail.com Thu Jul 30 21:48:13 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EF53A6A2D for ; Thu, 30 Jul 2009 21:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLCKdcmPlxM9 for ; Thu, 30 Jul 2009 21:48:12 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id C23093A69CA for ; Thu, 30 Jul 2009 21:48:12 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id v27so261817wah.5 for ; Thu, 30 Jul 2009 21:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=F9rZLN3mzu8nF4ygLsnp3O6GbPvQe1vGmBOMhmRMM80=; b=g1wUJSxq0qzTnLDzlXiePYZibXMcFdxPEtBfm3OspsHdPr+tmWKlMHzSSL4Z3i77dw IqXfwIGE9uoPsHMttxaUY1Gl5G1ECJDt2qMRfYzupLl4GoXk0LOEZCGf+szSXoLBUP9t 8mCJMf/XNIkvxnPnNhd4VMBAcWB3lGUvgQpkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=w+KudbeNuKKRaK2Yim7PwG4h/TyVT5LX6CiHkRwI2BG1Gd4H8vGiZFtUf5HkV22au2 AW6bxzILr6cVn6FRywXl0vlBp5T7jcfha9H5Ueu3p8W7EdIfBseuPC122j9vH834o1V1 6/iOf4dxlX29TOkTWV++1S59gT7pr2puHvavk= Received: by 10.114.152.19 with SMTP id z19mr2923877wad.83.1249015693269; Thu, 30 Jul 2009 21:48:13 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id n9sm4336837wag.58.2009.07.30.21.48.11 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 21:48:12 -0700 (PDT) Message-ID: <4A727785.4030507@gmail.com> Date: Fri, 31 Jul 2009 16:48:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> <4A7222DD.20401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 04:48:13 -0000 I suspect this one can be fixed by clarifying rather than changing the rules, but I have a 5 year old to-do which is writing something about flow label use cases for the community to discuss. Regards Brian On 2009-07-31 16:30, Fred Baker wrote: > Well, the flow label being something that we have never actually used, > maybe we should change the rules to make it something useful... > > On Jul 31, 2009, at 12:46 AM, Brian E Carpenter wrote: > >> On 2009-07-30 21:11, Fred Baker wrote: >> ... >>> a) if there were some way to cleanly do so, such as a use of the flow >>> label in some appropriate way TBD as a "route me different" flag, >> >> Actually the flow label rules specified in RFC3697 cause a bit of >> an issue with any form of multipath (including SCTP and SHIM6 as >> well as multipath TCP). Do we want all threads of the same connection >> to carry the same flow label even if the source or destination >> addresses vary? I don't have an easy answer to that, and we ducked >> it in 3697. >> >> Shim6 does say "the in-path devices need to know about the use of >> the new locators even though the Flow Label stays the same." So it's >> kind-of assumed that the flow label isn't changed, but a strict >> interpretation of 3697 would define each {source locator, flow label} >> 2-uple as a separate flow, even if the flow label is the same. >> >> Brian > > From lars.eggert@nokia.com Thu Jul 30 23:38:31 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5503E3A6A5A for ; Thu, 30 Jul 2009 23:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7bpbqqCU1BI for ; Thu, 30 Jul 2009 23:38:30 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 450B33A6837 for ; Thu, 30 Jul 2009 23:38:30 -0700 (PDT) Received: from [IPv6:2001:df8::80:225:ff:fe45:eccf] ([IPv6:2001:df8:0:80:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n6V6cDLP054772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2009 09:38:14 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <86C99C25-93E9-4D21-9C2C-27BBB69DDAC0@nokia.com> From: Lars Eggert To: Brian E Carpenter In-Reply-To: <4A7222DD.20401@gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-42-132148732; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 08:38:08 +0200 References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> <4A7222DD.20401@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Fri, 31 Jul 2009 09:38:16 +0300 (EEST) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 06:38:31 -0000 --Apple-Mail-42-132148732 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-7-31, at 0:46, Brian E Carpenter wrote: > Actually the flow label rules specified in RFC3697 cause a bit of > an issue with any form of multipath (including SCTP and SHIM6 as > well as multipath TCP). Do we want all threads of the same connection > to carry the same flow label even if the source or destination > addresses vary? I don't have an easy answer to that, and we ducked > it in 3697. RFC3697 actually says in the introduction: A flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the source desires to label as a flow. A flow could consist of all packets in a specific transport connection or a media stream. However, a flow is not necessarily 1:1 mapped to a transport connection. The first sentence seems to imply that the packets of different subflows may carry different flow labels. The second sentence is the issue. It is true for unipath/uniflow transport protocols, but not multipath transport protocols. The third sentence I don't understand :-) But at least to me, the decision to call this "flow label" instead of "connection label" implies that the intent was for this label to identify a sequence of packet that has topology affinity, rather than application connection affinity. Lars --Apple-Mail-42-132148732 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA3MzEwNjM4MDhaMCMGCSqGSIb3DQEJBDEWBBTk+HYHLe/ofn/A IQJ7eRE9NRJmoTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAlv0djl0kZ/HPmRIhFKJcZmyLBpyvNqr8g/sd1BLIGT7m0N3fK4V2 O9rRVcb1JledZeTKoNb05XjXezIP7CCh5L3/i6uDb5wPd5oTl0gRPiu9dRo9YdhADs45GA7YbnYS t1hhiBLOmgyD3hZ7SIplDOFI1IuiZT7dv5FzsJgrZjtX6C5+yojEpTtKMnsCfGyerx8WoK83o9cQ guglx/uEGQj7P4ugTMnsARVi7q5Pml7ewQ5KEtqbw9JLakB8KwZsPyWG1dtGzjQBNyI5UeInSNaD s96hm9TrOxEknOVxKVxptkPs9RoxCV3tON3yFoeV0nnvTuBxIqj1WKUltbLmdQAAAAAAAA== --Apple-Mail-42-132148732-- From Dimitri.Papadimitriou@alcatel-lucent.be Fri Jul 31 00:45:19 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477953A6B9A; Fri, 31 Jul 2009 00:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZQa3kR7NNKM; Fri, 31 Jul 2009 00:45:18 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 115B13A693A; Fri, 31 Jul 2009 00:45:17 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6V7jHfG007919; Fri, 31 Jul 2009 09:45:17 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 09:45:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 09:45:15 +0200 Message-ID: <00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On Thursday's Multipath TCP BOF Thread-Index: AcoQ73/aWPVFZZ7zQ5aXkJioZBZKQAApbFTw References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> From: "PAPADIMITRIOU Dimitri" To: "Christian Vogt" , "Multipath TCP Mailing List" X-OriginalArrivalTime: 31 Jul 2009 07:45:17.0399 (UTC) FILETIME=[D8E18670:01CA11B2] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: IETF Discussion Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 07:45:19 -0000 I see value in working on a "linked" congestion control scheme (work consisting in architecting and determining how efficient such scheme would be compared to current practice/congestion control schemes).=20 I have a couple of comments/concerns though: - The BoF presentation considers that the TCP end-points controls routing of the traffic along a certain path in the network but routing information does not reach the end-points. So for what it concerns routing of the traffic, per TCP connection, there is no difference compared to the current situation (the network is not aware that two connections entering the network belong to the same "set"). This assumption is to be revisited because the "possible" paths towards (set of destinations) will be as provided by the routing system and means for triggering and enforcing diversity inside network is not achievable without additional mechanism (at the "networking layer" level). Note: The term "path" is from this perspective a bit confusing i.e. inverse multiplexed TCP or multi component TCP would probably better suite. - The BoF presentation considers that controlling onto which (sub-)connection the source puts traffic leads to offload the network from performing traffic engineering. Thus, I do not see how this would lead to a situation where the network would be free from any traffic engineering ? (I would even say the contrary, this would lead us back to the hyper-aggregation problem). - On the proposed scheme itself, if the end-points assumes that sub-connections (say between IP Address 1 and 2) can not be re-established after detecting their failures, the degraded state would remain permanent since the connection between Address 1 and 2 would not be re-established. So, it may be that some of the decisions taken by the end-points become detrimental. At this stage, it is not clear how to prevent such situation would happen. Note: also that some of the RTT numbers provided in the presentations are within recovery times achievable using fast re-routing schemes.=20 Thanks, -dimitri. > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20 > Behalf Of Christian Vogt > Sent: Wednesday, July 29, 2009 10:59 PM > To: IETF Discussion Mailing List > Cc: Multipath TCP Mailing List > Subject: On Thursday's Multipath TCP BOF >=20 > Dear all - >=20 > Since I won't make it to tomorrow's Multipath TCP BOF unfortunately, I > would like to express my support for this effort by email. >=20 > Multipath TCP promises to enable an attractive set of new features -- > ranging from automatic fail-over, to load-balancing, to mobility > support. Even though there are, of course, important challenges to be > surmounted, early analyses indicate the feasibility of the concept as > such. And the strong academic background and support from key IETF > folks ensures that people with clue and sufficient time will=20 > work on it. >=20 > Therefore, personally, I believe this BOF should be given a thumbs-up > for working group establishment. >=20 > - Christian >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From iljitsch@muada.com Fri Jul 31 00:50:29 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00FD43A6C81 for ; Fri, 31 Jul 2009 00:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+vJPvoxm9dT for ; Fri, 31 Jul 2009 00:50:28 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D96083A6C27 for ; Fri, 31 Jul 2009 00:50:27 -0700 (PDT) Received: from dhcp-55f3.meeting.ietf.org (dhcp-55f3.meeting.ietf.org [130.129.85.243] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6V7njTf005891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Jul 2009 09:49:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Brian E Carpenter In-Reply-To: <4A7222DD.20401@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 09:50:04 +0200 References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> <4A7222DD.20401@gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: Multipath TCP Mailing List , Bob Briscoe Subject: [multipathtcp] Flow label, was: Re: On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 07:50:29 -0000 On 31 jul 2009, at 0:46, Brian E Carpenter wrote: >> a) if there were some way to cleanly do so, such as a use of the flow >> label in some appropriate way TBD as a "route me different" flag, > Do we want all threads of the same connection > to carry the same flow label even if the source or destination > addresses vary? I think Fred is talking about the case where the source and destination addresses actually stay the same. This is an important intended future development of the one-ended multipath TCP solution. For instance, imagine the situation where routers do equal cost multipath (RFC 2992) load sharing across a bundle of links (or paths). In IPv4, the best way to do this is using a bunch of hash buckets with a hash over source/dest addresses and port numbers and the protocol number. With IPv6, this could be source/ dest/flow label. Unlike the IPv4 case, then it would be possible to influence the hash and therefore path selector without making changes that are imcompatible with existing receivers by using a different flow label for certain packets. We've been looking for other bits that could be used for this in the IP header but they're hard to find... On a mostly unrelated note, in Bob Briscoe's re-ECN session yesterday I suggested that he take the third ECN bit that he needs from the flow label if re-ECN takes off, as it would be a shame to require a 8-byte extension header for this while the flow label remains unused in practice (and could easily work with 16 bits or so). From iljitsch@muada.com Fri Jul 31 01:00:47 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0833A6B3A for ; Fri, 31 Jul 2009 01:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTKR8DkwdBhG for ; Fri, 31 Jul 2009 01:00:46 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 2591028C2C2 for ; Fri, 31 Jul 2009 01:00:45 -0700 (PDT) Received: from dhcp-55f3.meeting.ietf.org (dhcp-55f3.meeting.ietf.org [130.129.85.243] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6V80Rio006017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 31 Jul 2009 10:00:28 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Multipath TCP Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 10:00:46 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [multipathtcp] Multipath UDP? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:00:47 -0000 Hi, Someone at the mic in RRG just asked about multipath UDP... Iljitsch From touch@ISI.EDU Fri Jul 31 01:11:01 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA1C3A691A for ; Fri, 31 Jul 2009 01:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQuc0axYrZbX for ; Fri, 31 Jul 2009 01:11:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D86603A6A6C for ; Fri, 31 Jul 2009 01:11:00 -0700 (PDT) Received: from [130.129.22.106] (dhcp-166a.meeting.ietf.org [130.129.22.106]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6V8AaGh004704; Fri, 31 Jul 2009 01:10:38 -0700 (PDT) Message-ID: <4A72A6FC.9010008@isi.edu> Date: Fri, 31 Jul 2009 01:10:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] Multipath UDP? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:11:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: > Hi, > > Someone at the mic in RRG just asked about multipath UDP... Why? UDP is a single packet protocol with no state. There's no relationship between two UDP packets - regardless of same/different port or addresses. So unless you're doing some sort of quantum double-slit experiment, a single path can't go over multiple paths, so multipath doesn't make any sense for UDP IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpypvwACgkQE5f5cImnZrv8IQCgoPeLKTJRrkiqRuzkQkV/+N4J 6r0AoPoh6Mwf/3AMTxlTbc0IdLXGOlGD =H5Eq -----END PGP SIGNATURE----- From scott.brim@gmail.com Fri Jul 31 01:20:53 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9402428C254 for ; Fri, 31 Jul 2009 01:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9UMXKL4KRYf for ; Fri, 31 Jul 2009 01:20:52 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id A34C23A6F19 for ; Fri, 31 Jul 2009 01:20:52 -0700 (PDT) Received: by fxm17 with SMTP id 17so1228811fxm.37 for ; Fri, 31 Jul 2009 01:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=AjLgAhJpAWHEtWyqNIRlvjgGd8nzuqfDkxP3vAwOrnM=; b=sny5K42FZcxB0Fo02SkKg3hPXPgXFJxr+ieLytGKm06cy94fUh/ngp1hyEW+MZBrcy GRGE8sPzu/XC0X8oSVKEl7MvUcDI4tyWdoy/nZnLWwd20UYgMYXF+z635zEaYs/2M93p dZolxEOj/YBwQkN8cFg+p4Xc6qJX0L3xbO22Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=RiGR4LpMlAGt72X+TgjxyECtS28221A7lhTsj7349JHz052lB4KB2tDCe5spHaz1Ps yU+u9y24FL5MLsWGnaWIIirjt1Gr3ZYGS2Z8cyemXI+NMnEiyxjI11tY+tUnA9YMr1rk AX2bmqAIs2Q084ajpYJhgFMCtZibWgWOWGZJE= Received: by 10.103.6.18 with SMTP id j18mr1293937mui.117.1249028451652; Fri, 31 Jul 2009 01:20:51 -0700 (PDT) Received: from dhcp-55fa.meeting.ietf.org ([130.129.85.250]) by mx.google.com with ESMTPS id y2sm19185293mug.12.2009.07.31.01.20.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 01:20:50 -0700 (PDT) Message-ID: <4A72A960.6020707@gmail.com> Date: Fri, 31 Jul 2009 10:20:48 +0200 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Joe Touch References: <4A72A6FC.9010008@isi.edu> In-Reply-To: <4A72A6FC.9010008@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] Multipath UDP? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:20:53 -0000 Joe Touch allegedly wrote on 07/31/2009 10:10 GMT+02:00: >> Someone at the mic in RRG just asked about multipath UDP... > > Why? > > UDP is a single packet protocol with no state. There's no relationship > between two UDP packets - regardless of same/different port or addresses. There are long-lasting flows based on UDP, but the state synchronization is done at a higher layer than transport. Multipath transport is only meaningful if the transport layer is handling state synchronization -- if the multipathing is done in a higher layer, it's out of scope for this WG ... which isn't to say that it's not useful. From aongenae@gmail.com Fri Jul 31 01:23:18 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1033A6F19 for ; Fri, 31 Jul 2009 01:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoIaYFPn8otP for ; Fri, 31 Jul 2009 01:23:12 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id AEFC93A6B3A for ; Fri, 31 Jul 2009 01:23:11 -0700 (PDT) Received: by ewy10 with SMTP id 10so1336628ewy.37 for ; Fri, 31 Jul 2009 01:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer; bh=zuWuqJiQSnkfGrxaQhHoVX7V+vAwxJZmT0G77v0N+EM=; b=pKee8/cADLGQIIZY3CDTlKXZnd+HAWgDbldGV4+qGADCbYdzCTpvRIb0m+bGaVn/sR MLZTUZAHD/Tzy80q1bqSLBMxzKytbtIA24ooWXho7ZRE3vqQP+EKAVFVva5LOBRGcCEk doUii67gAIXgd6UrLyF0ii3W51/e68VPi1cTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; b=ScWDQtBJxvuPD2U8lpiVZ+uCDLvpvmCNxdK20o+CGEpxpJ1TJGncyVL8UK8Q5aNCdP FsEE1TdFVntr8Nfdchj2fUdCNsSieRF4rSjhJzar8248Rr8ZcmObyl4wsXyg7efwMZu9 gUYbuh7WSLXl9gyZYcdpJTa757JhUCxiKMuB8= Received: by 10.210.53.1 with SMTP id b1mr486117eba.62.1249028589794; Fri, 31 Jul 2009 01:23:09 -0700 (PDT) Received: from ?192.168.0.107? (host-85-201-157-84.brutele.be [85.201.157.84]) by mx.google.com with ESMTPS id 5sm2407948eyf.28.2009.07.31.01.23.08 (version=SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 01:23:08 -0700 (PDT) From: Arnaud Ongenae To: Joe Touch In-Reply-To: <4A72A6FC.9010008@isi.edu> References: <4A72A6FC.9010008@isi.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-uSbeyYBVXuerPE9XBF+W" Date: Fri, 31 Jul 2009 10:23:05 +0200 Message-Id: <1249028585.5359.28.camel@nhuynhth-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] Multipath UDP? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:23:18 -0000 --=-uSbeyYBVXuerPE9XBF+W Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-07-31 at 01:10 -0700, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 > Iljitsch van Beijnum wrote: > > Hi, > >=20 > > Someone at the mic in RRG just asked about multipath UDP... >=20 > Why? >=20 > UDP is a single packet protocol with no state. There's no relationship > between two UDP packets - regardless of same/different port or addresses. While only looking at the transport level, you're right, there is no relation between packets. But at the application level, two UDP packets that take different path could produce injury to the application. This reference try to improve UDP in a multi-path context: M. Yabandeh, S. Zarifzadeh, and N. Yazdani.=20 Improving performance of transport protocols in multipath transferring schemes.=20 Elsevier B. V., doi:10.1016/j.comcom.2007.02.017, 2007. >=20 > So unless you're doing some sort of quantum double-slit experiment, a > single path can't go over multiple paths, so multipath doesn't make any > sense for UDP IMO. >=20 > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkpypvwACgkQE5f5cImnZrv8IQCgoPeLKTJRrkiqRuzkQkV/+N4J > 6r0AoPoh6Mwf/3AMTxlTbc0IdLXGOlGD > =3DH5Eq > -----END PGP SIGNATURE----- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --=-uSbeyYBVXuerPE9XBF+W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpyqeIACgkQHpJ+LMVPWRK9RQCfVBuVUkI7b5ZqHSUcNMj4w3Kl /bsAoJm5WeyAIva2VRmzrQ//ykTb4DYM =dARL -----END PGP SIGNATURE----- --=-uSbeyYBVXuerPE9XBF+W-- From touch@ISI.EDU Fri Jul 31 01:26:00 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7010228C312 for ; Fri, 31 Jul 2009 01:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLxMT+MupO+9 for ; Fri, 31 Jul 2009 01:25:59 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7BFFF28C323 for ; Fri, 31 Jul 2009 01:24:11 -0700 (PDT) Received: from [130.129.22.106] (dhcp-166a.meeting.ietf.org [130.129.22.106]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6V8Nsa7007584; Fri, 31 Jul 2009 01:23:57 -0700 (PDT) Message-ID: <4A72AA17.8070807@isi.edu> Date: Fri, 31 Jul 2009 01:23:51 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Scott Brim References: <4A72A6FC.9010008@isi.edu> <4A72A960.6020707@gmail.com> In-Reply-To: <4A72A960.6020707@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] Multipath UDP? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:26:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Brim wrote: > Joe Touch allegedly wrote on 07/31/2009 10:10 GMT+02:00: >>> Someone at the mic in RRG just asked about multipath UDP... >> >> Why? >> >> UDP is a single packet protocol with no state. There's no relationship >> between two UDP packets - regardless of same/different port or addresses. > > There are long-lasting flows based on UDP, but the state synchronization > is done at a higher layer than transport. Multipath transport is only > meaningful if the transport layer is handling state synchronization -- > if the multipathing is done in a higher layer, it's out of scope for > this WG ... which isn't to say that it's not useful. I agree - multipath protocols *above* UDP may be useful, but there is (AFAICT) no such thing as multipath UDP. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpyqhcACgkQE5f5cImnZrstXwCg0MXha6m0Wd0pUaFt9wTNTD4+ 6sYAn2T2RGwQ846TOnvTklsMYQuFiKWl =VGuU -----END PGP SIGNATURE----- From john@jlc.net Fri Jul 31 01:49:36 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86B03A6805 for ; Fri, 31 Jul 2009 01:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI8gvVGK2No0 for ; Fri, 31 Jul 2009 01:49:35 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id D5DFC3A6A02 for ; Fri, 31 Jul 2009 01:49:26 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 797E533C32; Fri, 31 Jul 2009 04:49:15 -0400 (EDT) Date: Fri, 31 Jul 2009 04:49:15 -0400 From: John Leslie To: PAPADIMITRIOU Dimitri Message-ID: <20090731084915.GV9935@verdi> References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> User-Agent: Mutt/1.4.1i Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:49:36 -0000 PAPADIMITRIOU Dimitri wrote: > > I see value in working on a "linked" congestion control scheme (work > consisting in architecting and determining how efficient such scheme > would be compared to current practice/congestion control schemes). Linked Congestion Control is fairly central to the Multipath TCP idea -- but is not intended as a research topic here. Rather, it is a way to avoid worrying about overlap of paths (some of which are "obvious" overlaps which implementors will probably find anyway). By linking the congestion control, we avoid the need to hunt down sets of IP addresses which are "the same" in terms of forwarding path. > I have a couple of comments/concerns though: > > - The BoF presentation considers that the TCP end-points controls > routing of the traffic along a certain path in the network but routing > information does not reach the end-points. I'm not sure I understand. Clearly, the destination IP address "controls" the path the packet will take, and clearly the actual path taken isn't reported (except for "record route" option, which usually doesn't work anyway) to the destination host. But you seem to be saying something beyond that... > So for what it concerns routing of the traffic, per TCP connection, > there is no difference compared to the current situation (the network > is not aware that two connections entering the network belong to the > same "set"). Agreed. "The network" is expected simply to forward packets. > This assumption is to be revisited because the "possible" paths towards > (set of destinations) will be as provided by the routing system and > means for triggering and enforcing diversity inside network is not > achievable without additional mechanism (at the "networking layer" > level). We specifically avoid any expectation that the network should enforce diversity. We expect the network to make "best effort" forwarding decisions: no more, no less. > Note: The term "path" is from this perspective a bit confusing i.e. > inverse multiplexed TCP or multi component TCP would probably better > suite. I think we're stuck with the name. May I suggest we think of it as "TCP that can run over multiple simultaneous paths" rather than "TCP that guarantees the redundancy of multiple paths". > - The BoF presentation considers that controlling onto which > (sub-)connection the source puts traffic leads to offload the network > from performing traffic engineering. I disagree. Network operators will still need to do their own traffic engineering. Multipath TCP is intended to give end-users some traffic-engineering ability separate from that of network operators. We claim that this can reduce the amount of network traffic-engineering needed, but if that claim proves false, nothing really changes. > Thus, I do not see how this would lead to a situation where the network > would be free from any traffic engineering ? I don't believe we've claimed any such thing. > (I would even say the contrary, this would lead us back to the > hyper-aggregation problem). I don't believe we've said much about that. There's a perhaps unstated assumption that network operators may impose artificial delay or packet loss in order to influence Multipath-TCP allocation between paths; and we clearly believe that such "traffic-engineering" would be less harmful than some things they're doing today. > - On the proposed scheme itself, if the end-points assumes that > sub-connections (say between IP Address 1 and 2) can not be > re-established after detecting their failures, the degraded state would > remain permanent since the connection between Address 1 and 2 would not > be re-established. Point well taken. However, it is not clear to me that we ever "detect failure" rather than treating what the routing system considers to be "failure" as, instead, "especially heavy congestion". The difference is, when we detect "especially heavy congestion" we can leave the sub-connection up until its routing problem is resolved (even if that takes several days). > So, it may be that some of the decisions taken by the end-points become > detrimental. At this stage, it is not clear how to prevent such > situation would happen. This does imply that we might need to consider different timeouts for tearing down sub-connections than for non-multipath TCP connections. And that has not been discussed yet; but IMHO it could be left as an implementation detail... -- John Leslie From iljitsch@muada.com Fri Jul 31 01:58:15 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52823A6805 for ; Fri, 31 Jul 2009 01:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPfkacGLZu1E for ; Fri, 31 Jul 2009 01:58:15 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D3CAE3A698A for ; Fri, 31 Jul 2009 01:58:14 -0700 (PDT) Received: from dhcp-55f3.meeting.ietf.org (dhcp-55f3.meeting.ietf.org [130.129.85.243] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6V8vt0O006512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Jul 2009 10:57:56 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <98FF5E69-6491-4D56-B0E7-EE26EC266139@muada.com> From: Iljitsch van Beijnum To: John Leslie In-Reply-To: <20090731084915.GV9935@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 10:58:14 +0200 References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> <20090731084915.GV9935@verdi> X-Mailer: Apple Mail (2.935.3) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:58:15 -0000 On 31 jul 2009, at 10:49, John Leslie wrote: > it is not clear to me that we ever "detect > failure" rather than treating what the routing system considers to be > "failure" as, instead, "especially heavy congestion". > The difference is, when we detect "especially heavy congestion" we > can leave the sub-connection up until its routing problem is resolved > (even if that takes several days). After the BoF, Joe Touch made the point that some (unspecified) applications use TCP to evaluate whether some remote endpoint is reachable, and this is a feature we must retain. So if the initially chosen address pair stops working, the entire session must be torn down, even if there are still other working paths. (BGP does this for eBGP but I can't see how anyone could reasonably want to run eBGP over multipath TCP.) I'm not sure though how those application could have reasonably made this assumption. And if they couldn't, we shouldn't need to perpetuate this limitation. (Of course an API to opt out of MPTCP would be fine.) From lars.eggert@nokia.com Fri Jul 31 02:05:16 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6F33A69DE for ; Fri, 31 Jul 2009 02:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrlYRAes6fUc for ; Fri, 31 Jul 2009 02:05:15 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 9113A3A68B4 for ; Fri, 31 Jul 2009 02:05:15 -0700 (PDT) Received: from dhcp-1558.meeting.ietf.org (dhcp-1558.meeting.ietf.org [130.129.21.88]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n6V956nW057181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2009 12:05:08 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <799F8C28-38AF-4042-9546-F6DDADE18BC7@nokia.com> From: Lars Eggert To: Iljitsch van Beijnum In-Reply-To: <98FF5E69-6491-4D56-B0E7-EE26EC266139@muada.com> Content-Type: multipart/signed; boundary=Apple-Mail-48-140967218; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 11:05:06 +0200 References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> <20090731084915.GV9935@verdi> <98FF5E69-6491-4D56-B0E7-EE26EC266139@muada.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [212.213.221.39]); Fri, 31 Jul 2009 12:05:08 +0300 (EEST) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:05:16 -0000 --Apple-Mail-48-140967218 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-7-31, at 10:58, Iljitsch van Beijnum wrote: > After the BoF, Joe Touch made the point that some (unspecified) > applications use TCP to evaluate whether some remote endpoint is > reachable, and this is a feature we must retain. So if the initially > chosen address pair stops working, the entire session must be torn > down, even if there are still other working paths. this would severely impact the usefulness of the protocol though, because it destroys much of the support for nomadic connectivity that we'd get with MPTCP. You know more about SHIM6 than I do, but I dimly remember that SHIM6 keeps exposing the initial address pair to higher layers even when they change. If this is so, we could make the argument that the cat is out of the bag, i.e., that if someone ran such an app over TCP over SHIM6, it would similarly break, and we have IETF consensus that that's apparently OK. > (BGP does this for eBGP but I can't see how anyone could reasonably > want to run eBGP over multipath TCP.) Agreed. And I don't know of any other app. > I'm not sure though how those application could have reasonably made > this assumption. And if they couldn't, we shouldn't need to perpetuate > this limitation. (Of course an API to opt out of MPTCP would be fine.) Also agreed. Lars --Apple-Mail-48-140967218 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA3MzEwOTA1MDdaMCMGCSqGSIb3DQEJBDEWBBQuuHzRnHljSRmi /2uWieLy5MwVxTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAFTrLNAYE6EKs0FBVe2oB+tvfhDcCH/d9HvVN8YNExSBVvWHWjzet u00h5oxDXzPU1scwkXhu+wEAIh71kHVCYsL7rF0iURmQqeaQR4O8asTlJ1M7NFNZO9W3M6YeGzU2 XENl2lDFqPrOa8dQkC6iCPp6S4EbBEXSs6HB//CKydM5zoNqUOZfBNHw1UqTKc+iiFRVvBYhqOL5 dT2RhygLQeHHKmlIXRwzr19mDUDhiskVegIeRY2JZEZkBWcl6wG9zMSOf0aL5HfAk2ZeQsWkxoSq k1DEScImJUGkTxklit05jHUR3bqAEChWuKaVUHitVvO2+/9yPIQzAXb8kINyaQAAAAAAAA== --Apple-Mail-48-140967218-- From daniel@haxx.se Fri Jul 31 02:15:15 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB033A6911 for ; Fri, 31 Jul 2009 02:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C62oIY0YERPP for ; Fri, 31 Jul 2009 02:15:14 -0700 (PDT) Received: from kluster1.contactor.se (kluster1.contactor.se [91.191.140.11]) by core3.amsl.com (Postfix) with ESMTP id 717923A68B4 for ; Fri, 31 Jul 2009 02:15:14 -0700 (PDT) Received: from linux2.contactor.se (linux2.contactor.se [91.191.140.14]) by kluster1.contactor.se (8.13.8/8.13.8/Debian-3) with ESMTP id n6V9FF3R023752 for ; Fri, 31 Jul 2009 11:15:15 +0200 Date: Fri, 31 Jul 2009 11:18:31 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@linux2.contactor.se To: Multipath TCP Mailing List Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:15:15 -0000 (gah, sorry, I sent this response using the wrong From: so I'm reposting to the list-only now) On Fri, 31 Jul 2009, Iljitsch van Beijnum wrote: > After the BoF, Joe Touch made the point that some (unspecified) applications > use TCP to evaluate whether some remote endpoint is reachable, and this is a > feature we must retain. So if the initially chosen address pair stops > working, the entire session must be torn down, even if there are still other > working paths. But how would these apps know what flow that is alive or not if the API is the exact same? A bazillion apps do their own keep-alive over TCP, but that will work fine as long as there's just at least one living "path". -- / daniel.haxx.se From touch@ISI.EDU Fri Jul 31 02:16:19 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24EC13A6805 for ; Fri, 31 Jul 2009 02:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT52ozteDyhP for ; Fri, 31 Jul 2009 02:16:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 05A493A6DCF for ; Fri, 31 Jul 2009 02:16:18 -0700 (PDT) Received: from [130.129.22.106] (dhcp-166a.meeting.ietf.org [130.129.22.106]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6V9G2JQ018978; Fri, 31 Jul 2009 02:16:07 -0700 (PDT) Message-ID: <4A72B653.2070505@isi.edu> Date: Fri, 31 Jul 2009 02:16:03 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> <20090731084915.GV9935@verdi> <98FF5E69-6491-4D56-B0E7-EE26EC266139@muada.com> In-Reply-To: <98FF5E69-6491-4D56-B0E7-EE26EC266139@muada.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:16:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: > On 31 jul 2009, at 10:49, John Leslie wrote: > >> it is not clear to me that we ever "detect >> failure" rather than treating what the routing system considers to be >> "failure" as, instead, "especially heavy congestion". > >> The difference is, when we detect "especially heavy congestion" we >> can leave the sub-connection up until its routing problem is resolved >> (even if that takes several days). > > After the BoF, Joe Touch made the point that some (unspecified) > applications use TCP to evaluate whether some remote endpoint is > reachable, and this is a feature we must retain. So if the initially > chosen address pair stops working, the entire session must be torn down, > even if there are still other working paths. > > (BGP does this for eBGP but I can't see how anyone could reasonably want > to run eBGP over multipath TCP.) There are separate issues: - whether an app wants to use one of the (at least 4) variants of what mulltipath TCP means - whether an app even knows this is happening (e.g., if an OS sets a flag to "try to use multipath TCP for legacy apps") IMO, if an app decides to use multipath explicitly, it might as well have used SCTP. If it needs to go through a NAT, do something like SCTP over UDP ;-) I.e., NAT traversal for legacy apps is not a great reason to muck around with TCP semantics. > I'm not sure though how those application could have reasonably made > this assumption. We discussed this. IMO, RFC 793 establishes that TCP is a service: A. *of* a reliable, in-order byte-stream++ (where ++ includes congestion response, etc., as added later) B. *between* the endpoints of the connection's socket pair (again, where socket pair is addr/port pair from 793, not a unix-ism) this is part of the defined API of TCP AFAICT, (B) is as much a part of TCP as is (A). Now, whether an app should assume that having a stable TCP connection should be a prerequisite to anything is a good question; I don't think it ought to be a prerequisite to dynamic interdomain routing (eBGP), but that ship has sailed. My concern is that there are (and could/should be) applications that expect a TCP connection to go down when the local IP address is down. TCP is a service for a bytestream between an IP address/port pair, it is not defined as binding to something else that happens to map to an IP/address port pair right now. The implications if this would be: - assume multipath TCP opens connections using a primary (initial) socket pair - as long as that socketpair is available*, the connection stays up; when not, the connection is torn down * = where "available" could mean just that both sides still think that the IP address is bound to one of their interfaces. I.e., you REALLY do not want the following case: A: adr 11, adr 12 B: adr 23, adr 24 A adr 11 port 52394 connects to B adr 23 port 80 A and B open a second TCP connection to use in the multipath set, e.g., from A 12 -> B 24 A ifconfig's adr 11 down C ifconfig's adr 11 up Now what? IMO, if A-B would have lost its connection if a single TCP, then it should have done so over multipath TCP. Note that this does allow A/11 to have a heartbeat to B/23, OR to just ensure that both sides shut the connection when they receive a RST on the original connection. > And if they couldn't, we shouldn't need to perpetuate > this limitation. (Of course an API to opt out of MPTCP would be fine.) Opt-in is the only viable solution if the semantics are changed. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpytlIACgkQE5f5cImnZruJdACg/KiEM4P0Ns6eVaYT0jk5cU2s V+AAn3V1SrBRKOVvKtHau18+on14Wjgl =Scrk -----END PGP SIGNATURE----- From iljitsch@muada.com Fri Jul 31 02:22:44 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B773A6DD7 for ; Fri, 31 Jul 2009 02:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yGwNZ2z5TQO for ; Fri, 31 Jul 2009 02:22:43 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 60B8C3A69DE for ; Fri, 31 Jul 2009 02:22:43 -0700 (PDT) Received: from dhcp-55f3.meeting.ietf.org (dhcp-55f3.meeting.ietf.org [130.129.85.243] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6V9MO1J006736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Jul 2009 11:22:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <211C6038-71F9-4ED8-A8E0-DB153EE792FC@muada.com> From: Iljitsch van Beijnum To: Daniel Stenberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 11:22:42 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:22:44 -0000 On 31 jul 2009, at 11:18, Daniel Stenberg wrote: > But how would these apps know what flow that is alive or not if the > API is the exact same? A bazillion apps do their own keep-alive over > TCP, but that will work fine as long as there's just at least one > living "path". Consider BGP: you have internal and external BGP (iBGP and eBGP). Both care about whether the other end of the TCP session is still up so they send keepalives to check on this. The difference is that iBGP runs across multiple hops, and if something in the middle goes down, iBGP is perfectly happy to ignore that if the session is rerouted over something else so it remains alive. eBGP is made to run directly between two neighboring routers. If the link between those routers goes down, eBGP wants to know about that. It doesn't want the session to be rerouted. So the iBGP-type applications that use keepalives would be happy with the increased redundancy in multipath TCP, but it would pretty much break the eBGP-type applications. So how many of these eBGP-type applications are there? The solution would be for the eBGP-type applications to opt out of the MPTCP, but obviously they don't do that today so there is a migration issue. During that migration these applications would be unhappy unless we make the "fail often, fail fast" behavior the default, negating one of the benefits of MPTCP. From daniel@haxx.se Fri Jul 31 02:34:47 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2F53A6D31 for ; Fri, 31 Jul 2009 02:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFDu9HvKeQfQ for ; Fri, 31 Jul 2009 02:34:46 -0700 (PDT) Received: from kluster1.contactor.se (kluster1.contactor.se [91.191.140.11]) by core3.amsl.com (Postfix) with ESMTP id 85EDE3A69D7 for ; Fri, 31 Jul 2009 02:34:46 -0700 (PDT) Received: from linux2.contactor.se (linux2.contactor.se [91.191.140.14]) by kluster1.contactor.se (8.13.8/8.13.8/Debian-3) with ESMTP id n6V9Ylkm026952; Fri, 31 Jul 2009 11:34:47 +0200 Date: Fri, 31 Jul 2009 11:38:03 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@linux2.contactor.se To: Iljitsch van Beijnum In-Reply-To: <211C6038-71F9-4ED8-A8E0-DB153EE792FC@muada.com> Message-ID: References: <211C6038-71F9-4ED8-A8E0-DB153EE792FC@muada.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:34:47 -0000 On Fri, 31 Jul 2009, Iljitsch van Beijnum wrote: > eBGP is made to run directly between two neighboring routers. If the link > between those routers goes down, eBGP wants to know about that. It doesn't > want the session to be rerouted. Thanks for this fine description. Yes indeed if you use TCP to verify the functionality of a specific link (or even a specific network interface), mptcp in its current proposal may break that... -- / daniel.haxx.se From lars.eggert@nokia.com Fri Jul 31 02:40:58 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECC63A6C18 for ; Fri, 31 Jul 2009 02:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpjiKluvkDcK for ; Fri, 31 Jul 2009 02:40:53 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 7AF553A69F5 for ; Fri, 31 Jul 2009 02:40:52 -0700 (PDT) Received: from dhcp-1558.meeting.ietf.org (dhcp-1558.meeting.ietf.org [130.129.21.88]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n6V9ej60057691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2009 12:40:46 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <3A4F3A9F-91CD-493F-8F94-49EDA60679DB@nokia.com> From: Lars Eggert To: Joe Touch In-Reply-To: <4A72B653.2070505@isi.edu> Content-Type: multipart/signed; boundary=Apple-Mail-49-143106085; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 11:40:45 +0200 References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> <20090731084915.GV9935@verdi> <98FF5E69-6491-4D56-B0E7-EE26EC266139@muada.com> <4A72B653.2070505@isi.edu> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [212.213.221.39]); Fri, 31 Jul 2009 12:40:46 +0300 (EEST) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:40:58 -0000 --Apple-Mail-49-143106085 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-7-31, at 11:16, Joe Touch wrote: > IMO, if an app decides to use multipath explicitly, it might as well > have used SCTP. If it needs to go through a NAT, do something like > SCTP > over UDP ;-) I.e., NAT traversal for legacy apps is not a great reason > to muck around with TCP semantics. it's not quite as simple as that (you also need the CMT extension, plus you need to add something like the coupled congestion control to CMT). But I agree that some of the appeal comes from being transparent to existing apps. > We discussed this. IMO, RFC 793 establishes that TCP is a service: > > A. *of* a reliable, in-order byte-stream++ > (where ++ includes congestion response, etc., > as added later) > > B. *between* the endpoints of the connection's socket pair > (again, where socket pair is addr/port pair from 793, > not a unix-ism) > this is part of the defined API of TCP > > AFAICT, (B) is as much a part of TCP as is (A). Agreed. And one way to view what MPTCP does is that it extends B to where a connection exists between a set of "subflow endpoints" that can change over time, and the connection stays alive while at least one such subflow endpoint remains associated with the connection at each end system. In other words, it ties the existence of an MPTCP connection to the availability of IP connectivity between the end systems, rather than to the availability of IP connectivity *along a single path*. > My concern is that there are (and could/should be) applications that > expect a TCP connection to go down when the local IP address is down. ... > Opt-in is the only viable solution if the semantics are changed. I wouldn't go quite as far. The intent is to publish an Experimental specification, and one question to look at should be if there are applications that will break if MPTCP is shoved in underneath them. BGP/LDP probably would, but off the top of my head I can't think of others. And we know that some applications should be safe. For example, everything that runs inside TLS should be fine, because those apps are already binding to a TLS context rather than an TCP endpoint. Lars --Apple-Mail-49-143106085 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA3MzEwOTQwNDZaMCMGCSqGSIb3DQEJBDEWBBR1cz0PZoQ/ITPU 3LvhFziDc7mtjTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAGiXWhJEKJ8DgsMk8AHpfMp2lyEtjZ4zHxqUlCWHq2rboHkN2JiJv L823WjzwOaNy+UIn7HjRRgQWp+GUJfDMGM4pltzk9IkxFRxTs9eKDkW4iVHJLcfRcol6AVRgw40b uxkI0J5ZE+8Z0dh/26j8jRzcKmM3xeUiNMcSqV+Y/3g4dIk7Z34yBHHUhMzYfPKFZT/JmS1xabDU g+H1DPfHmgCoGJj0ZE9dFHHwdnoQpMNFLzq3n0pmSS77LjEqQjX1EdRPd9haNEnDmIki3VEqjzKJ OIOr8LoGCQCM6Z+gSZY/07GTI2El+p0VHjrEF4nMN4b4lFFxUIUkIp7Qo8bLNQAAAAAAAA== --Apple-Mail-49-143106085-- From gurtov@cs.helsinki.fi Fri Jul 31 02:54:36 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4916A3A69EB for ; Fri, 31 Jul 2009 02:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-AV66nWa8MH for ; Fri, 31 Jul 2009 02:54:35 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 83C8C28C0D7 for ; Fri, 31 Jul 2009 02:53:45 -0700 (PDT) Received: from [130.129.23.156] (dhcp-179c.meeting.ietf.org [130.129.23.156]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 31 Jul 2009 12:53:45 +0300 id 00063E22.4A72BF29.00003A6C Message-ID: <4A72BF26.3070606@cs.helsinki.fi> Date: Fri, 31 Jul 2009 12:53:42 +0300 From: Andrei Gurtov User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: John Leslie References: <4A7160BA.5030606@cs.helsinki.fi> <4A71A108.9010503@cs.helsinki.fi> <20090730140510.GP9935@verdi> In-Reply-To: <20090730140510.GP9935@verdi> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] multipath TCP/HIP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:54:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Leslie wrote: > Andrei Gurtov wrote: >> For two-ended multipath TCP it makes more sense to use HIP than shim6. >> Then there is no IPv4/IPv6 issues - in fact you could mix such paths >> together to receive their aggregate bandwidth. > > May I suggest you give a brief tutorial on how to do this? With HIP, TCP and applications see only HIT, a hash of public key. The scheduler sitting between HIP and link interfaces estimates RTT and loss of each path from a stream of TCP packets/acks and distributes TCP segments along the paths according to estimated TCP-friendly rate and trying to avoid packet reordering. So you have multipath implemented "low" in the stack, below actual TCP layer. The good thing is that prevents address hijacking, TCP reset, etc attacks since traffic is (as a rule) secured by IPsec. Applications and network stack don't need modifications, the scheduler is sitting as a user-level daemon. If you're looking for a generic HIP tutorial, there is a short intro in Cisco's IP journal http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-1/ipj_12-1.pdf > (HIP would appear to be a work in progress, and I doubt we'd all > make the same guesses where it will end up.) Well, it's in progress of being upgraded from experimental to standard track, but HIP itself has been around since 1999 and lately in quite stable form since RFC5201-5207 were published. There are HIP VPN products that are used in production factory environments. Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpyvyYACgkQP7jp0uceFkRcyACdHewFPWyqEbWDI4qZ7tQrv//M HlIAoOENysE4rhE5OWvkY0iKVu1BmFnw =Rzsg -----END PGP SIGNATURE----- From sebastien.barre@uclouvain.be Fri Jul 31 05:02:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88EED3A691A for ; Fri, 31 Jul 2009 05:02:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr0q8ki7HS9S for ; Fri, 31 Jul 2009 05:02:34 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 487893A6AF5 for ; Fri, 31 Jul 2009 05:02:33 -0700 (PDT) Received: from [192.135.167.105] (wifi-eduroam-105.sri.ucl.ac.be [192.135.167.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sbarre@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 1A051E8A72; Fri, 31 Jul 2009 14:02:32 +0200 (CEST) Message-ID: <4A72DD54.2000205@uclouvain.be> Date: Fri, 31 Jul 2009 14:02:28 +0200 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andrei Gurtov References: <4A7160BA.5030606@cs.helsinki.fi> <4A71A108.9010503@cs.helsinki.fi> <20090730140510.GP9935@verdi> <4A72BF26.3070606@cs.helsinki.fi> In-Reply-To: <4A72BF26.3070606@cs.helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1A051E8A72.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: sebastien.barre@uclouvain.be X-SGSI-Spam-Status: No Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] multipath TCP/HIP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 12:02:35 -0000 Hi, While HIP provides better security, it also comes with the cost of having that high security. Also, AFAICT, I think that Shim6 seems easier to deploy than HIP in the Internet, since Shim6 uses a particular locator as identifer, rather than a non-routable HIT. Since IPsec is probably not always required, my guess is that it would be nice to consider a multipath TCP able to run on either one of HIP or shim6. regards, Sébastien. Andrei Gurtov a écrit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John Leslie wrote: > >> Andrei Gurtov wrote: >> >>> For two-ended multipath TCP it makes more sense to use HIP than shim6. >>> Then there is no IPv4/IPv6 issues - in fact you could mix such paths >>> together to receive their aggregate bandwidth. >>> >> May I suggest you give a brief tutorial on how to do this? >> > > With HIP, TCP and applications see only HIT, a hash of public key. > The scheduler sitting between HIP and link interfaces estimates RTT and > loss of each path from a stream of TCP packets/acks and distributes TCP > segments along the paths according to estimated TCP-friendly rate and > trying to avoid packet reordering. So you have multipath implemented > "low" in the stack, below actual TCP layer. The good thing is that > prevents address hijacking, TCP reset, etc attacks since traffic is (as > a rule) secured by IPsec. Applications and network stack don't need > modifications, the scheduler is sitting as a user-level daemon. > > If you're looking for a generic HIP tutorial, there is a short intro in > Cisco's IP journal > http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-1/ipj_12-1.pdf > > >> (HIP would appear to be a work in progress, and I doubt we'd all >> make the same guesses where it will end up.) >> > > Well, it's in progress of being upgraded from experimental to standard > track, but HIP itself has been around since 1999 and lately in quite > stable form since RFC5201-5207 were published. There are HIP VPN > products that are used in production factory environments. > > Andrei > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkpyvyYACgkQP7jp0uceFkRcyACdHewFPWyqEbWDI4qZ7tQrv//M > HlIAoOENysE4rhE5OWvkY0iKVu1BmFnw > =Rzsg > -----END PGP SIGNATURE----- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium http://inl.info.ucl.ac.be/sbarre From tessa3d@gmail.com Fri Jul 31 05:34:37 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8493A6DAC for ; Fri, 31 Jul 2009 05:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3thtbxrRNCYl for ; Fri, 31 Jul 2009 05:34:36 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 3D6FD3A6E60 for ; Fri, 31 Jul 2009 05:33:50 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so559529eye.31 for ; Fri, 31 Jul 2009 05:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=pTUNFFXCy84G0V0hHDlx5bcUA2mZBLRDRgbmbEupl0k=; b=PGM9QTyuDCY/+49Vsny/9d6vguRNBbOTgp+muhWgSF7W8YdW2u1qKoR3lBUmFskm6t LqibzXI9Ddzta9rrX/WvQ/1LeRbg/eLABJfCf0v8FZeYG9uOAkAQAjVVJ0SFVrBS9ep2 zhsBcJCfPogjpX602POWQa7UZ+8y40najiu5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hnYDUsdgD3xzICaHypPuzZQ0TRRN4kBOclQZcNdjmJexpR3GfSiRpuWCmxEdmIZVbM y6FaGJ/Q/9ls/8zD6NmBFwEjkXQU3sdUFMhaPNsUtPoPsS8FVEiFd+wpDJVGmDLR5a09 0trcuyF3wXkLsdavfHLIzMy8qRFoRwzsUo12k= MIME-Version: 1.0 Received: by 10.210.61.8 with SMTP id j8mr3110860eba.2.1249043628037; Fri, 31 Jul 2009 05:33:48 -0700 (PDT) Date: Fri, 31 Jul 2009 15:33:48 +0300 Message-ID: <2a4d59320907310533g6815b0f8n87c7572f63866e98@mail.gmail.com> From: Tatiana Polishchuk To: multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=00151749f7cec21765046fffa156 Subject: Re: [multipathtcp] Multipath UDP? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 12:37:23 -0000 --00151749f7cec21765046fffa156 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Recently I've seen a presentation of Sebastian Siikavirta from Helsinki University of Technology where he described the ongoing work on multipath transport solution on top of UDP. --00151749f7cec21765046fffa156 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Recently I've seen a presentation of Sebastian Siikavirta from Helsinki University of Technology where he described the ongoing work on multipath transport solution on top of UDP.
--00151749f7cec21765046fffa156-- From baford@mpi-sws.org Fri Jul 31 12:33:17 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18E93A6D0C for ; Fri, 31 Jul 2009 12:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=2.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1DbFmefL3Oo for ; Fri, 31 Jul 2009 12:33:16 -0700 (PDT) Received: from hera.mpi-sb.mpg.de (infao0809.mpi-sb.mpg.de [139.19.1.49]) by core3.amsl.com (Postfix) with ESMTP id E4EA43A67B7 for ; Fri, 31 Jul 2009 12:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Cc:Message-Id:From:To: In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version: Subject:Date:References; bh=xZrW5h3hlURjyAt0QKygU3JNPVAcELtT4HMA ER232to=; b=NcoSSgpoNzuva7Hk35D1hLFhS494SN2PwR3N5o+DTXaYp1o8+B2w sqtXTpFVABP+QTU7QjfoG8MK9GXbsbZbDXn+mJwW15bxPbbdnx99Gg9mDDURq8tS BuvAa8ZqpYAPSAqAQKjvZEm8ad/k1rP1jGPF95fVvT+uuh7S71U6ph8= Received: from infao0525.mpi-sb.mpg.de ([139.19.1.26]:48782 helo=newmaniac.mpi-sb.mpg.de) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1MWxqp-0004Nx-VL; Fri, 31 Jul 2009 21:33:15 +0200 Received: from [212.112.167.85] (port=52030 helo=[10.43.2.83]) by newmaniac.mpi-sb.mpg.de with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1MWxqp-0005Eu-DG; Fri, 31 Jul 2009 21:33:11 +0200 Message-Id: From: Bryan Ford To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= In-Reply-To: <4A72DD54.2000205@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 21:33:09 +0200 References: <4A7160BA.5030606@cs.helsinki.fi> <4A71A108.9010503@cs.helsinki.fi> <20090730140510.GP9935@verdi> <4A72BF26.3070606@cs.helsinki.fi> <4A72DD54.2000205@uclouvain.be> X-Mailer: Apple Mail (2.935.3) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] multipath TCP/HIP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 19:33:17 -0000 Multipath TCP (or multipath ) needs at =20 least the following two components to build on, each of which can be =20 defined and implemented separately and orthogonally to each other and =20= to the multipath transport protocol itself: 1. A mechanism to detect the existence and number of paths available =20 between two logical endpoints, and to direct traffic over one =20 particular path or another. 2. A mechanism to shape (congestion control) the traffic over each =20 path in an appropriately multipath-sensitive way. #2 can be separated cleanly from the semantic part of the transport, =20 as discussed in our architecture draft, simply by having the Flow =20 Layer (which implements congestion control) provide an interface =20 allowing higher layers (in this case the Semantic Layer) to declare a =20= certain set of flows to be "bundled" or "linked" for congestion =20 control purposes. It's completely up to the congestion control =20 algorithm in the Flow Layer how to interpret that "linkage" =20 information, whether via simple 1/n MulTCP, Michio Honda's dynamic =20 weight-shifting approach, or the latest partly-coupled algorithm =20 presented in TSVAREA. The Semantic Layer doesn't need to care how the =20= Flow Layer handles linked flows; it just indicates to the Flow Layer =20 that they are connected. The Flow Layer doesn't need to care _why_ =20 flows are linked - they could just as well be linked because the =20 _application_ requested it. #1 can likewise be separated cleanly from the semantic part of the =20 transport via a simple interface, and through that interface, =20 multipath TCP (or multipath anything) could run atop any of the =20 following "multipath-capable delivery services": (a) Atop a simple mechanism that just uses multiple (IP,port) endpont =20= pairs on each host to define multiple paths, as specified in the =20 current protocol draft. (b) Atop a version of HIP modified slightly to expose the existence =20 of, and a way to direct traffic over, the multiple paths derived from =20= the many-to-one relationship of locators to identifiers in the HIP =20 world. (c) Atop a version of shim6 similarly modified. (d) Atop an IP routing protocol that has been extended with "native" =20 support for discovering and making available multiple paths between =20 two IP addresses. There are many experimental examples of such =20 protocols. In any of these options, the interface between the "multipath-capable =20= delivery service", whatever it is, and the main multipath transport, =20 can be at least conceptually very simple: 1. The multipath-capable delivery service provides a function the =20 upper layer can call to get (an estimate of) the number of paths =20 available or currently known (i.e., a simple integer) between two =20 endpoints as known to the upper layer . Change notification or =20 periodic re-checking considerations may apply of course. 2. The multipath-capable delivery service, in the function it provides =20= to the upper layer to transmit a packet, allows the upper layer to =20 specify a "path selector" - a simple integer from 0 to n-1, where n is =20= the number of paths returned above - and ensures that the packet gets =20= transmitted over that path. The key idea is that the semantic part of the multipath transport - =20 i.e., the TCP stuff that does stream-level sequencing and end-to-end =20 acknowledgment and retransmission and all that - needs to know that =20 there _are_ multiple paths but doesn't need to know almost anything =20 _about_ those paths. It just needs to know that the paths exist and =20 have a way to index them. There are several reasonable and =20 interesting ways of actually figuring out what those paths are, but =20 that functionality should be, at least logically, very separate and =20 orthogonal to the semantic part of the multipath transport. In the interest of ensuring that the multipath WG can make progress by =20= itself without unnecessary dependence on other experimental protocols, =20= I think its charter specify that mechanism (a) above be the first =20 "multipath-capable delivery service" to be worked on, but tie-ins with =20= HIP, shim6, etc., could come in later stages. Unless of course the =20 debate about changing TCP semantics makes (a) a non-option, which =20 personally I think would be a pity; there's a lot of value in having =20 multipath TCP usable by unmodified or nearly-unmodified applications =20 when it can be determined to be safe to do so. Bryan On Jul 31, 2009, at 2:02 PM, S=E9bastien Barr=E9 wrote: > Hi, > > While HIP provides better security, it also comes with the cost of =20 > having that high security. > Also, AFAICT, I think that Shim6 seems easier to deploy than HIP in =20= > the Internet, since Shim6 uses a particular locator as identifer, =20 > rather than a non-routable HIT. > > Since IPsec is probably not always required, my guess is that it =20 > would be nice to consider a multipath TCP > able to run on either one of HIP or shim6. > > regards, > > S=E9bastien. > > Andrei Gurtov a =E9crit : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> John Leslie wrote: >> >>> Andrei Gurtov wrote: >>> >>>> For two-ended multipath TCP it makes more sense to use HIP than =20 >>>> shim6. >>>> Then there is no IPv4/IPv6 issues - in fact you could mix such =20 >>>> paths >>>> together to receive their aggregate bandwidth. >>>> >>> May I suggest you give a brief tutorial on how to do this? >>> >> >> With HIP, TCP and applications see only HIT, a hash of public key. >> The scheduler sitting between HIP and link interfaces estimates RTT =20= >> and >> loss of each path from a stream of TCP packets/acks and distributes =20= >> TCP >> segments along the paths according to estimated TCP-friendly rate and >> trying to avoid packet reordering. So you have multipath implemented >> "low" in the stack, below actual TCP layer. The good thing is that >> prevents address hijacking, TCP reset, etc attacks since traffic is =20= >> (as >> a rule) secured by IPsec. Applications and network stack don't need >> modifications, the scheduler is sitting as a user-level daemon. >> >> If you're looking for a generic HIP tutorial, there is a short =20 >> intro in >> Cisco's IP journal >> = http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-1/ipj_12= -1.pdf >> >> >>> (HIP would appear to be a work in progress, and I doubt we'd all >>> make the same guesses where it will end up.) >>> >> >> Well, it's in progress of being upgraded from experimental to =20 >> standard >> track, but HIP itself has been around since 1999 and lately in quite >> stable form since RFC5201-5207 were published. There are HIP VPN >> products that are used in production factory environments. >> >> Andrei >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkpyvyYACgkQP7jp0uceFkRcyACdHewFPWyqEbWDI4qZ7tQrv//M >> HlIAoOENysE4rhE5OWvkY0iKVu1BmFnw >> =3DRzsg >> -----END PGP SIGNATURE----- >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> > > --=20 > S=E9bastien Barr=E9 > Researcher, > CSE department, UCLouvain, Belgium > http://inl.info.ucl.ac.be/sbarre > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From sebastien.barre@uclouvain.be Fri Jul 31 15:17:20 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175B73A6D38 for ; Fri, 31 Jul 2009 15:17:20 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPDfaDUR0qxM for ; Fri, 31 Jul 2009 15:17:18 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 5E89D3A6D30 for ; Fri, 31 Jul 2009 15:17:18 -0700 (PDT) Received: from [192.168.1.120] (unknown [91.86.147.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sbarre@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 11AB7E8D56; Sat, 1 Aug 2009 00:17:21 +0200 (CEST) Message-ID: <4A736D6B.8090203@uclouvain.be> Date: Sat, 01 Aug 2009 00:17:15 +0200 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Bryan Ford References: <4A7160BA.5030606@cs.helsinki.fi> <4A71A108.9010503@cs.helsinki.fi> <20090730140510.GP9935@verdi> <4A72BF26.3070606@cs.helsinki.fi> <4A72DD54.2000205@uclouvain.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 11AB7E8D56.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: sebastien.barre@uclouvain.be X-SGSI-Spam-Status: No Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] multipath TCP/HIP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 22:17:20 -0000 Hi Bryan, I completely agree with you. Actually I have worked quite a bit with this kind of architecture, which I described in details in section 3 of Trilogy deliverable 4 (http://trilogy-project.org/fileadmin/publications/Deliverables/D4_-_Design_Space_Analysis_for_Reachability.pdf) as well as in section 5.2 of Trilogy deliverable 5 (http://trilogy-project.org/fileadmin/publications/Deliverables/D5_-_Design_Space_Analysis_for_Resource_Control.pdf). A short update/summary is also present in Trilogy deliverable 7, section 3.1.2. (http://trilogy-project.org/fileadmin/publications/Deliverables/D7_-_Trilogy_Overall_Architecture_Including_Design_Principles.pdf) In the D4, the path management aspects are described (which corresponds more or less to your #1 description), while in the D5, the overall architecture and definition of an "MPS" (MultiPath Scheduler) are provided (#2 in your description). I also have already a prototype implementation that runs above Shim6, but is sufficiently generic (it actually implements the architecture described in D4,D5,D7) to be extended for other technologies. regards, Sébastien. Bryan Ford a écrit : > Multipath TCP (or multipath ) needs at > least the following two components to build on, each of which can be > defined and implemented separately and orthogonally to each other and > to the multipath transport protocol itself: > > 1. A mechanism to detect the existence and number of paths available > between two logical endpoints, and to direct traffic over one > particular path or another. > 2. A mechanism to shape (congestion control) the traffic over each > path in an appropriately multipath-sensitive way. > > #2 can be separated cleanly from the semantic part of the transport, > as discussed in our architecture draft, simply by having the Flow > Layer (which implements congestion control) provide an interface > allowing higher layers (in this case the Semantic Layer) to declare a > certain set of flows to be "bundled" or "linked" for congestion > control purposes. It's completely up to the congestion control > algorithm in the Flow Layer how to interpret that "linkage" > information, whether via simple 1/n MulTCP, Michio Honda's dynamic > weight-shifting approach, or the latest partly-coupled algorithm > presented in TSVAREA. The Semantic Layer doesn't need to care how the > Flow Layer handles linked flows; it just indicates to the Flow Layer > that they are connected. The Flow Layer doesn't need to care _why_ > flows are linked - they could just as well be linked because the > _application_ requested it. > > #1 can likewise be separated cleanly from the semantic part of the > transport via a simple interface, and through that interface, > multipath TCP (or multipath anything) could run atop any of the > following "multipath-capable delivery services": > > (a) Atop a simple mechanism that just uses multiple (IP,port) endpont > pairs on each host to define multiple paths, as specified in the > current protocol draft. > (b) Atop a version of HIP modified slightly to expose the existence > of, and a way to direct traffic over, the multiple paths derived from > the many-to-one relationship of locators to identifiers in the HIP world. > (c) Atop a version of shim6 similarly modified. > (d) Atop an IP routing protocol that has been extended with "native" > support for discovering and making available multiple paths between > two IP addresses. There are many experimental examples of such > protocols. > > In any of these options, the interface between the "multipath-capable > delivery service", whatever it is, and the main multipath transport, > can be at least conceptually very simple: > > 1. The multipath-capable delivery service provides a function the > upper layer can call to get (an estimate of) the number of paths > available or currently known (i.e., a simple integer) between two > endpoints as known to the upper layer . Change notification or > periodic re-checking considerations may apply of course. > > 2. The multipath-capable delivery service, in the function it provides > to the upper layer to transmit a packet, allows the upper layer to > specify a "path selector" - a simple integer from 0 to n-1, where n is > the number of paths returned above - and ensures that the packet gets > transmitted over that path. > > The key idea is that the semantic part of the multipath transport - > i.e., the TCP stuff that does stream-level sequencing and end-to-end > acknowledgment and retransmission and all that - needs to know that > there _are_ multiple paths but doesn't need to know almost anything > _about_ those paths. It just needs to know that the paths exist and > have a way to index them. There are several reasonable and > interesting ways of actually figuring out what those paths are, but > that functionality should be, at least logically, very separate and > orthogonal to the semantic part of the multipath transport. > > In the interest of ensuring that the multipath WG can make progress by > itself without unnecessary dependence on other experimental protocols, > I think its charter specify that mechanism (a) above be the first > "multipath-capable delivery service" to be worked on, but tie-ins with > HIP, shim6, etc., could come in later stages. Unless of course the > debate about changing TCP semantics makes (a) a non-option, which > personally I think would be a pity; there's a lot of value in having > multipath TCP usable by unmodified or nearly-unmodified applications > when it can be determined to be safe to do so. > > Bryan > > > On Jul 31, 2009, at 2:02 PM, Sébastien Barré wrote: >> Hi, >> >> While HIP provides better security, it also comes with the cost of >> having that high security. >> Also, AFAICT, I think that Shim6 seems easier to deploy than HIP in >> the Internet, since Shim6 uses a particular locator as identifer, >> rather than a non-routable HIT. >> >> Since IPsec is probably not always required, my guess is that it >> would be nice to consider a multipath TCP >> able to run on either one of HIP or shim6. >> >> regards, >> >> Sébastien. >> >> Andrei Gurtov a écrit : >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> John Leslie wrote: >>> >>>> Andrei Gurtov wrote: >>>> >>>>> For two-ended multipath TCP it makes more sense to use HIP than >>>>> shim6. >>>>> Then there is no IPv4/IPv6 issues - in fact you could mix such paths >>>>> together to receive their aggregate bandwidth. >>>>> >>>> May I suggest you give a brief tutorial on how to do this? >>>> >>> >>> With HIP, TCP and applications see only HIT, a hash of public key. >>> The scheduler sitting between HIP and link interfaces estimates RTT and >>> loss of each path from a stream of TCP packets/acks and distributes TCP >>> segments along the paths according to estimated TCP-friendly rate and >>> trying to avoid packet reordering. So you have multipath implemented >>> "low" in the stack, below actual TCP layer. The good thing is that >>> prevents address hijacking, TCP reset, etc attacks since traffic is (as >>> a rule) secured by IPsec. Applications and network stack don't need >>> modifications, the scheduler is sitting as a user-level daemon. >>> >>> If you're looking for a generic HIP tutorial, there is a short intro in >>> Cisco's IP journal >>> http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-1/ipj_12-1.pdf >>> >>> >>> >>>> (HIP would appear to be a work in progress, and I doubt we'd all >>>> make the same guesses where it will end up.) >>>> >>> >>> Well, it's in progress of being upgraded from experimental to standard >>> track, but HIP itself has been around since 1999 and lately in quite >>> stable form since RFC5201-5207 were published. There are HIP VPN >>> products that are used in production factory environments. >>> >>> Andrei >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.9 (MingW32) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAkpyvyYACgkQP7jp0uceFkRcyACdHewFPWyqEbWDI4qZ7tQrv//M >>> HlIAoOENysE4rhE5OWvkY0iKVu1BmFnw >>> =Rzsg >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >> >> -- >> Sébastien Barré >> Researcher, >> CSE department, UCLouvain, Belgium >> http://inl.info.ucl.ac.be/sbarre >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium http://inl.info.ucl.ac.be/sbarre