From Aleksi.Suhonen@tut.fi Sun Jun 14 19:44: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 5D8A43A6C7D for ; Sun, 14 Jun 2009 19:44:17 -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 mdAFtYz6Q475 for ; Sun, 14 Jun 2009 19:44:16 -0700 (PDT) Received: from av-gw2.cc.tut.fi (av-gw2.cc.tut.fi [130.230.130.111]) by core3.amsl.com (Postfix) with ESMTP id 667143A657C for ; Sun, 14 Jun 2009 19:44:15 -0700 (PDT) Received: from av-gw2.cc.tut.fi (unknown [127.0.0.1]) by av-gw2.cc.tut.fi (Symantec Mail Security) with ESMTP id D9C46150029 for ; Mon, 15 Jun 2009 05:44:23 +0300 (EEST) X-AuditID: 82e6826f-ac999bb0000003e2-d5-4a35b5873684 Received: from mail.cc.tut.fi (unknown [130.230.1.120]) by av-gw2.cc.tut.fi (Symantec Mail Security) with ESMTP id D4C7390052 for ; Mon, 15 Jun 2009 05:44:23 +0300 (EEST) Received: from [130.230.52.50] (rotta.atm.tut.fi [130.230.52.50]) by mail.cc.tut.fi (Postfix) with ESMTP id 88F29A40F8 for ; Mon, 15 Jun 2009 05:44:24 +0300 (EEST) Message-ID: <4A35B588.5030903@tut.fi> Date: Mon, 15 Jun 2009 05:44:24 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Institute of Communications Engineering User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: multipathtcp@ietf.org References: <5EBA85DF-FC90-4017-88F9-B59BF4BDB227@muada.com> In-Reply-To: <5EBA85DF-FC90-4017-88F9-B59BF4BDB227@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [multipathtcp] A Suggestion for Address Selection X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.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, 15 Jun 2009 02:44:17 -0000 Hi, This is a request for comments on a draft for an internet draft on a new address selection algorithm that I'm developing as part of the Finnish Future Internet project. I'm trying to find a home working group for it, but I'm not finding it easy since it seems to affect so many things. Instead of sending the whole text on several mailing lists, I put the rough draft on the web: http://www.axu.tm/2009/draft-axu-addr-sel-pre00.html The motivation for this algorithm comes from multi-pathing protocols and the need for agile address re-selection when forced to reroute. Readers of the multipathtcp list may be especially interested in commenting the connection pooling subsection of the draft, since it would add a sort of crude multi-pathing support to plain TCP protocols that open several connections. Sincerely awaiting your constructive feedback, -- Aleksi Suhonen Department of Communications Engineering Tampere University of Technology From Aleksi.Suhonen@tut.fi Sun Jun 14 20:34: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 4949D3A6919 for ; Sun, 14 Jun 2009 20:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 SpKnjt770Rhm for ; Sun, 14 Jun 2009 20:34:14 -0700 (PDT) Received: from av-gw1.cc.tut.fi (av-gw1.cc.tut.fi [130.230.130.110]) by core3.amsl.com (Postfix) with ESMTP id 537573A6805 for ; Sun, 14 Jun 2009 20:34:14 -0700 (PDT) Received: from av-gw1.cc.tut.fi (unknown [127.0.0.1]) by av-gw1.cc.tut.fi (Symantec Mail Security) with ESMTP id C9CD8B5801B for ; Mon, 15 Jun 2009 06:34:23 +0300 (EEST) X-AuditID: 82e6826e-a4ec4bb0000009be-6b-4a35c13fca76 Received: from mail.cc.tut.fi (unknown [130.230.1.120]) by av-gw1.cc.tut.fi (Symantec Mail Security) with ESMTP id 8F306430026 for ; Mon, 15 Jun 2009 06:34:23 +0300 (EEST) Received: from [130.230.52.50] (rotta.atm.tut.fi [130.230.52.50]) by mail.cc.tut.fi (Postfix) with ESMTP id 7D591A40F8 for ; Mon, 15 Jun 2009 06:34:23 +0300 (EEST) Message-ID: <4A35C13F.7040707@tut.fi> Date: Mon, 15 Jun 2009 06:34:23 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Institute of Communications Engineering User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 CC: multipathtcp@ietf.org References: <4A031B0F.4030606@employees.org> <4A031E1E.5050900@it.uc3m.es> <20090507211619.GA35382@cisco.com> <5E59C0C6-4A97-4253-954D-05139E1F684C@muada.com> <4A03635F.4010107@it.uc3m.es> <4A02FC62.8080503@it.uc3m.es> <4A031B0F.4030606@employees.org> <4A031E1E.5050900@it.uc3m.es> <20090507211619.GA35382@cisco.com> <5E59C0C6-4A97-4253-954D-05139E1F684C@muada.com> <20090507230452.GC35382@cisco.com> <1241789497.4055.8.camel@nhuynhth-laptop> <001e01c9cfff$bde8f1e0$103947ab@cisco.com> <97963A5D-FD5D-4D08-99F6-12455BB90FE4@muada.com> <001f01c9d005$0c583110$103947ab@cisco.com> <1241818843.26211.67.camel@nhuynhth-laptop> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [multipathtcp] TCP modification vs switching to SCTP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.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, 15 Jun 2009 03:34:15 -0000 Bryan Ford wrote: > I think this "multipath TCP versus multipath SCTP" question is > important, but still misses a larger issue: SCTP and TCP are different > transports providing substantially different application-visible > semantics, but we would really like to have multipath support for _both_ > of those transports (and perhaps others). One thing I haven't noticed yet in these discussions is interaction with other multi-pathing protocols underneath or on top of TCP. For example, if you run TCP over HIP, you get multi-pathing from HIP. Or if you run iSCSI over TCP, iSCSI itself takes care of multi-pathing. What happens to these protocol combinations if TCP starts to behave differently too? > It's a pain for TCP > applications to switch to SCTP because it involves programmers learning > a new API with different semantics: This is why operating systems that support SCTP have two separate APIs, one that provides an identical interface as TCP with the exception of one parameter to one function call, and one that is substantially different and offers much more control over the finer features of SCTP, isn't it? -- Aleksi Suhonen From iljitsch@muada.com Mon Jun 15 06:47: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 B125D3A6832 for ; Mon, 15 Jun 2009 06:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.637 X-Spam-Level: X-Spam-Status: No, score=-6.637 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 dINGSoshKN8C for ; Mon, 15 Jun 2009 06:47:02 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 8194E3A6CC8 for ; Mon, 15 Jun 2009 06:47:02 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.219]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5FDkFxi065407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2009 15:46:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Aleksi Suhonen In-Reply-To: <4A35B588.5030903@tut.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: Mon, 15 Jun 2009 15:45:43 +0200 References: <5EBA85DF-FC90-4017-88F9-B59BF4BDB227@muada.com> <4A35B588.5030903@tut.fi> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] A Suggestion for Address Selection X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.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, 15 Jun 2009 13:47:03 -0000 On 15 jun 2009, at 4:44, Aleksi Suhonen wrote: > http://www.axu.tm/2009/draft-axu-addr-sel-pre00.html Section 2: for hosts that only have a default route this doesn't seem to do much... I don't understand the text in 2.1. In 2.2 you assume multiple routing tables. I don't think that's a reasonable expectation. (But I agree that using an address with the router that provided the RA is a good goal.) Not entirely sure about 2.3, but I probably disagree. We tried to tackle some of these issues in the early work on the shim6 reap protocol and I know there is (has been?) work going on on a new version of RFC 3484. Having something useful in this area would be very good, but I'm not seeing much of practical use in your draft as it is now. You may want to start filling in some of those "TBD"s. I think a discussion of a single routing table vs a multiple routing table vs a hybrid model would be useful, and probably an address _ordering_ rather than filtering. Iljitsch From iljitsch@muada.com Thu Jun 25 14:50: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 4B4AF3A6981 for ; Thu, 25 Jun 2009 14:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 1Zv+UCO1gcP0 for ; Thu, 25 Jun 2009 14:50:30 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 369623A697A for ; Thu, 25 Jun 2009 14:49:01 -0700 (PDT) Received: from [192.168.0.193] (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 n5PKj85i066636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 25 Jun 2009 22:45:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: 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 v930.3) Date: Thu, 25 Jun 2009 22:44:42 +0200 X-Mailer: Apple Mail (2.930.3) Subject: [multipathtcp] [T3-Rsrc Control] Multipath TCP use cases X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.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, 25 Jun 2009 21:50:31 -0000 Hi all, So far we've more or less assumed bulk data transfer as the use case for multipath TCP. I think multipath TCP and/or multipath transport in general and/or some of the underlying mechanisms (testing paths to find the best one(s)) are more broadly applicable. There are basically six different types of communication: 1. Single packet request/response transactions (like the DNS) 2. Multi-packet, but limited size transactions (like typical HTTP transfers) 3. Bulk transfers (FTP or HTTP transfer of large files) 4. Low-bandwidth interactive traffic (such as Telnet) 5. Low-bandwidth streaming (VoIP) 6. High-bandwidth streaming (video) With the exception of 1, all can benefit from using multiple paths. In all cases except 6, the most optimal strategy is to distribute packets over the paths such that the last bit arrives within the least amount of time. In cases 4 and 5, that means using the path with the shortest round trip times exclusively. In case 3, the round trip times of individual packets are so short compared to the total length of the transfer that choosing the shortest RTT path for an individual packet provides virtually no benefit. In that case, it's important to either use all available paths fully, or order the paths in order of decreasing bandwidth and use them in that order as aggressively as permitted within the bounds of fairness. In case 2, if the size of the transaction is known up front and the properties of the paths are also known up front, ore can be learned quickly enough, it's possible to distribute the packets over the paths such that the last bit arrives in the minimum amount of time possible. In case 6 there is usually a fairly fixed amount of bandwidth that is required. If that bandwidth is available on one of the paths, the obviously the transfer can simply use that path. If no single path is capable of providing the required bandwidth, then congestion control can be executed for multiple paths in order to determine how much bandwidth may be used on each path. Packets are then distributed over each path within the limits of the congestion window for that path. This way, a stream's bandwidth is limited by the baggregate bandwidth of the available paths, not by that of a single path. From gorry@erg.abdn.ac.uk Fri Jun 26 00:13:12 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04093A6890 for ; Fri, 26 Jun 2009 00:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 r8L2EBmpGT6T for ; Fri, 26 Jun 2009 00:13:12 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id A17803A690B for ; Fri, 26 Jun 2009 00:13:10 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5Q7DHAs020586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 Jun 2009 08:13:17 +0100 (BST) Message-ID: <4A44750D.7010106@erg.abdn.ac.uk> Date: Fri, 26 Jun 2009 08:13:17 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Iljitsch van Beijnum References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [T3-Rsrc Control] Multipath TCP use cases X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 07:13:13 -0000 Iljitsch van Beijnum wrote: > Hi all, > > So far we've more or less assumed bulk data transfer as the use case for > multipath TCP. I think multipath TCP and/or multipath transport in > general and/or some of the underlying mechanisms (testing paths to find > the best one(s)) are more broadly applicable. > > There are basically six different types of communication: > > 1. Single packet request/response transactions (like the DNS) > 2. Multi-packet, but limited size transactions (like typical HTTP > transfers) > 3. Bulk transfers (FTP or HTTP transfer of large files) > 4. Low-bandwidth interactive traffic (such as Telnet) > 5. Low-bandwidth streaming (VoIP) > 6. High-bandwidth streaming (video) > We could also consider bulk transfer that is unattended, like 3, but with even more relaxed time constraints. Would that change things? > With the exception of 1, all can benefit from using multiple paths. In > all cases except 6, the most optimal strategy is to distribute packets > over the paths such that the last bit arrives within the least amount of > time. > > In cases 4 and 5, that means using the path with the shortest round trip > times exclusively. In case 3, the round trip times of individual packets > are so short compared to the total length of the transfer that choosing > the shortest RTT path for an individual packet provides virtually no > benefit. In that case, it's important to either use all available paths > fully, or order the paths in order of decreasing bandwidth and use them > in that order as aggressively as permitted within the bounds of fairness. > > In case 2, if the size of the transaction is known up front and the > properties of the paths are also known up front, ore can be learned > quickly enough, it's possible to distribute the packets over the paths > such that the last bit arrives in the minimum amount of time possible. > Do you think this is likely to be a common case? > In case 6 there is usually a fairly fixed amount of bandwidth that is > required. If that bandwidth is available on one of the paths, the > obviously the transfer can simply use that path. If no single path is > capable of providing the required bandwidth, then congestion control can > be executed for multiple paths in order to determine how much bandwidth > may be used on each path. Packets are then distributed over each path > within the limits of the congestion window for that path. This way, a > stream's bandwidth is limited by the baggregate bandwidth of the > available paths, not by that of a single path. > In case 6 - I think this is true for the streaming of video in real-time (as in while with video-conference video), rather than receiver-buffered video? In video-streaming applications with 10-20 seconds of buffer, or so, there is quite some slack-time. > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > Gorry From iljitsch@muada.com Fri Jun 26 01:28: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 9464B3A6917 for ; Fri, 26 Jun 2009 01:28:31 -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 CVhVfboOrHf3 for ; Fri, 26 Jun 2009 01:28:28 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 576353A6849 for ; Fri, 26 Jun 2009 01:28:24 -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 n5Q8QYv7070291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Jun 2009 10:26:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <7D266C7C-539A-436B-9C00-476644823965@muada.com> From: Iljitsch van Beijnum To: gorry@erg.abdn.ac.uk In-Reply-To: <4A44750D.7010106@erg.abdn.ac.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: Fri, 26 Jun 2009 10:26:09 +0200 References: <4A44750D.7010106@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [T3-Rsrc Control] Multipath TCP use cases X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.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, 26 Jun 2009 08:28:32 -0000 On 26 jun 2009, at 9:13, Gorry Fairhurst wrote: >> 3. Bulk transfers (FTP or HTTP transfer of large files) > We could also consider bulk transfer that is unattended, like 3, but > with even more relaxed time constraints. Would that change things? Don't think so... How makes the presence of the user any difference to the multipath? Of course it's possible to argue that unattended communication can be less agressive about the amount of bandwidth that it claims, but that would be true regardless of the use of multiple paths, this is what LEDBAT is doing. >> In case 2, if the size of the transaction is known up front and the >> properties of the paths are also known up front, ore can be learned >> quickly enough, it's possible to distribute the packets over the >> paths such that the last bit arrives in the minimum amount of time >> possible. > Do you think this is likely to be a common case? Well, this would be your typical HTTP transfer for a web page or an image. The question is whether between the minimum number of packets that we need to test at least a couple of paths and the requirement that the length of the transmission be known early = the transmission is small enough that it fits within the send buffer there is a reasonable number of transactions that qualify. > In case 6 - I think this is true for the streaming of video in real- > time (as in while with video-conference video), rather than receiver- > buffered video? In video-streaming applications with 10-20 seconds > of buffer, or so, there is quite some slack-time. If you're watching a 1.5 Mbps stream but you have two 1 Mbps connections to the internet the buffer isn't going to help you much. :-) Iljitsch From michael.scharf@ikr.uni-stuttgart.de Fri Jun 26 09:10: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 569573A6882 for ; Fri, 26 Jun 2009 09:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGBAI6GDXF5E for ; Fri, 26 Jun 2009 09:10:16 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 716BB3A6899 for ; Fri, 26 Jun 2009 09:10:16 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 43CDF439F5; Fri, 26 Jun 2009 18:10:26 +0200 (CEST) Received: from ikr.uni-stuttgart.de (cnode01 [10.21.20.1]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id 2D8E1BC07E; Fri, 26 Jun 2009 18:10:26 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Fri, 26 Jun 2009 18:10:26 +0200 Date: Fri, 26 Jun 2009 18:10:26 +0200 From: Michael Scharf To: Iljitsch van Beijnum Message-ID: <20090626161026.GA28555@ikr.uni-stuttgart.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [T3-Rsrc Control] Multipath TCP use cases X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.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, 26 Jun 2009 16:10:17 -0000 On Thu, 25 Jun 2009 at 22:44:42, Iljitsch van Beijnum wrote: > There are basically six different types of communication: > > 1. Single packet request/response transactions (like the DNS) > 2. Multi-packet, but limited size transactions (like typical HTTP > transfers) > 3. Bulk transfers (FTP or HTTP transfer of large files) > 4. Low-bandwidth interactive traffic (such as Telnet) > 5. Low-bandwidth streaming (VoIP) > 6. High-bandwidth streaming (video) > > With the exception of 1, all can benefit from using multiple paths. In > all cases except 6, the most optimal strategy is to distribute packets > over the paths such that the last bit arrives within the least amount of > time. > > In cases 4 and 5, that means using the path with the shortest round trip > times exclusively. In case 3, the round trip times of individual packets > are so short compared to the total length of the transfer that choosing > the shortest RTT path for an individual packet provides virtually no > benefit. In that case, it's important to either use all available paths > fully, or order the paths in order of decreasing bandwidth and use them > in that order as aggressively as permitted within the bounds of fairness. Why is it not optimal to order the paths always in order of increasing RTTs, i. e., the sender first uses the path with the smallest RTT only, and it sucessively starts to distribute the data over (all) other paths once it becomes clear that the bandwidth of the first one is not "sufficient"? Such a heuristic might not require any distinction between application types 3,4,5. Do I miss something? > In case 2, if the size of the transaction is known up front and the > properties of the paths are also known up front, ore can be learned > quickly enough, it's possible to distribute the packets over the paths > such that the last bit arrives in the minimum amount of time possible. What precisely is the "size of the transaction"? A network stack can easily measure the amount of application data queued in the socket. Is there any benefit of determining the total amount of data that an application plans to send? Michael From iljitsch@muada.com Fri Jun 26 12:08: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 471A73A6B62 for ; Fri, 26 Jun 2009 12:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTArr1xLIfin for ; Fri, 26 Jun 2009 12:08:31 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 28DF93A6B07 for ; Fri, 26 Jun 2009 12:08:31 -0700 (PDT) Received: from [192.168.0.192] (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 n5QJ8BOZ073793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Jun 2009 21:08:41 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <38E4E372-C622-4CF1-BB3B-4A3127107FDF@muada.com> From: Iljitsch van Beijnum To: Michael Scharf In-Reply-To: <20090626161026.GA28555@ikr.uni-stuttgart.de> 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, 26 Jun 2009 21:07:27 +0200 References: <20090626161026.GA28555@ikr.uni-stuttgart.de> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [T3-Rsrc Control] Multipath TCP use cases X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.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, 26 Jun 2009 19:08:32 -0000 On 26 jun 2009, at 18:10, Michael Scharf wrote: >> 2. Multi-packet, but limited size transactions (like typical HTTP >> transfers) >> 3. Bulk transfers (FTP or HTTP transfer of large files) >> 4. Low-bandwidth interactive traffic (such as Telnet) >> 5. Low-bandwidth streaming (VoIP) >> 6. High-bandwidth streaming (video) > Why is it not optimal to order the paths always in order of increasing > RTTs, i. e., the sender first uses the path with the smallest RTT > only, and it sucessively starts to distribute the data over (all) > other paths once it becomes clear that the bandwidth of the first one > is not "sufficient"? Such a heuristic might not require any > distinction between application types 3,4,5. Do I miss something? Only in cases 5 and 6 do you (hopefully) know how much bandwidth is enough. In case 3 it's never enough, you always want to take more. >> In case 2, if the size of the transaction is known up front and the >> properties of the paths are also known up front, ore can be learned >> quickly enough, it's possible to distribute the packets over the >> paths >> such that the last bit arrives in the minimum amount of time >> possible. > What precisely is the "size of the transaction"? A network stack can > easily measure the amount of application data queued in the socket. Is > there any benefit of determining the total amount of data that an > application plans to send? Well, if I have a channel that can take 20 1000-byte packets per second with a 100 ms RTT and another channel that can take 100 1000- byte packets per second with a 500 ms RTT, then it takes 100 ms for the first packet to be ACKed on the low BT/RTT path and then another 1000 / 20 = 50 ms per packet for the other 4, so a total of 300 ms. On the high BW/RTT path the initial ACK is 500 ms and then 1000 / 100 = 10 ms for the other 4 = 540 total. So in this case I would want to send all packets over the low BW/RTT path. Now if there's another 10 packets following those initial 5, this becomes 800 vs 640 ms so it would have been better to send all packets over the high BT/RTT path. (Although it's even better if I can send 9 packets over the low path and 6 over the high path, for a completion time of 500 on the low path and 550 on the high path (or 10 / 5 = 550 / 540).) After a certain threshold I should always send 1/6th of my packets over the low path and 5/6th over the high path, so I don't really need to know how large the transfer is exactly, just that it's big enough that using the low path exclusively isn't the fastest option. And of course the fact that we don't know the path properties until we start sending packets severely complicates all of this. From michael.scharf@ikr.uni-stuttgart.de Fri Jun 26 13:55: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 CE1163A6932 for ; Fri, 26 Jun 2009 13:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZCCW29gfhsg for ; Fri, 26 Jun 2009 13:55:54 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 0862E3A67B0 for ; Fri, 26 Jun 2009 13:55:54 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id C79FD439F5; Fri, 26 Jun 2009 22:56:11 +0200 (CEST) Received: from ikr.uni-stuttgart.de (cnode01 [10.21.20.1]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id B55FCBC07E; Fri, 26 Jun 2009 22:56:11 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Fri, 26 Jun 2009 22:56:11 +0200 Date: Fri, 26 Jun 2009 22:56:11 +0200 From: Michael Scharf To: Iljitsch van Beijnum Message-ID: <20090626205611.GA10287@ikr.uni-stuttgart.de> References: <20090626161026.GA28555@ikr.uni-stuttgart.de> <38E4E372-C622-4CF1-BB3B-4A3127107FDF@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <38E4E372-C622-4CF1-BB3B-4A3127107FDF@muada.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [T3-Rsrc Control] Multipath TCP use cases X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.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, 26 Jun 2009 20:55:54 -0000 On Fri, 26 Jun 2009 at 21:07:27, Iljitsch van Beijnum wrote: > On 26 jun 2009, at 18:10, Michael Scharf wrote: > >>> 2. Multi-packet, but limited size transactions (like typical HTTP >>> transfers) >>> 3. Bulk transfers (FTP or HTTP transfer of large files) >>> 4. Low-bandwidth interactive traffic (such as Telnet) >>> 5. Low-bandwidth streaming (VoIP) >>> 6. High-bandwidth streaming (video) > >> Why is it not optimal to order the paths always in order of increasing >> RTTs, i. e., the sender first uses the path with the smallest RTT >> only, and it sucessively starts to distribute the data over (all) >> other paths once it becomes clear that the bandwidth of the first one >> is not "sufficient"? Such a heuristic might not require any >> distinction between application types 3,4,5. Do I miss something? > > Only in cases 5 and 6 do you (hopefully) know how much bandwidth is > enough. In case 3 it's never enough, you always want to take more. Sure. My point is that one could maybe handle both case 3 _and_ cases 4+5 with the same straightforward strategy. And then there would be no need to distinguish between these application types. You can detect quite fast whether the transfer over the path with the smallest RTT is application-limited or not (at least in static environments). In case 5 and 6 this is likely to be the case, i. e., a cwnd grows beyond the amount of available app data. Then, this path is just fine. In case 3, application limitation will not occur. Then, other paths beyond the one with the smallest RTT should be used as well. It should be possible to detect application limitation on the path with the smallest RTT within few seconds. Thus, if you always use the path with the smallest RTT first, and if you start to use additional paths once you detect that the path with the smallest RTT is not application-limited, you can handle _both_ case 3 and 4+5 with the same simple heuristic, without requiring any a-priori knowledge about the application type. But of course I may be wrong. Michael From iljitsch@muada.com Sun Jun 28 07:10: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 1DD153A67AF for ; Sun, 28 Jun 2009 07:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 kFF-EN7Dnq0K for ; Sun, 28 Jun 2009 07:10:53 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6AD3A68F4 for ; Sun, 28 Jun 2009 07:10:52 -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 n5SEB9ii085475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Jun 2009 16:11:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Michael Scharf In-Reply-To: <20090626205611.GA10287@ikr.uni-stuttgart.de> 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: Sun, 28 Jun 2009 16:10:45 +0200 References: <20090626161026.GA28555@ikr.uni-stuttgart.de> <38E4E372-C622-4CF1-BB3B-4A3127107FDF@muada.com> <20090626205611.GA10287@ikr.uni-stuttgart.de> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [T3-Rsrc Control] Multipath TCP use cases X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.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, 28 Jun 2009 14:10:54 -0000 On 26 jun 2009, at 22:56, Michael Scharf wrote: >> Only in cases 5 and 6 do you (hopefully) know how much bandwidth is >> enough. In case 3 it's never enough, you always want to take more. > Sure. My point is that one could maybe handle both case 3 _and_ cases > 4+5 with the same straightforward strategy. And then there would be no > need to distinguish between these application types. The difference is that VoIP/Telnet needs a fast turnaround for individual packets but bandwidth is almost never an issue, which is the opposite for bulk transfers. However, if we think of VoIP packets and Telnet keystrokes/responses as minitransactions and bulk transfers as really large transactions, we only need to solve the general case of transactions (both small and large) which would be something along the lines of: send on the lowest RTT path exclusively for RTT2 - RTT1 milliseconds if the data on hand fits within that timeframe, otherwise/after that distribute packets over paths 1 and 2 relative to the path bandwidth. (See my earlier message.) Since 1-packet "transactions" like in VoIP take zero time, you never end up in the situation > You can detect quite fast whether the transfer over the path with the > smallest RTT is application-limited or not (at least in static > environments). In case 5 and 6 this is likely to be the case, i. e., > a cwnd grows beyond the amount of available app data. Then, this path > is just fine. In case 3, application limitation will not occur. Then, > other paths beyond the one with the smallest RTT should be used as > well. That may be a good starting point, but even if the app doesn't send unlimited data there can be value in using multiple paths as this will get the last bit to the other side sooner than just using the lowest RTT path. But certainly in the case where the app doesn't fill up an entire packet we should just use the lowest RTT path. If the path isn't fast enough then the Nagle algorithm will kick in and the data will no longer be smaller than a packet size after some time. From Aleksi.Suhonen@tut.fi Mon Jun 29 03:13: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 A13A43A6D3D for ; Mon, 29 Jun 2009 03:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 0GemBrZRGtIh for ; Mon, 29 Jun 2009 03:13:35 -0700 (PDT) Received: from av-gw1.cc.tut.fi (av-gw1.cc.tut.fi [130.230.130.110]) by core3.amsl.com (Postfix) with ESMTP id B60873A6D1E for ; Mon, 29 Jun 2009 03:13:35 -0700 (PDT) Received: from av-gw1.cc.tut.fi (unknown [127.0.0.1]) by av-gw1.cc.tut.fi (Symantec Mail Security) with ESMTP id 255E0B58020 for ; Mon, 29 Jun 2009 13:13:54 +0300 (EEST) X-AuditID: 82e6826e-a8acabb0000009be-c5-4a4893e106cf Received: from mail.cc.tut.fi (unknown [130.230.1.120]) by av-gw1.cc.tut.fi (Symantec Mail Security) with ESMTP id ABB8C430026 for ; Mon, 29 Jun 2009 13:13:53 +0300 (EEST) Received: from [130.230.52.50] (rotta.atm.tut.fi [130.230.52.50]) by mail.cc.tut.fi (Postfix) with ESMTP id A6230A4119 for ; Mon, 29 Jun 2009 13:13:53 +0300 (EEST) Message-ID: <4A4893E1.6000503@tut.fi> Date: Mon, 29 Jun 2009 13:13:53 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Institute of Communications Engineering User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: multipathtcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [multipathtcp] [T3-Rsrc Control] Multipath TCP use cases X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.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, 29 Jun 2009 10:13:36 -0000 Iljitsch van Beijnum wrote: > 1. Single packet request/response transactions (like the DNS) > 2. Multi-packet, but limited size transactions (like typical HTTP > transfers) > 3. Bulk transfers (FTP or HTTP transfer of large files) > 4. Low-bandwidth interactive traffic (such as Telnet) > 5. Low-bandwidth streaming (VoIP) > 6. High-bandwidth streaming (video) I would like to add for your consideration two more categories: * unattended bulk transfers with liveness and timeliness constraints such as BGP or IRC intra-server-connections, which last "forever", don't consume much bandwidth except during bursts but which can't be interrupted or they die and cause havoc multi-pathing could potentially be useful in preserving the connections during outages and attacks * unattended bulk transfers without constraints such as usenet news and MTA intra-server-connections these two example protocols can benefit from multiple concurrent single path connections along different paths tho, so maybe this isn't as good an example... Anyway, the common denominator for these examples is that they are connections that never finish, or seldom finish, and I couldn't justify combining them with any of the existing 6 categories to myself. One notable feature of these is that they are very likely to wrap around TCP sequence space, and some of the discussion surrounding some of the MP/TCP proposals has been centered on TCP sequence space tricks to appease "connection normalizers". -- Aleksi Suhonen From magnus.westerlund@ericsson.com Mon Jun 29 09:19: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 386AD3A6DD8 for ; Mon, 29 Jun 2009 09:19:18 -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 uvQ8Stqe8uIo for ; Mon, 29 Jun 2009 09:19:17 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A18CC3A6882 for ; Mon, 29 Jun 2009 09:19:12 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-d0-4a48e97931d4 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 54.49.21241.979E84A4; Mon, 29 Jun 2009 18:19:05 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 18:19:04 +0200 Received: from [153.88.52.33] ([153.88.52.33]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 18:19:03 +0200 Message-ID: <4A48E977.5080209@ericsson.com> Date: Mon, 29 Jun 2009 18:19:03 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: multipathtcp@ietf.org, Scott.Brim@gmail.com, Mark Handley X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Jun 2009 16:19:04.0265 (UTC) FILETIME=[51E7FB90:01C9F8D5] X-Brightmail-Tracker: AAAAAA== Subject: [multipathtcp] Regarding the 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: Mon, 29 Jun 2009 16:19:18 -0000 Hi, It appears that nobody sent a notice to this list about that BOF being approved. I am very sorry for that, but I have been on leave and are catching up. I thank Jari Arkko for being the champion for this BOF in my absence. We also have appointed Scott Brim (Scott.Brim@gmail.com) and Mark Handley (M.Handley@cs.ucl.ac.uk) as BOF chairs. Any questions, request for agenda time or suggestion for what the important questions can be sent to them. Using the mailing list to discuss what the open issues are encouraged. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------