From Dimitri.Papadimitriou@alcatel-lucent.be Sun Aug 2 01:19: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 C21DF3A67AD for ; Sun, 2 Aug 2009 01:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.408 X-Spam-Level: X-Spam-Status: No, score=-4.408 tagged_above=-999 required=5 tests=[AWL=1.841, 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 u6-zaUhD4TP8 for ; Sun, 2 Aug 2009 01:19:35 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 9A32A3A6ACB for ; Sun, 2 Aug 2009 01:19:31 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n728JUGM013859; Sun, 2 Aug 2009 10:19:31 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Aug 2009 10:19:30 +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: Sun, 2 Aug 2009 10:19:29 +0200 Message-ID: <00275A5B436CA441900CB10936742A3802B1C1DB@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090731084915.GV9935@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] On Thursday's Multipath TCP BOF Thread-Index: AcoRu9q60xzXRJ+MQ++t7z4ZBK7HNwAOUWRA References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com><00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> <20090731084915.GV9935@verdi> From: "PAPADIMITRIOU Dimitri" To: "John Leslie" X-OriginalArrivalTime: 02 Aug 2009 08:19:30.0721 (UTC) FILETIME=[F5951910:01CA1349] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 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: Sun, 02 Aug 2009 08:19:36 -0000 Hi,=20 > > 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 >=20 > 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=20 > are "obvious" > overlaps which implementors will probably find anyway). >=20 > 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. Concerning the second part of the last statement: On one hand, the proposed work items include "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."=20 On the other, the presentation of A.Ford states "It should appear as regular TCP to applications" (and indeed the stack depicted during the plenary show APP over single MPTCP running on top of multiple TCP) assuming thus the relationship between APP and Transport layer does not change Clarification would be appreciated on how APP could have better control over TCP with this proposal compared to the current situation. This said, at minimum resolution mechanism would be needed to determine the set of destination end-point/addresses "attached" to a given logical endpoint (MPTCP) as the proposed mechanism adds a level of indirection.=20 > > I have a couple of comments/concerns though: > >=20 > > - The BoF presentation considers that the TCP end-points controls > > routing of the traffic along a certain path in the network=20 > but routing > > information does not reach the end-points. >=20 > 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=20 > be saying something beyond that... To simplify, the forwarding table entry derived from the routing table determines the outgoing interface the packet will take towards the next-hop. The information that populates these routing tables does not reach the TCP end-points (hosts).=20 =20 > > So for what it concerns routing of the traffic, per TCP connection, > > there is no difference compared to the current situation=20 > (the network > > is not aware that two connections entering the network belong to the > > same "set"). >=20 > Agreed. "The network" is expected simply to forward packets. >=20 > > This assumption is to be revisited because the "possible"=20 > 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). >=20 > We specifically avoid any expectation that the network=20 > should enforce > diversity. We expect the network to make "best effort" forwarding > decisions: no more, no less. >=20 > > Note: The term "path" is from this perspective a bit confusing i.e. > > inverse multiplexed TCP or multi component TCP would probably better > > suite. >=20 > 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 difference is between the network location the packet is destined to (destination) and how it reaches that destination (i.e., the actual path as determined by a sequence of hops). If all nodes along the network path forward the packet to the same next-hop (because the two prefixes are spatially contiguous) the actual network paths won't be redundant. =20 =20 > > - The BoF presentation considers that controlling onto which > > (sub-)connection the source puts traffic leads to offload=20 > the network > > from performing traffic engineering. >=20 > 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=20 > traffic-engineering > needed, but if that claim proves false, nothing really changes. I just ask to make things clearer compared the way this topic was presented. If the way I read your answer is correct, I think we agree that ISP/operators still need to do their own TE (and there is no question of offload with this proposed technique). > > Thus, I do not see how this would lead to a situation where=20 > the network > > would be free from any traffic engineering ? >=20 > I don't believe we've claimed any such thing. The first presentation of the BoF refers to offloading network traffic engineering operations. Quoting that presentation "We now understand that multipath TCP, if done appropriately, can go a long way towards solving network-wide traffic engineering problems." > > (I would even say the contrary, this would lead us back to the > > hyper-aggregation problem). >=20 > I don't believe we've said much about that. There's a=20 > perhaps unstated > assumption that network operators may impose artificial delay=20 > or packet > loss in order to influence Multipath-TCP allocation between paths; and > we clearly believe that such "traffic-engineering" would be=20 > less harmful than some things they're doing today. >=20 > > - 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=20 > state would > > remain permanent since the connection between Address 1 and=20 > 2 would not > > be re-established. >=20 > Point well taken. However, it is not clear to me that we=20 > ever "detect > failure" rather than treating what the routing system considers to be > "failure" as, instead, "especially heavy congestion". Is your concern whether the routing system can differentiate between "topological" failures and heavy congestion events or not ? =20 > 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). The relationship to implicit and explicit congestion feedback from the network is a point that may require further refinement. It is my reading that only primal congestion control has been considered since so far in the MPTCP context. > > So, it may be that some of the decisions taken by the=20 > end-points become > > detrimental. At this stage, it is not clear how to prevent such > > situation would happen. >=20 > This does imply that we might need to consider different=20 > 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... I think more generally that reversion mechanisms may be considered when dealing with failovers techniques. Thanks, -d. =20 > -- > John Leslie > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 From gurtov@cs.helsinki.fi Sun Aug 2 22:30: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 25F3B3A6AB4 for ; Sun, 2 Aug 2009 22:30:19 -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 hGLT7cw1PqIw for ; Sun, 2 Aug 2009 22:30:17 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE7F3A69DF for ; Sun, 2 Aug 2009 22:30:01 -0700 (PDT) Received: from [88.192.47.114] (dsl-hkibrasgw3-ff2fc000-114.dhcp.inet.fi [88.192.47.114]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 03 Aug 2009 08:30:02 +0300 id 0008C0EE.4A7675DA.00002CF0 Message-ID: <4A7675A7.6090407@cs.helsinki.fi> Date: Mon, 03 Aug 2009 08:29:11 +0300 From: Andrei Gurtov User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "=?ISO-8859-1?Q?S=E9bastien_Barr=E9?=" 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: <4A72DD54.2000205@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Mon, 03 Aug 2009 05:30:19 -0000 > While HIP provides better security, it also comes with the cost of > having that high security. A fair statement, but if you use plain TCP you might be using the latest crypto security fixes from TCPM plus return routability checks to avoid redirection attacks, plus crypto address ownership checks so you would end up to something not very far from HIP. In terms of net neutrality debate at the last IETF, IPsec is a good way to avoid Deep packet inspection and other nasty tricks ISPs make. > 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. Shim6 might be better handling referrals, but it's v6 only and the current Internet is pretty much v4 still. A good thing for shim6 that it supports one-ended connections better than HIP. > 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. Yes, I think the best for the MPTCP WG would be to produce experimental multipath congestion control specs without specifying at which layer it's implemented. Andrei From c.raiciu@cs.ucl.ac.uk Mon Aug 3 07:33: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 0A80D28C16F for ; Mon, 3 Aug 2009 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 LgZkNwq2qX-j for ; Mon, 3 Aug 2009 07:33:31 -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 36C193A6E36 for ; Mon, 3 Aug 2009 07:33:31 -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 1MXyHN-000Jha-RK for multipathtcp@ietf.org; Mon, 03 Aug 2009 15:12:45 +0100 Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: <8D89A6E0-AA2B-4791-B789-63CFF8049F88@cs.ucl.ac.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: multipathtcp@ietf.org From: Costin Raiciu Date: Mon, 3 Aug 2009 15:33:30 +0100 X-Mailer: Apple Mail (2.753.1) Subject: [multipathtcp] Dealing with EBGP 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, 03 Aug 2009 14:33:32 -0000 Hi, I kept wondering if "default on" MPTCP does break unmodified eBGP. I need to ask the following questions, to get things straight in my head. Experts (like Iljistch) please step in :) 1. Does eBGP bind the local source address before making a connection? If so, we don't have a problem - in our current proposal MPTCP will not even attempt to setup multiple flows when the host locally binds a specific interface. 2. Are addresses used by the border routers "routable"? I assume they may well be, but they in fact don't need to. In the end, all you need for a next hop is some address of a neighboring router (even ethernet will do, and so will local ip addresses). If that were the case, then multipath TCP would simply fail to find multiple paths - unless there are redundant links between the same servers (this seems unlikely). Thanks, Costin From Scott.Brim@gmail.com Tue Aug 4 03:10:10 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 22EB928C202 for ; Tue, 4 Aug 2009 03:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_44=1, 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 K9uDNXRE1k4V for ; Tue, 4 Aug 2009 03:10:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3F6753A6F76 for ; Tue, 4 Aug 2009 03:10:07 -0700 (PDT) X-Files: meetingnotes.txt : 22971 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANeld0pAZnmf/2dsb2JhbAC9GocJgU4IjyiCNw0IgUwFgUo X-IronPort-AV: E=Sophos;i="4.43,320,1246838400"; d="txt'?scan'208";a="52808300" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Aug 2009 10:10:05 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n74AA5Dx014969 for ; Tue, 4 Aug 2009 06:10:05 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n74AA53L018958 for ; Tue, 4 Aug 2009 10:10:05 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); Tue, 4 Aug 2009 06:10:04 -0400 Received: from cisco.com ([10.86.251.75]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 06:10:04 -0400 Date: Tue, 4 Aug 2009 06:10:00 -0400 From: Scott Brim To: multipathtcp@ietf.org Message-ID: <20090804101000.GD49731@cisco.com> Mail-Followup-To: Scott Brim , multipathtcp@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 04 Aug 2009 10:10:04.0510 (UTC) FILETIME=[BC7477E0:01CA14EB] Authentication-Results: rtp-dkim-2; header.From=Scott.Brim@gmail.com; dkim=neutral Subject: [multipathtcp] draft meeting notes 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, 04 Aug 2009 10:10:10 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please review and fix the attached meeting notes. Scott --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="meetingnotes.txt" Multipath TCP BOF IETF75 30 July 2009 Chairs: Mark Handley, UCL; Scott Brim, Cisco Agenda: Introduction, Scope, Intention, Process (Scott Brim, 5 minutes) Goals and Background (Mark Handley, 25 minutes) 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, 30 minutes) WG Chartering Discussion (Led by Scott Brim, 30 minutes) Goals and Background (Mark Handley) ----------------------------------- Extensions to TCP to enable it to work over multiple simultaneous paths. TCP congestion control has done the job of keeping the Internet from collapsing, even though it has some problems. TCP CC does not make traffic go away, it just spreads it over longer period of time. MPTCP actually DOES make traffic go away over congested paths Today's demands for reliability are higher than can be delivered over concatenated paths across the Internet, and applications are much more demanding of network resources. Further, the Internet is unpredictable - failures, DDoS attacks, etc. - need to provide higher reliability for tomorrows' services. Redundancy mechanisms have historically been the method for offering robustness, such as routing failures, multihoming, traffic engineering, and increasingly traffic shaping (Via DPI). Wireless links (the vast majority of devices will be wireless), are also unpredictable. They do have multiple radios, though they cannot currently use these multiple radios to provide redundancy. Example Blackberry - seamless mobility across access technologies, 3G as backup/baseline interface, WiFi as primary when available MP Transport basic principle - stop hiding the multi-homing. Give all network downlinks addresses and make them available to the transport protocol. Congestion control works across multiple interfaces, not just on single interface. Example: Multi-home server. Client can connect to server over multiple paths if the server is multi-homed, but this is considered a single TCP connection. Congestion control mechanism is linked to both interfaces. Cannot do this with BGP multihoming. Link failure does not impact flow - as alternate path remains available. Example: Multi-home server + Legacy Client. Legacy client consumes resources on one of available links. MP TCP connection balances more traffic to alternate path to distribute traffic evenly. MP Transport goal is "resource pooling" - all network resources behave as single pooled resource, and shift load between various parts of network. Example: Multiple 12MB links appear and act as a single 36MB link. Resource pooling is not a new phenomenon - just being extended across multiple physical paths. The more MP clients are enabled, the more possible usage matrices exist, and therefore the better the distribution of traffic. Both clients and servers have different reasons for sending traffic over multiple paths at the same time - but both have the motivation. MP Transport protocols are key to making internet more robust/responsive. In addition, inherent redundancy and responses to unpredictable events are possible (which is not suitable for the underlying routing architecture). Belief that it is not terribly difficult to add multipath behavior to TCP. What about "over TCP" versus "in TCP"? Bittorrent is an example. You only fully get the congestion benefits if you link the response of one path to the congestion of the other path. Want to extend to ALL applications. SCTP? Already has the mechanism, just not implemented at the congestion control function. DCCP? demand? UDP? no single approach. MP-TCP has been proposed several times and shot down (apologies to Christian Huitema, who was original proposer) New understanding that MP-TCP can solve network-wide traffic engineering problems Q (Joe Touch): Three things we are dealing with: (1) TCP dealing with multiple paths. (2) striping. (3) multiple endpoints. Does the process of building this mechanism break "virtualization"? What if multiple addresses on the same interface. Need to ensure via "acid test" that everything running through single virtual interface - that MP-TCP, at worst, operates no worse than TCP today. Answer: Need to make sure we cover these three aspects without breaking virtualization - full agreement. To be covered, to some degree, in Alan's presentation Protocol Design (Alan Ford) --------------------------- Scope- To build TCP modifications to support multipath. Multiple implementations already available, but need to discuss details to solve Internet implementation criteria Usage - a stream of packets sent by source gets to destination. MP protocol determines which path each packet takes. Criteria - path discovery, sequence numbering, scheduling, SYN meanings, etc. Scenarios - most obvious - bulk client/server transfers. Short transactions (HTTP), P2P, interactive and streaming services. Determining where MP-TCP needs to be deployed differs based on scenario (especially with P2P and streaming) Compatibility - no worse than TCP over best path. Unaware boxes (including NATs) must see as standard TCP. Should also appear as standard TCP to applications (API compatibility) Scheduling - the key part of MP-TCP implementation, since determines how to distribute along multiple paths. Scheduler also responsible for retransmission (over same OR alternative path). Scheduling logic may be dependent on path properties (cost, for instance) Signaling - how to do? Chunking or as TCP options? Chunking is application layer, so TCP options is available and standardizes way to add info to TCP headers. Either way, signaling needs to be kept to minimum. Sequence space - 2 ways - single sequence space or data sequence space. Former sends each TCP segment on one of the paths. Latter has a clear distinction between path and data. Two proposals - "One Ended" and "Two Ended" One ended - multihomed host with provider-independent addressing. Only sender modified, and only one source/destination address - per-path congestion provided by SACK Two-ended - single TCP "subflow" begins, and additional subflows (new source/destination address pair) created, and merged under single identifier with existing flow(s) Doing signaling of additional addresses to other endpoint provides workarounds for NAT/firewalls. Also allows simultaneous IPv4/IPv6 use Subflows look like regular TCP with additional options. Data-level sequence number in TCP option. Each subflow operates as individual TCP session (SYN to FIN) Security - no worse than TCP today, and quite possibly a mechanism towards stronger security (opportunistic encryption), or other for binding sessions together. Two-ended solution must deal with same considerations as SHIM6 and mobility Q (Joe Touch): Endpoints start off with association based on a socket pair, then you can add more socket pairs for better performance. What happens if first socket pair shuts down due to ICMP errors? Answer - Good point. Current thinking that initial socket-pair stays connection identifier for entire MP-TCP session. Iljitsch van Beijnum: ICMP doesn't make TCP go away. Joe: "hard errors". Mark: Regardless, you don't have to send anything over a path that is not actually working even if keep state around. So the state of the initial pair will always anchor the association. Q: One or more Addresses, but what about port numbers? Answer - One or more port numbers. So, 2 address, 2 port numbers = 4 paths. But, you dont have to initiate all paths. Q (Dave Thaler): One-ended model. Multiple paths and multiple addresses not only single use-case. Can be single address with multiple gateways, as well. Answer - Agreement Question - Detailed technical work at this point already. Use-cases are less clear, corner cases. "I disable multiple interfaces because I dont want them both active" Answer - "would you say that you don't use both is because you can't keep session continuity via multipath?" Q (Dave Oran): What about extra complexity around PMTU? Answer - Good question - and no answer at present. Q: Address/Port pair corresponds to one path. How do you detect and test multiple paths via endpoint without knowing network topology? Can't detect shared bottleneck. Answer - Requires proper congestion control. Question - Thoughts regarding MPTCP over MPTCP (ie, VPNs)? Answer - Great thing to consider. No answer at present. Question - No notification to application risks a new application relying on a socket that is not there anymore. Answer - Not a concern since applications do not see. Q (Dave Craig): NAT bindings and connection re-use? A: MPTCP doesn't change addresses. Linked Congestion Control (Costin Raiciu) ----------------------------------------- Demonstration of Multipath TCP. 2 interfaces, both shaped to 10Mbps. Killed interfaces, re-enabled interfaces. Showed how bandwidth went down, up, re-discovery, etc. MPTCP - how do you allocate traffic to each path. Depends on goals: 1) Improve throughput over the best single path versus TCP 2) Any path should not be more aggressive than TCP (ie, take at most the same throughput) 3) Balance congestion away from bad links to good links. This implies resource pooling 1) Use independent CC on each path - problem= bottleneck fairness (ie, you get double the throughput of TCP) solution= couple the congestion controllers (see algorithm in slides). The aggregate flows will then behave like a single TCP flow BUT, fully coupled is "flappy" - flips between two extremes 2) Further modification for "linked algorithm" problem - "flappy" solution = change algorithm slightly to remove problem. (see change in algorithm in slides). Algorithm grows windows on each interface a the same rate. Windowing on one interface causes 50% of that interface load to move to the other interface. 3) Effect on RTT problem= equal window on both subflows if equal RTT and same droprates. If RTT on one interface grows, and droprates on both remain the same, then MP-TCP will be doing worse than standard TCP problem= RTT1TCP2 - windowing and throughput need to be above minimum throughput line of individual TCP connection solution= related to RTT (see slides), but results show that MP-TCP works in this scenario (improved performance, actually). Linked provided more fairness than uncoupled and coupled. Algorithm is simple, and working. But other solutions (less conservative) are possible. Q (jabber via Iljitsch): Clipping problem. With coupled windows, is there possibility that you need to decrease windows below zero Answer - no. Fully coupled algorithm has clipping problem, but linked algorithm never halves to something negative (not possible) Q: Operators will want to control sub-flow switching. Need to look at "Switching" issues - when you switch, how much you send over specific interface, etc. May need additional goal: "no worse than TCP in perturbation situations". Answer - No reply Q: what is a path? MPLS? A: source/destination pair. Q: so, you can only "fork" at source? Can't take advantage of additional paths in core. Answer - Not trying to address these cases as this time (i.e. how to signal to routing system). Iljitsch is interested in this question. Costin: MPTCP is first step; if routing system gave choice ... Iljitsch: discussions on mailing list about path selector to signal to routing system. List concluded not to do this now. Q (Gorry Fairhurst): RTT. Worried that RTT plays a part in this, when RTT varies significantly in access links. Is this something that can be addressed? Answer - the experiment changes RTT every ACK (very dynamic). This was taken into account, and Costin shows the graphs for comparison to standard TCP. Q: Technical comparisons were to two examples - uncoupled and fully coupled. Support standard TCP (weighted, statically) Answer - this would give bottleneck fairness but not resource pooling Q: Some resource pooling, but admittedly not as good as this. Answer - absolutely right. 2 types of resource pooling - (1) for single session at any time. (2) for many sessions at any time. Q (Remi Despre): Congratulations. This is the most innovative and promising idea in a long time. Decoupled TCP is a great solution. Q (Gorry Fairhurst): MTU? Answer - When applied to MTU in IPv6 with MTU 1280, should work immediately. Answer - you have to do MTU on each path. This would require changes to implementation stack Rethinking the transport layer (Janardhan Iyengar, Bryan Ford) -------------------------------------------------------------- Quite different - architectural perspective based on next-gen transport architecture presented in TSVArea at IETF75, Monday session (Tng draft) Transport layer defactored into four layers - Endpoint (naming, port numbers), Flow Regulation (performance concerns), Isolation (separates network functions from application functions, End-to-End security), Semantic (API-related functions, end-to-end reliability) Semantic Layer is where MP-TCP functionality fits. Semantic Layer would provide multipath capabilities. Semantic layer manages end-to-end state across flows, and bundles together for shared congestion control This cleanly separates functional units in MPTCP, and opens the exploration of new protocols in the multipath architecture Design implications - 1) No E2E ACK, just flow-level ACK but, middlebox ACK optimistically MPTCP cannot recover from failure after ACK and before successful transmission 2) Number of TCP flows multiplies quickly MP-TCP will consume port numbers very quickly, and increased state could be problematic. CC behavior gets erratic as number of synched TCP connections increase (SCTP or SST might provide a clue for how to resolve at Semantic Layer) Security - where does security belong? Proposal is TLS above TCP subflows (each subflow appears as TLS over TCP - advantage, since if any middlebox messes with TLS, MPTCP just drops path, and thus protecting MPTCP state) Q (Joe Touch): if propose TLS per flow, there may be TLS over TLS. Also what about TCPAO? TLS only protects data, not the TCP connection. Answer - agreement. Could use IPsec if desired. Q (Tim Shephard): TLS today checks certificates. Are we proposing to not check certs? Answer - applications can run TLS on top of semantic layer E2E security. Answer - we are not wedded to TLS (S/TLS/TCPAO mechanism). Concern is considering architectural implications of where you put security, and benefits of having security at this particular layer (between semantic and flow layer) Q (Andrew Yourtchenko): since TLS does not protect TCP, possibility of having single TLS above the multiplexed MPTCP flows. Answer - agree, but you lose the ability to crop single path. Separating compatibility requirements with TCP at API AND network layer has implications: SCTP is multi-home capable and can be used at Semantic layer with TCP subflows at Flow layer SST (Structured Scheme Transport) and SCTP has richer APIs DCCP is better at flow layer than MP TCP *This raises the question of the right evolution of protocols Architectural document should be part of the WG efforts - describe architecture, design choices, and how other protocols fit in this architecture Starting point should be MP-TCP design draft and Tng draft Chair comment: Decision on architecture document will be determined after determining if WG is created Technology Discussion ------------------- Question - at socket level, MPTCP is using same address family? Can this use 1 v4 stream and 1 v6 stream? But a socket is bound to address family, so would require change in API Answer - yes, everything so far has used same address family. Technically feasible to use multiple AFs in parallel. Is this a prudent thing to do? This may also be a way to for v4 to v6 transition Question - v4 and v6 - something to be aware of. Ports are part of the v4 address family in many proposals. Concern about port consumption. Would be great if additional ports wer enot needed. Answer - identifier is used for determining which subflows to bind to initial flow. Ports are actually only used for binding and used for rendezvous for initial connection. Answer from chair - there are great benefits to working through proposal in IETF to understand implications on the Internet. Q (Dino Farinacci): MP-TCP cannot choose path, it chooses exit interface from host. Network does destination routing. Example - site that is multi-homed to SP A and SP B, with unique address. A packet could take an exit that didn't match its source address, and get dropped due to uRPF. Very difficult to decide on source address without considering decisions on the routing side. Keeping it loosely coupled breaks MP-TCP. This questions usefulness of load-splitting this close to the host. You cannot load-split across converged network (ie, Internet). Clear distinction needs to be made that MP-TCP cannot choose paths, just interface, and the fate of the packet is tied to that decision. Having multiple IPs on the source is a very difficult problem to solve Answer - Need to be aware of how to get traffic out of link, and might require addtional methods. Answer - This is not a MPTCP problem, since that's a misconfigured network with or without MPTCP. Answer - The network/datacenter architecture would evolve differently if these capabilities existed. Q (Tim Shephard): In response to previous question/comment - there are ways to expose multiple paths in the network to the end systems. Cha Wei Yang's paper. Remi's preso in IntArea. Doesn't necessarily agree with Dino. Q (Tim Shephard): The most important thing here is congestion work. Don't get lost in the details. HIP/SHIM6 needs a multi-path TCP technology to be successful. Need to manage sets of addresses/locators. Need to manage security for those sets. Would be best to be compatible with HIP and SHIM6. Answer - SHIM6 folks involved in draft, so architectural consideration involved in using SHIM6 and MP-TCP together are being explored Scott: Have looked at HIP and SHIM6 and believe MPTCP has advantages in the area of address-pair liveness detection. Tim: probably agree. Iljitsch: could make one-ended on TCP and then use SHIM6. Answer from Chair - this should be discussed in a WG structure and decide which way to go forward. Feedback from community is best way. Question - Different view on relationship between MP-TCP and IPv4 and IPv6. Need to start to develop complete solution in IPv6. MP on IPv6 is very interesting as a solution to the routing problem is compelling. and can be designed very quickly. Answer - Agreement. From Tng architecture, the flow layer picked in initial prototype (existing TCP) is around maintaining compatibility with legacy interface. With IPv6, there is opportunity to not have to deal with compatibility problems and design limitations (port numbers) of legacy TCP. Point is - only in v4 case is it necessary to be compatible with existing infrastructure. In v6, more feasible to consider MP-TCP default operation use different flow layer (ie, DCCP) Answer from chair - need to work in IPv4 and IPv6. Thats intent of work Question - aren't mobility, multi-homing, etc already clearly differentiated in charter of what we are doing? Answer - next topic of conversation - WG charter Question - please send out mail as to why port problems are alleviated in v6 issue Answer - v6 assumption that no v6 port address translation Question - port selection and concerns are a function of the transport protocol selection Question - ports in v4 and v6 - no port NAT on the path. Not that we don't need or shouldn't have - just don't. IPv6 NAT will not share addresses, versus v4 where you share a single address. Answer from chair - NAT will be moved to mailing list conversation WG Charter Discussion ------------------- Q (Gabriel Montenegro): Is it well-defined? Still questions on v4 or v4/v6? Answer - intent is both Question - Vote for WG charter Q (Joe Touch): set of problems is reasonably well defined and would like it expressed that way. Hesitant to create WG, but if LISP is a WG, this should be a WG. Should go to experimental, and if well-received, move back to proposed. Experimental frees people outside of the IETF process Answer - avoided presenting proposal, so this would not be design-by-committee. Need for WG is to help nail all questions/details. Question - support of working group and load-sharing across Internet is important subject, and MP-TCP interesting by simplicity. If group does not exclude pure IPv6 solution before v4/v6 solution is useful. Experimental or proposed standard? Possible for WG to be open to either? Q (Pete Resnick): as applications guy, this is "delightful" and addresses a host of issues that Apps have dealt with forever. Apps would like to see charter Question - application feedback 2nd'd. Question for audience - create WG? Handraise suggested overwhelming (vast majority) for formation of working group. No objections. Charter is next step. Target September. Question for audience - experimental or proposed? Answer - experimental to proposed migration is easy if design works. experimental is easier to work from WG perspective. Good argument from group needed to go to proposed standard Q (Joe Touch): charter should call out separation of work or building a sequence of steps that add value independently, and integrated into single document at the end. This might simplify things. Would like to see ability to switch to a different IP address separated out. Answer - point taken and detailed look as to whether this is possible. More work here. Question - Does MPTCP assume multiple interfaces? Answer - no. Question - Note re: overlap with MIF Answer - noted. Assumption that output of MIF influences and directs MP WG --sm4nu43k4a2Rpi4c-- From iljitsch@muada.com Tue Aug 4 04:16: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 DF2443A6FCB for ; Tue, 4 Aug 2009 04:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 kpPnI+lAf4dc for ; Tue, 4 Aug 2009 04:16:36 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id E91B03A69BE for ; Tue, 4 Aug 2009 04:16:35 -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 n74BG7C6041338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 13:16:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <69944CB0-62B7-4689-B004-68C6EF269A77@muada.com> From: Iljitsch van Beijnum To: Costin Raiciu In-Reply-To: <8D89A6E0-AA2B-4791-B789-63CFF8049F88@cs.ucl.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: Tue, 4 Aug 2009 13:16:24 +0200 References: <8D89A6E0-AA2B-4791-B789-63CFF8049F88@cs.ucl.ac.uk> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Dealing with EBGP 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, 04 Aug 2009 11:16:37 -0000 On 3 aug 2009, at 16:33, Costin Raiciu wrote: > I kept wondering if "default on" MPTCP does break unmodified eBGP. Don't worry about it. There is no real overlap between boxes running BGP and boxes that would benefit from MPTCP. Especially if we provide an opt-out API call then software BGP implementations will use this quickly and there shouldn't be any problems even if people run BGP on boxes that enable MPBGP by default. > 1. Does eBGP bind the local source address before making a connection? Yes, it usually does. > If so, we don't have a problem - in our current proposal MPTCP will > not even attempt to setup multiple flows > when the host locally binds a specific interface. Strange. > 2. Are addresses used by the border routers "routable"? What is "routable"? From iljitsch@muada.com Tue Aug 4 04:52: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 0753628C394 for ; Tue, 4 Aug 2009 04:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 iwLk35HOrAo9 for ; Tue, 4 Aug 2009 04:52:36 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 0006828C395 for ; Tue, 4 Aug 2009 04:52:35 -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 n74Bq7cu041655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 13:52:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <868B6924-2BF6-47A8-8606-099D39354F18@muada.com> From: Iljitsch van Beijnum To: Costin Raiciu In-Reply-To: <2A70142E-1810-4D6F-ACD3-9ED3600E1C96@cs.ucl.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: Tue, 4 Aug 2009 13:52:24 +0200 References: <8D89A6E0-AA2B-4791-B789-63CFF8049F88@cs.ucl.ac.uk> <69944CB0-62B7-4689-B004-68C6EF269A77@muada.com> <2A70142E-1810-4D6F-ACD3-9ED3600E1C96@cs.ucl.ac.uk> X-Mailer: Apple Mail (2.935.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Dealing with EBGP 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, 04 Aug 2009 11:52:37 -0000 On 4 aug 2009, at 13:30, Costin Raiciu wrote: >> Especially if we provide an opt-out API call then software BGP >> implementations will use this quickly and there shouldn't be any >> problems even if people run BGP on boxes that enable MPBGP by >> default. > Sure, but that requires changes to BGP implementations. The big win > is if we can deploy it now and get only benefits, without breaking > any important apps. Right, but in the BGP case I would expect people to simply turn off MPTCP for the whole box. >>> 2. Are addresses used by the border routers "routable"? >> What is "routable"? > As in can I ping a border router from my machine? Does it have a > public address? Yes, the addresses are as good as always public and usually pingable, although if you're paranoid you may want to restrict incoming ping packets etc towards your router's addresses. From iljitsch@muada.com Tue Aug 4 05:46: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 DD0FF3A6B18 for ; Tue, 4 Aug 2009 05:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.302 X-Spam-Level: X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 TWIMghq7XTfw for ; Tue, 4 Aug 2009 05:46:18 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id C5D663A68B0 for ; Tue, 4 Aug 2009 05:46:17 -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 n74CjuAM041938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 14:45:56 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Joe Touch In-Reply-To: <4A72B653.2070505@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: Tue, 4 Aug 2009 14:46:12 +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) Cc: Multipath TCP Mailing List Subject: [multipathtcp] MP captain going down with the address ship, 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: Tue, 04 Aug 2009 12:46:18 -0000 On 31 jul 2009, at 11:16, Joe Touch wrote: > IMO, if an app decides to use multipath explicitly, it might as well > have used SCTP. SCTP in its current form does multiaddressing but not multiple paths at the same time or even smart path selection. > 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. We need a list of such applications. > - 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. This is a narrower case than what we discussed after the session last week. Let's list some options: 1. The host has an address and the other host can reach it 2. The host has an address that is reachable for other hosts, but not the one involved in the MPTCP session 3. The host has an address, but it's unreachable 4. The host had and address, and can reasonably expect nobody else to have it now 5. The host had an address, and it may now be held by another host I think we can all agree that we can do MPTCP in case 1. In case 5, we should obviously explicitly and completely remove the address from any MPTCP sessions. Possibly to the degree that if that's not possible, we kill the session. But what about the cases in the middle? In my opionion, 2 is also still completely ok, and 3 may or may not be depending on the address configuration details. As for 4, if I have an interface identifier with the u/l bit set to universal, and probably also in the case of a CGA/HBA iid, I can reasonably expect that nobody else is going to use an address built from that iid on a subnet I was attached to, especially if this is a subnet I expect to be attached to again in the near future. > Opt-in is the only viable solution if the semantics are changed. I say: if we make this experimental for at least 2 years during which we tell application makers to use an opt out API after those 2 years we can reasonably turn on MPTCP by default. From c.raiciu@cs.ucl.ac.uk Tue Aug 4 06:50: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 EDC9728C3D5 for ; Tue, 4 Aug 2009 06:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 gXaA3uZJRORN for ; Tue, 4 Aug 2009 06:50:44 -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 DA38528C3E9 for ; Tue, 4 Aug 2009 06:50:43 -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 1MYHtc-000Jrp-7J; Tue, 04 Aug 2009 12:09:32 +0100 In-Reply-To: <69944CB0-62B7-4689-B004-68C6EF269A77@muada.com> References: <8D89A6E0-AA2B-4791-B789-63CFF8049F88@cs.ucl.ac.uk> <69944CB0-62B7-4689-B004-68C6EF269A77@muada.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A70142E-1810-4D6F-ACD3-9ED3600E1C96@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Tue, 4 Aug 2009 12:30:44 +0100 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Dealing with EBGP 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, 04 Aug 2009 13:50:45 -0000 On 4 Aug 2009, at 12:16, Iljitsch van Beijnum wrote: > On 3 aug 2009, at 16:33, Costin Raiciu wrote: > >> I kept wondering if "default on" MPTCP does break unmodified eBGP. > > Don't worry about it. There is no real overlap between boxes > running BGP and boxes that would benefit from MPTCP. I agree with that, it doesn't make sense to implement mptcp on IOS. However, if the router is running on Linux (there are a few out there that use XORP or Quagga or something else, I imagine), > > Especially if we provide an opt-out API call then software BGP > implementations will use this quickly and there shouldn't be any > problems even if people run BGP on boxes that enable MPBGP by default. Sure, but that requires changes to BGP implementations. The big win is if we can deploy it now and get only benefits, without breaking any important apps. > >> 1. Does eBGP bind the local source address before making a >> connection? > > Yes, it usually does. > >> If so, we don't have a problem - in our current proposal MPTCP >> will not even attempt to setup multiple flows >> when the host locally binds a specific interface. > > Strange. Arguable. If an application only wants to accept connections destined for ip a, why should we advertise ip B to the other end. However, if the app binds INADDR_ANY, it seems natural it doesn't care and therefore we could use all addresses. > >> 2. Are addresses used by the border routers "routable"? > > What is "routable"? As in can I ping a border router from my machine? Does it have a public address? From scott.brim@gmail.com Tue Aug 4 06:59: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 8951228C2EA for ; Tue, 4 Aug 2009 06:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 fEh9Rm323GKr for ; Tue, 4 Aug 2009 06:59:41 -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 CA89F28C40B for ; Tue, 4 Aug 2009 06:59:29 -0700 (PDT) Received: by qyk41 with SMTP id 41so5019486qyk.29 for ; Tue, 04 Aug 2009 06:59:12 -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=meL6yAHmThtQcWB031OMbdTxR9NN6vZ4ojU7dEw5ZBI=; b=WHG3x/ten9bl5ovdQx4Wa7BARuogMtsABwoRx7tTOTJfYe3qh4YkG+VQ/cQx2bDw3b Bb1YIT7OitlohQwTBTcEARkKpMzQ0xC73ye4Aez3eXVrcrzQD3ZqBNRwU0jw06b+jrP2 17ui/uEPauxmcU5BuxY9M09fYLV82R5Xe3flY= 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=VNFKlQ8vGYpHs8EzZKshCcUsVgtHOTTjOP3ji8/lfb3znyimFHyJ+kceMBell6UdB2 t+fOqcDrDMECO0SKOcVV7br+pYJkWCOfsPpKP5WJ2RI4BQkCbej/Plsj4xiWbLYxOikY 0vo6m1lwXailGvzO+dvY5M8xRkwtQtkwkexZE= Received: by 10.224.53.198 with SMTP id n6mr5870678qag.187.1249394351951; Tue, 04 Aug 2009 06:59:11 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 8sm15154457qwj.46.2009.08.04.06.59.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 06:59:11 -0700 (PDT) Message-ID: <4A783EAC.6080704@gmail.com> Date: Tue, 04 Aug 2009 09:59:08 -0400 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: Lars Eggert References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> <4A7222DD.20401@gmail.com> <86C99C25-93E9-4D21-9C2C-27BBB69DDAC0@nokia.com> In-Reply-To: <86C99C25-93E9-4D21-9C2C-27BBB69DDAC0@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Tue, 04 Aug 2009 13:59:42 -0000 Lars: The point of a flow label is to allow better flow identification for packet handling, both at intermediate points and endpoints. Labeling is up to the endpoints, and there can be multiple "flows" (as defined by flow label) based on a single "connection" (as defined by state shared by the endpoints). So a "flow" could include all packets supported by a connection, or a subset of them. IMHO endpoints MAY use the same flow label on different flows (aka subflows) taking different paths. If those paths merged at some point the flows might be treated as one. This is true with or without multipath transport. Scott Lars Eggert allegedly wrote on 07/31/2009 02:38 EDT: > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From touch@ISI.EDU Tue Aug 4 07:03: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 0DD2F28C3F9 for ; Tue, 4 Aug 2009 07:03:27 -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 5SLnbn4tKbpK for ; Tue, 4 Aug 2009 07:03:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E6BE228C407 for ; Tue, 4 Aug 2009 07:03:25 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n74E2AKR028538; Tue, 4 Aug 2009 07:02:11 -0700 (PDT) Message-ID: <4A783F60.8070406@isi.edu> Date: Tue, 04 Aug 2009 07:02:08 -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> <4A72B653.2070505@isi.edu> 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] MP captain going down with the address ship, 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: Tue, 04 Aug 2009 14:03:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: > On 31 jul 2009, at 11:16, Joe Touch wrote: > >> IMO, if an app decides to use multipath explicitly, it might as well >> have used SCTP. > > SCTP in its current form does multiaddressing but not multiple paths at > the same time or even smart path selection. > >> 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. > > We need a list of such applications. Sure. Provide me a list of all applications that use TCP, and I can help try to figure out which ones are affected ;-) Start with: - apps that bind to a specific local address - apps that look at the address they bind to after they connect - apps that use addresses for validation (e.g., that refer to X.509 certificates, that use the DNS lookup of the address, or that use addresses for access control directly) The overall problem is that this proposal is creating a new concept - that a group of addresses are bound together - and assuming we can make this meaningful to applications that use TCP. My key concern here is that changing the semantics of the API is much more difficult to diagnose and easy to blame on other things (e.g., insufficient permissions). See further below... >> - 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. > > This is a narrower case than what we discussed after the session last > week. Let's list some options: > > 1. The host has an address and the other host can reach it > 2. The host has an address that is reachable for other hosts, but not > the one involved in the MPTCP session > 3. The host has an address, but it's unreachable > 4. The host had and address, and can reasonably expect nobody else to > have it now > 5. The host had an address, and it may now be held by another host > > I think we can all agree that we can do MPTCP in case 1. In case 5, we > should obviously explicitly and completely remove the address from any > MPTCP sessions. Possibly to the degree that if that's not possible, we > kill the session. Well, AFAICT, that kills most of the use cases I've seen described. > But what about the cases in the middle? We'd need to understand whether those cases are: a) variants of the last case - i.e., if you have an address that's not reachable, that may be what YOU see, but it needs to be what the OTHER END sees as well. b) testable (or even knowable) > In my opionion, 2 is also still completely ok, and 3 may or may not be > depending on the address configuration details. > > As for 4, if I have an interface identifier with the u/l bit set to > universal, and probably also in the case of a CGA/HBA iid, I can > reasonably expect that nobody else is going to use an address built from > that iid on a subnet I was attached to, especially if this is a subnet I > expect to be attached to again in the near future. > >> Opt-in is the only viable solution if the semantics are changed. > > I say: if we make this experimental for at least 2 years during which we > tell application makers to use an opt out API after those 2 years we can > reasonably turn on MPTCP by default. I'm not trying to prevent going to experimental with this, FWIW. I'm trying to understand whether there's an objective criteria for knowing whether we can go to standards track. There are other cases of experimental protocols being deployed that nobody knew whether they were OK or just that nobody knew what to look for or who to complain to, but that has not been seen as sufficient evidence to make them standards track (e.g., in Linux congestion control). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp4P2AACgkQE5f5cImnZrs0JgCeKGkTgRMxkLax2XVLhlXEfuIH E1wAoLquLadrKKsPuFK95u3tuHh5Y3Gm =5WhD -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Aug 4 07:06: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 75FE428C40A for ; Tue, 4 Aug 2009 07:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 0Vr3Y7lEknyh for ; Tue, 4 Aug 2009 07:06:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9EEF528C403 for ; Tue, 4 Aug 2009 07:06:08 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n74E55hj029659; Tue, 4 Aug 2009 07:05:07 -0700 (PDT) Message-ID: <4A784010.4010403@isi.edu> Date: Tue, 04 Aug 2009 07:05:04 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Costin Raiciu References: <8D89A6E0-AA2B-4791-B789-63CFF8049F88@cs.ucl.ac.uk> <69944CB0-62B7-4689-B004-68C6EF269A77@muada.com> <2A70142E-1810-4D6F-ACD3-9ED3600E1C96@cs.ucl.ac.uk> In-Reply-To: <2A70142E-1810-4D6F-ACD3-9ED3600E1C96@cs.ucl.ac.uk> 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: multipathtcp@ietf.org Subject: Re: [multipathtcp] Dealing with EBGP 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, 04 Aug 2009 14:06:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Costin Raiciu wrote: >... >>> If so, we don't have a problem - in our current proposal MPTCP will >>> not even attempt to setup multiple flows >>> when the host locally binds a specific interface. >> >> Strange. > > Arguable. If an application only wants to accept connections destined > for ip a, why should we advertise ip B to the other end. However, if the > app binds INADDR_ANY, it seems natural it doesn't care and therefore we > could use all addresses. The app would need to: a) use wildcard addresses in its API (INADDR_ANY) b) never use the local endpoint used (i.e., never look at the socket's actual addresses) This goes for whichever end of the connection it assumes can have multiple addresses - local or remote. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp4QBAACgkQE5f5cImnZrtadACfRaerhViVBB5r+ZzNybZcNgCL LKIAoPIepwZG6XzT6ttxcRjIzacKRBTr =tKJ4 -----END PGP SIGNATURE----- From alan.ford@roke.co.uk Tue Aug 4 11:25: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 B3CE93A68C9 for ; Tue, 4 Aug 2009 11:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.884 X-Spam-Level: X-Spam-Status: No, score=-4.884 tagged_above=-999 required=5 tests=[AWL=-1.285, 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 W2QWzbmeKGrz for ; Tue, 4 Aug 2009 11:25:56 -0700 (PDT) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id EDEBD3A6858 for ; Tue, 4 Aug 2009 11:25:55 -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 n74IPpsG032462; Tue, 4 Aug 2009 19:25:51 +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: Tue, 4 Aug 2009 19:25:50 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680830AF40@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <4A72B653.2070505@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] On Thursday's Multipath TCP BOF Thread-Index: AcoRv5h76a9jazHiSc2pIzVe5js/PQDVDgng 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> From: "Ford, Alan" To: "Joe Touch" X-roke-co-uk-MailScanner-ID: n74IPpsG032462 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: 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: Tue, 04 Aug 2009 18:25:57 -0000 Hi, > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On > Behalf Of Joe Touch > Sent: 31 July 2009 10:16 > To: Iljitsch van Beijnum > Cc: Multipath TCP Mailing List > Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF [snip] > 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. >=20 > The implications if this would be: >=20 > - assume multipath TCP opens connections using a primary > (initial) socket pair >=20 > - as long as that socketpair is available*, the connection > stays up; when not, the connection is torn down >=20 > * =3D where "available" could mean just that both sides still think = that > the IP address is bound to one of their interfaces. >=20 > I.e., you REALLY do not want the following case: >=20 >=20 > A: adr 11, adr 12 > B: adr 23, adr 24 >=20 > 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 >=20 > A ifconfig's adr 11 down >=20 > C ifconfig's adr 11 up >=20 > Now what? The problem here is if an application on A thinks A/11 is its address, then signals this to B, then B tries to connect to C/11 to send it something else. I can't think of any other cases where this would cause a problem offhand. For this to be a problem, this assumes that something is listening on the given port on C/11 and the application has no handshake built in. Sounds quite unlikely, but not infeasible. Do you know of any applications that behave like that? (If nothing was listening, the application would get a TCP RST or ICMP port unreachable, depending on protocol, which would be the correct behaviour). An alternative may be for B to maintain a mapping of adr11 to alternative addresses on A until any sessions that had this as their initial subflow have closed. This would effectively be moving knowledge of paths outside of individual connections, however - something I've been so far keen to avoid, since I fear that may be an jumbo-sized can of worms! > 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. Ah, but what are "A" and "B" in this case? You use them as nodes in the text above, and as such "A-B" would not lose its connection in single TCP if A/12 -> B/24 was being used, only if A/11->B/23 was being used. In MPTCP, both pairs are being used, and it seems semantically consistent to say the connection would not be lost unless there are no paths in use between A and B. As Lars says in a later reply, this is intended to be Experimental. We do not yet know if there are applications that will be harmed by this - during the development of this work we will find this out! Regards, Alan From alan.ford@roke.co.uk Tue Aug 4 11: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 633543A68C9 for ; Tue, 4 Aug 2009 11:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.456 X-Spam-Level: X-Spam-Status: No, score=-4.456 tagged_above=-999 required=5 tests=[AWL=-0.857, 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 bF+nQZhjk0WV for ; Tue, 4 Aug 2009 11:25:59 -0700 (PDT) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id 387733A6895 for ; Tue, 4 Aug 2009 11:25:59 -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 n74IPnEo004339; Tue, 4 Aug 2009 19:25:49 +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: Tue, 4 Aug 2009 19:25:48 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680830AF3F@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <86C99C25-93E9-4D21-9C2C-27BBB69DDAC0@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] On Thursday's Multipath TCP BOF Thread-Index: AcoRqY+N481nguqDRfu22KTorpcnwADaJJ7Q References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com><7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com><4A7222DD.20401@gmail.com> <86C99C25-93E9-4D21-9C2C-27BBB69DDAC0@nokia.com> From: "Ford, Alan" To: "Lars Eggert" , "Brian E Carpenter" 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: 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: Tue, 04 Aug 2009 18:26:00 -0000 Hi, > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On > Behalf Of Lars Eggert > Sent: 31 July 2009 07:38 > To: Brian E Carpenter > Cc: Multipath TCP Mailing List > Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF >=20 > Hi, >=20 > 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. >=20 > RFC3697 actually says in the introduction: >=20 > 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. >=20 > The first sentence seems to imply that the packets of different > subflows may carry different flow labels. >=20 > The second sentence is the issue. It is true for unipath/uniflow > transport protocols, but not multipath transport protocols. >=20 > The third sentence I don't understand :-) Yes, it's an odd one. I imagine the intention (Brian?) was to permit multiple flows per transport connection. However, as written it would also permit a single flow across multiple transport connections. (Of course, we then get onto the definition of a "transport connection" - is it a MPTCP connection or a TCP subflow?). > 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. I can agree with that reading, however now would probably be a good time to sort out clarifying this :) My initial feeling on this was that we should exploit the flow label as an static-per-connection identifier for a MPTCP connection. However, it's not clear if that would bring any benefits. For example, as the source sets the flow label, this means that a flow can be identified by a tuple of (source_addr, flow_label) - but the source address can be different in MPTCP, so middleboxes that may have gained benefit from such an identifier (e.g. load balancers) will still not be able to determine anything from the flow label. Furthermore, such a rule just goes against what I wrote above regarding the non-1:1 mapping, since it would no longer permit multiple flows per transport connection. Yes, definitely one for the clarifications list :) Regards, Alan From alan.ford@roke.co.uk Tue Aug 4 11:27: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 0AD2C3A6949 for ; Tue, 4 Aug 2009 11:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.242 X-Spam-Level: X-Spam-Status: No, score=-4.242 tagged_above=-999 required=5 tests=[AWL=-0.643, 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 jbkaFSlcriyQ for ; Tue, 4 Aug 2009 11:27:43 -0700 (PDT) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id CFA4A3A6858 for ; Tue, 4 Aug 2009 11:27:42 -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 n74IPm5n004330; Tue, 4 Aug 2009 19:25:48 +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: Tue, 4 Aug 2009 19:25:46 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680830AF3E@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <00275A5B436CA441900CB10936742A3802B1C1DB@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] On Thursday's Multipath TCP BOF Thread-Index: AcoRu9q60xzXRJ+MQ++t7z4ZBK7HNwAOUWRAAMMnxEA= References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com><00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com><20090731084915.GV9935@verdi> <00275A5B436CA441900CB10936742A3802B1C1DB@FRVELSMBS22.ad2.ad.alcatel.com> From: "Ford, Alan" To: "PAPADIMITRIOU Dimitri" 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: 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: Tue, 04 Aug 2009 18:27:44 -0000 Hi, > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On > Behalf Of PAPADIMITRIOU Dimitri > Sent: 02 August 2009 09:19 > To: John Leslie > Cc: Multipath TCP Mailing List > Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF >=20 > Hi, >=20 > > > 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. >=20 > Concerning the second part of the last statement: >=20 > On one hand, the proposed work items include "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." >=20 > On the other, the presentation of A.Ford states "It should appear as > regular TCP to applications" (and indeed the stack depicted during the > plenary show APP over single MPTCP running on top of multiple TCP) > assuming thus the relationship between APP and Transport layer does not > change >=20 > Clarification would be appreciated on how APP could have better control > over TCP with this proposal compared to the current situation. Typically, an application (that is either a legacy, MPTCP-unaware app, or an app that has chosen to be MPTCP-agnostic) will be provided with a multipath TCP connection automatically, but is (If it has elected to exercise some control itself, such as binding to an interface, it makes sense for this to take precedence, however). An extended MPTCP API would allow an application to find out more about, for example, how many paths are in use, and which interfaces they are between. The kind of control it may wish to exercise could be to express a preference such as "this is going to be a long-lived but very low-bandwidth connection, so please only use MPTCP for backup purposes". There could also (potentially) be prioritisation information, which could be mapped to local policy - this is all TBD however! This is only how we see it at the moment, however - further development will indicate how best to approach this. > This said, at minimum resolution mechanism would be needed to determine > the set of destination end-point/addresses "attached" to a given logical > endpoint (MPTCP) as the proposed mechanism adds a level of indirection. [snip] > > > 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". >=20 > The difference is between the network location the packet is destined to > (destination) and how it reaches that destination (i.e., the actual path > as determined by a sequence of hops). If all nodes along the network > path forward the packet to the same next-hop (because the two prefixes > are spatially contiguous) the actual network paths won't be redundant. True, however I don't think that goes against John's description, "TCP that can run over multiple simultaneous paths" (note "can" :) ). Regards, Alan From brian.e.carpenter@gmail.com Tue Aug 4 14:55: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 B645C3A6DE3 for ; Tue, 4 Aug 2009 14:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 rk9jhQFInEO5 for ; Tue, 4 Aug 2009 14:55:28 -0700 (PDT) Received: from mail-pz0-f178.google.com (mail-pz0-f178.google.com [209.85.222.178]) by core3.amsl.com (Postfix) with ESMTP id C922C28C35E for ; Tue, 4 Aug 2009 14:55:28 -0700 (PDT) Received: by pzk8 with SMTP id 8so2949984pzk.31 for ; Tue, 04 Aug 2009 14:55:30 -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=GauquZbqObOv3N+2DOiAWRMLVHdpKaLXPr5Ok7lccE4=; b=I/qJDV8tZU4TNAN3x8JUJiD+1obrAgwom8QtMieleC3vhJzPbcbAWWGmH1QztZcZWC /769MJ2h1GvHJhh7oCvEzziRzzfX7oTBjFwR9htQHaw+5P2Tjmrycf2JGKpZwWmpNsD4 uFHvMKyeO3DrRAWDmOEhLyf/cgGooJ9eiSmkY= 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=iKTtm28eyf8jKIDU6/4KnnSXbXQzFcL4y+OAsuiSQ0XO6p7Nzm7zEHFDhoJdgjDprv rf9kaDeGc4jarHTuiAdPqqq7kEwa0a4u9wkU4kJ4GstyO7Q5riPn7FBOit2UQmiwEjBM dCXhrxWaBqFV6V/BiGxdhQxSEBcfFOEqbg22U= Received: by 10.141.41.18 with SMTP id t18mr5649358rvj.264.1249422929993; Tue, 04 Aug 2009 14:55:29 -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 k41sm4624330rvb.47.2009.08.04.14.55.28 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 14:55:29 -0700 (PDT) Message-ID: <4A78AE4E.30406@gmail.com> Date: Wed, 05 Aug 2009 09:55:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Ford, Alan" References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com><7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com><4A7222DD.20401@gmail.com> <86C99C25-93E9-4D21-9C2C-27BBB69DDAC0@nokia.com> <2181C5F19DD0254692452BFF3EAF1D680830AF3F@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680830AF3F@rsys005a.comm.ad.roke.co.uk> 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: Tue, 04 Aug 2009 21:55:29 -0000 On 2009-08-05 06:25, Ford, Alan wrote: ... >> 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 third sentence I don't understand :-) > > Yes, it's an odd one. I imagine the intention (Brian?) was to permit > multiple flows per transport connection. However, as written it would > also permit a single flow across multiple transport connections. (Of > course, we then get onto the definition of a "transport connection" - is > it a MPTCP connection or a TCP subflow?). I would have to trawl the archive to be sure, but I suspect I wrote that sentence and that the intention was to allow use cases where multiple microflows (for example, all the TCP sessions between a particular pair of application instances, or all the RTSP streams between them) were given the same label. Or even, all the flows between two hosts that happen to use the same diffserv DSCP are given the same label. To put it another way: a flow between A and B is whatever set of packets A chooses to label as a single flow, with no enforced mapping to the transport layer. However, we just didn't think about the case where A is sending to B using more than one address pair. >> 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. Actually the intent of 3697 was, I think, to be neutral on that point. It could be interpreted either way, or both ways simultaneously. What was clear was the the flow label was not in any shape or form an explicit routing tag like the MPLS label. > > I can agree with that reading, however now would probably be a good time > to sort out clarifying this :) > > My initial feeling on this was that we should exploit the flow label as > an static-per-connection identifier for a MPTCP connection. However, > it's not clear if that would bring any benefits. For example, as the > source sets the flow label, this means that a flow can be identified by > a tuple of (source_addr, flow_label) - but the source address can be > different in MPTCP, so middleboxes that may have gained benefit from > such an identifier (e.g. load balancers) will still not be able to > determine anything from the flow label. Furthermore, such a rule just > goes against what I wrote above regarding the non-1:1 mapping, since it > would no longer permit multiple flows per transport connection. Exactly. And remember that the flow label has no useful security properties, and can be forged trivially. Brian From brian.e.carpenter@gmail.com Tue Aug 4 15:02: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 176433A70D7 for ; Tue, 4 Aug 2009 15:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 VeRBEs1RxLZB for ; Tue, 4 Aug 2009 15:02:26 -0700 (PDT) Received: from mail-pz0-f192.google.com (mail-pz0-f192.google.com [209.85.222.192]) by core3.amsl.com (Postfix) with ESMTP id 339DB3A69ED for ; Tue, 4 Aug 2009 15:02:26 -0700 (PDT) Received: by pzk30 with SMTP id 30so3267873pzk.5 for ; Tue, 04 Aug 2009 15:02:27 -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=JUfQujx4yW9bNAKtQGNO9fkLQa5VNhY6wvO9nT68Y+E=; b=kzpjj2ksDFszRy+oHwvFj7ijS6IaBcnNoMX/C9xLqMEsSkwPw/fiJ/3GFVUC/uIfaE FMcYmS/HaLLgCZTlr1qKD5iuAC2HQojOmtsxNorc7Rli/eZskL03PjFA+H0dlPMgWv2t uh74Mt+II6JJQareHNQl7m/HFZ/FVn0TP1HR4= 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=wappimKZ1ZKXb8NQNDkoLT/C//O1GZs3KDecJbVXvJghxjsYUHqHfx4Aik+nYLGAPy sHzG74Z4IBFiHpIM8uMCJCzGecEZYMWHSNGXj6/71f6DmoofZucNpNo8VFUpnjCixyDM VWG+mQS6NVzWOe9Kfts9cOOUHNbJvN/5X3U6k= Received: by 10.141.14.2 with SMTP id r2mr3755212rvi.167.1249423347008; Tue, 04 Aug 2009 15:02:27 -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 c20sm4320270rvf.21.2009.08.04.15.02.24 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 15:02:26 -0700 (PDT) Message-ID: <4A78AFEE.5000508@gmail.com> Date: Wed, 05 Aug 2009 10:02:22 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott Brim References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> <4A7222DD.20401@gmail.com> <86C99C25-93E9-4D21-9C2C-27BBB69DDAC0@nokia.com> <4A783EAC.6080704@gmail.com> In-Reply-To: <4A783EAC.6080704@gmail.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: Tue, 04 Aug 2009 22:02:27 -0000 On 2009-08-05 01:59, Scott Brim wrote: > Lars: The point of a flow label is to allow better flow identification > for packet handling, both at intermediate points and endpoints. Labeling > is up to the endpoints, and there can be multiple "flows" (as defined by > flow label) based on a single "connection" (as defined by state shared > by the endpoints). So a "flow" could include all packets supported by a > connection, or a subset of them. > > IMHO endpoints MAY use the same flow label on different flows (aka > subflows) taking different paths. If those paths merged at some point > the flows might be treated as one. This is true with or without > multipath transport. The current rules would allow that if the sending host is using different address pairs. But the merge point would need to know that the various source addresses or destination addresses are equivalent, and that raises a big security issue, because the flow label is forgeable and would make a really lousy nonce. Brian > > Scott > > > Lars Eggert allegedly wrote on 07/31/2009 02:38 EDT: >> 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 >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > From Aleksi.Suhonen@tut.fi Tue Aug 4 19:53:05 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 4CBA83A7097 for ; Tue, 4 Aug 2009 19:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 OqKnh10z9IVF for ; Tue, 4 Aug 2009 19:53:04 -0700 (PDT) Received: from mail-gw1.cc.tut.fi (mail-gw1.cc.tut.fi [130.230.160.15]) by core3.amsl.com (Postfix) with ESMTP id D7DAE3A67CC for ; Tue, 4 Aug 2009 19:53:03 -0700 (PDT) X-AuditID: 82e6a00f-b7b40ae000007078-fa-4a78f411c449 Received: from mail.cc.tut.fi (mail.cc.tut.fi [130.230.1.120]) by mail-gw1.cc.tut.fi (Symantec Brightmail Gateway) with SMTP id 53.66.28792.114F87A4; Wed, 5 Aug 2009 05:53:05 +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 36655A410D for ; Wed, 5 Aug 2009 05:53:05 +0300 (EEST) Message-ID: <4A78F410.1000009@tut.fi> Date: Wed, 05 Aug 2009 05:53:04 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Institute of Communications Engineering User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: multipathtcp@ietf.org References: <8D89A6E0-AA2B-4791-B789-63CFF8049F88@cs.ucl.ac.uk> In-Reply-To: <8D89A6E0-AA2B-4791-B789-63CFF8049F88@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [multipathtcp] Dealing with EBGP 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, 05 Aug 2009 02:53:05 -0000 Hi, Costin Raiciu wrote: > I kept wondering if "default on" MPTCP does break unmodified eBGP. I > need to ask the following questions, to get things straight in my head. > Experts (like Iljistch) please step in :) Iljitsch already responded, but I thought I'd pitch in too. It also sounds to me like you're already on the right path. I just wanted to reiterate a few points. > 1. Does eBGP bind the local source address before making a connection? > If so, we don't have a problem - in our current proposal MPTCP will not > even attempt to setup multiple flows > when the host locally binds a specific interface. With best current practices, EBGP binds the source address. However, with lazy configuration practices (often the case), it doesn't. EBGP connections are(*) between two different operators. When the operators are peering at an Internet Exchange Point, the address space belongs to neither of the two operators. When the EBGP session's purpose is private peering or transit, the address space belongs to one of the operators according to the terms of their agreement. A common practice is that an operator doesn't accept anyone else's address space in their IGP. This means that without the EBGP session, either (and sometimes neither) one of the operators wouldn't have any route to the addresses used by the EBGP/TCP connection, save for the directly connected routers. When the connection between the two EBGP speakers fails, the EBGP session should die as fast as possible, so that alternative routes would be sought. EBGP suffers slightly from TCP's attempts to survive short connection outages. MPTCP might prolong this suffering. > 2. Are addresses used by the border routers "routable"? I assume they > may well be, but they in fact don't need to. In the end, all you need > for a next hop is some address of a neighboring router (even ethernet > will do, and so will local ip addresses). If that were the case, then > multipath TCP would simply fail to find multiple paths - unless there > are redundant links between the same servers (this seems unlikely). Some operators protect their customer EBGP sessions by putting them on a different link than where the traffic flows. In those cases it also makes sense to use non-routable addresses on that link. As Iljitsch said, it's also common practice to filter external traffic directed at exchange point address space, to protect them from attacks. One thing to keep in mind is that EBGP sessions usually(*) use a TTL of one. MPTCP might well find alternative paths between the speakers, BUT the others might have more hops than the proper path. 3. IBGP You didn't write anything about IBGP, but I'm going to write something anyway. :-) The best practice is that IBGP sessions are bound to logical interfaces (loopbacks) instead of physical interfaces (such as ethernets) so that the failure of any single link won't affect the IBGP session as long as alternative paths exist. IBGP relies on IGP (usually OSPF or IS-IS) to spread the routes for the logical interfaces and to find alternative paths quickly. If an IBGP speaker is totally isolated from the rest of the network, the IBGP sessions should die as quickly as possible so that the network will converge to alternative (external) paths as quickly as possible. This too might be something MPTCP could prolong and hinder. Again, lazy configurations will bind IBGP sessions to either IPADDR_ANY or to some physical interface. This is where MPTCP could save those sessions from the failure of a single interface, but it should make sure to do a better job at it than IGP would. My two cents, -- Aleksi Suhonen, Research Assistant Department of Communications Engineering Tampere University of Technology (*) 99% of the time From iljitsch@muada.com Wed Aug 5 01:41: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 29A193A707A for ; Wed, 5 Aug 2009 01:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 2TXhCoLFScbU for ; Wed, 5 Aug 2009 01:41:20 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id E981C3A718C for ; Wed, 5 Aug 2009 01:41:19 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n758evjw049653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2009 10:40:57 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <4D084759-1E7D-472E-90C5-3727123451CF@muada.com> From: Iljitsch van Beijnum To: Brian E Carpenter In-Reply-To: <4A78AE4E.30406@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: Wed, 5 Aug 2009 10:41:13 +0200 References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com><7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com><4A7222DD.20401@gmail.com> <86C99C25-93E9-4D21-9C2C-27BBB69DDAC0@nokia.com> <2181C5F19DD0254692452BFF3EAF1D680830AF3F@rsys005a.comm.ad.roke.co.uk> <4A78AE4E.30406@gmail.com> 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: Wed, 05 Aug 2009 08:41:21 -0000 On 4 aug 2009, at 23:55, Brian E Carpenter wrote: > However, we just didn't think about the case where A is sending to B > using more than one address pair. It gets _really_ interesting when A and B are talking over different paths but using the same addresses. If routers do ECMP over the flow label then the flow label could be manipulated to make packets beloning to the same session flow over different paths. From C.Raiciu@cs.ucl.ac.uk Wed Aug 5 02:09: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 E06673A716F for ; Wed, 5 Aug 2009 02:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.712 X-Spam-Level: X-Spam-Status: No, score=-3.712 tagged_above=-999 required=5 tests=[AWL=2.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 Qf+QK4sGLYU8 for ; Wed, 5 Aug 2009 02:09:58 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by core3.amsl.com (Postfix) with SMTP id 1B5FD28C54F for ; Wed, 5 Aug 2009 02:09:15 -0700 (PDT) Received: from bells3.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Aug 2009 10:08:35 +0100 Received: from prayer by bells3.cs.ucl.ac.uk with local (Exim 4.54) id 1MYcSe-0006fe-Gh; Wed, 05 Aug 2009 10:07:04 +0100 From: C.Raiciu@cs.ucl.ac.uk To: Joe Touch Date: 05 Aug 2009 10:07:04 +0100 X-Mailer: Prayer v1.0.16 X-Originating-IP: [128.16.68.58] In-Reply-To: <4A784010.4010403@isi.edu> Message-ID: References: <8D89A6E0-AA2B-4791-B789-63CFF8049F88@cs.ucl.ac.uk> <69944CB0-62B7-4689-B004-68C6EF269A77@muada.com> <2A70142E-1810-4D6F-ACD3-9ED3600E1C96@cs.ucl.ac.uk> <4A784010.4010403@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Dealing with EBGP 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, 05 Aug 2009 09:09:59 -0000 On Aug 4 2009, Joe Touch wrote: >Costin Raiciu wrote: >>... >>>> If so, we don't have a problem - in our current proposal MPTCP will >>>> not even attempt to setup multiple flows >>>> when the host locally binds a specific interface. >>> >>> Strange. >>=20 >> Arguable. If an application only wants to accept connections destined >> for ip a, why should we advertise ip B to the other end. However, if the >> app binds INADDR_ANY, it seems natural it doesn't care and therefore we >> could use all addresses. > >The app would need to: >=09a) use wildcard addresses in its API (INADDR_ANY) >=09b) never use the local endpoint used (i.e., never look >=09at the socket's actual addresses) > >This goes for whichever end of the connection it assumes can have >multiple addresses - local or remote. Agreed > 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. >=20 > The implications if this would be: >=20 > - assume multipath TCP opens connections using a primary > (initial) socket pair >=20 > - as long as that socketpair is available*, the connection > stays up; when not, the connection is torn down >=20 > * =3D where "available" could mean just that both sides still think that > the IP address is bound to one of their interfaces. >=20 > I.e., you REALLY do not want the following case: >=20 >=20 > A: adr 11, adr 12 > B: adr 23, adr 24 >=20 > 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 >=20 > A ifconfig's adr 11 down >=20 > C ifconfig's adr 11 up >=20 > Now what? Well A needs not do anything in particular. It will timeout the subflow it= =20 had running on adr 11, and then remove the state associated with it.=20 B may try to retransmit data to A's 11 and it will end up at C. Here it wil= l get a reset -> so B will kill the subflow too. The problem, as I see it, is when applications use TCP to test path=20 liveness and measure path properties: e.g. EBGP does the first; I assume=20 there are dumb apps that use app level pings on top of TCP to measure rtt,= =20 for instance. In these cases, any type of multipath distorts the measurements; adding a= =20 single additional path makes the measurements meaningless. It seems that=20 for EBGP this may not be an issue, because it binds a specific address.=20 Can't tell what it will be like for other apps. Costin From C.Raiciu@cs.ucl.ac.uk Wed Aug 5 02:15:05 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 8FFD328C39D for ; Wed, 5 Aug 2009 02:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.13 X-Spam-Level: X-Spam-Status: No, score=-4.13 tagged_above=-999 required=5 tests=[AWL=1.670, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 zX6GADNIgkn3 for ; Wed, 5 Aug 2009 02:15:04 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by core3.amsl.com (Postfix) with SMTP id 252613A6B41 for ; Wed, 5 Aug 2009 02:13:43 -0700 (PDT) Received: from bells3.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Aug 2009 10:13:07 +0100 Received: from prayer by bells3.cs.ucl.ac.uk with local (Exim 4.54) id 1MYcX2-0006gU-Pb for multipathtcp@ietf.org; Wed, 05 Aug 2009 10:11:36 +0100 From: C.Raiciu@cs.ucl.ac.uk To: multipathtcp@ietf.org Date: 05 Aug 2009 10:11:36 +0100 X-Mailer: Prayer v1.0.16 X-Originating-IP: [128.16.68.58] In-Reply-To: <4A78F410.1000009@tut.fi> Message-ID: References: <8D89A6E0-AA2B-4791-B789-63CFF8049F88@cs.ucl.ac.uk> <4A78F410.1000009@tut.fi> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Subject: Re: [multipathtcp] Dealing with EBGP 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, 05 Aug 2009 09:15:05 -0000 Aleksi, Thanks for the clarifications, much appreciated. Costin On Aug 5 2009, Aleksi Suhonen wrote: >Hi, > >Costin Raiciu wrote: >> I kept wondering if "default on" MPTCP does break unmodified eBGP. I >> need to ask the following questions, to get things straight in my head. >> Experts (like Iljistch) please step in :) > >Iljitsch already responded, but I thought I'd pitch in too. It also >sounds to me like you're already on the right path. I just wanted to >reiterate a few points. > >> 1. Does eBGP bind the local source address before making a connection? >> If so, we don't have a problem - in our current proposal MPTCP will not >> even attempt to setup multiple flows >> when the host locally binds a specific interface. > >With best current practices, EBGP binds the source address. However, >with lazy configuration practices (often the case), it doesn't. > >EBGP connections are(*) between two different operators. When the >operators are peering at an Internet Exchange Point, the address space >belongs to neither of the two operators. When the EBGP session's purpose >is private peering or transit, the address space belongs to one of the >operators according to the terms of their agreement. > >A common practice is that an operator doesn't accept anyone else's >address space in their IGP. This means that without the EBGP session, >either (and sometimes neither) one of the operators wouldn't have any >route to the addresses used by the EBGP/TCP connection, save for the >directly connected routers. > >When the connection between the two EBGP speakers fails, the EBGP >session should die as fast as possible, so that alternative routes would >be sought. EBGP suffers slightly from TCP's attempts to survive short >connection outages. MPTCP might prolong this suffering. > >> 2. Are addresses used by the border routers "routable"? I assume they >> may well be, but they in fact don't need to. In the end, all you need >> for a next hop is some address of a neighboring router (even ethernet >> will do, and so will local ip addresses). If that were the case, then >> multipath TCP would simply fail to find multiple paths - unless there >> are redundant links between the same servers (this seems unlikely). > >Some operators protect their customer EBGP sessions by putting them on a >different link than where the traffic flows. In those cases it also >makes sense to use non-routable addresses on that link. > >As Iljitsch said, it's also common practice to filter external traffic >directed at exchange point address space, to protect them from attacks. > >One thing to keep in mind is that EBGP sessions usually(*) use a TTL of >one. MPTCP might well find alternative paths between the speakers, BUT >the others might have more hops than the proper path. > >3. IBGP > >You didn't write anything about IBGP, but I'm going to write something >anyway. :-) > >The best practice is that IBGP sessions are bound to logical interfaces >(loopbacks) instead of physical interfaces (such as ethernets) so that >the failure of any single link won't affect the IBGP session as long as >alternative paths exist. IBGP relies on IGP (usually OSPF or IS-IS) to >spread the routes for the logical interfaces and to find alternative >paths quickly. > >If an IBGP speaker is totally isolated from the rest of the network, the >IBGP sessions should die as quickly as possible so that the network will >converge to alternative (external) paths as quickly as possible. This >too might be something MPTCP could prolong and hinder. > >Again, lazy configurations will bind IBGP sessions to either IPADDR_ANY >or to some physical interface. This is where MPTCP could save those >sessions from the failure of a single interface, but it should make sure >to do a better job at it than IGP would. > >My two cents, > > From Scott.Brim@gmail.com Thu Aug 6 11:25:07 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 AC0C528C159; Thu, 6 Aug 2009 11:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.358 X-Spam-Level: X-Spam-Status: No, score=-5.358 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 02nbB1dMRPar; Thu, 6 Aug 2009 11:25:06 -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 9B14828C10C; Thu, 6 Aug 2009 11:25:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFO9ekpAZnmf/2dsb2JhbAC4RIcJgU8Ij22CNw0IgUwF X-IronPort-AV: E=Sophos;i="4.43,335,1246838400"; d="scan'208";a="53170935" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Aug 2009 18:25:07 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n76IP7Hw020206; Thu, 6 Aug 2009 14:25:07 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n76IP6oj001065; Thu, 6 Aug 2009 18:25:06 GMT Date: Wed, 5 Aug 2009 20:25:49 -0400 From: Scott Brim To: PAPADIMITRIOU Dimitri Message-ID: <20090806002549.GA95596@cisco.com> Mail-Followup-To: Scott Brim , PAPADIMITRIOU Dimitri , Multipath TCP Mailing List , IETF Discussion Mailing List 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; format=flowed Content-Disposition: inline In-Reply-To: <00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=Scott.Brim@gmail.com; dkim=neutral Cc: Multipath TCP Mailing List , 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, 06 Aug 2009 18:25:07 -0000 PAPADIMITRIOU Dimitri allegedly wrote on 07/31/2009 03:45 EDT: > - 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. We need to sort out priorities and milestones. Short term goals should just be about the endpoints acting on their own. In that case you are right. However, there is lots of useful speculation about future work in which endpoints and routers (or other infrastructure services) could work together so that endpoints could take advantage of more path diversity. > Note: The term "path" is from this perspective a bit confusing i.e. > inverse multiplexed TCP or multi component TCP would probably better > suite. A path is a way of getting from one endpoint to another. Subflows follow potentially different paths. The collection of paths taken by all subflows might need a name. > - 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). WG short term: if an endpoint has multiple interfaces, it can direct traffic to those on which it sees less congestion (taking policy, cost, etc. into account). That will certainly avoid congestion as experienced by the endpoint, which will certainly do at least as well as current TCP at lowering congestion in the network. In the future we can explore interactions between network TE and endpoint MPTCP. Are you concerned about synchronization and oscillations? > - 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. The endpoint (currently) doesn't know what is going on in routing. MPTCP will use potentially all paths that work. If routing breaks MPTCP will stop using broken paths, and when FRR heals those paths MPTCP will use them again. If they are on the same time scale, then on the broken/healed path you may get packet behavior similar to current TCP, except that retransmits can take place on other paths during the outage. Scott From Dimitri.Papadimitriou@alcatel-lucent.be Thu Aug 6 15:39: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 1105D3A6923; Thu, 6 Aug 2009 15:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24] 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 WsuFKIcIDVIl; Thu, 6 Aug 2009 15:39:38 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 559533A6A6A; Thu, 6 Aug 2009 15:38:59 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n76Md0Y0032275; Fri, 7 Aug 2009 00:39:00 +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, 7 Aug 2009 00:39:00 +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, 7 Aug 2009 00:38:58 +0200 Message-ID: <00275A5B436CA441900CB10936742A3802B820B8@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090806002549.GA95596@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] On Thursday's Multipath TCP BOF Thread-Index: AcoWwzzbTjoKyPH3QBmlNAHHZNbPfQACtOKg References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> <20090806002549.GA95596@cisco.com> From: "PAPADIMITRIOU Dimitri" To: "Scott Brim" X-OriginalArrivalTime: 06 Aug 2009 22:39:00.0670 (UTC) FILETIME=[B151D5E0:01CA16E6] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: Multipath TCP Mailing List , 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, 06 Aug 2009 22:39:39 -0000 Scott: > > - The BoF presentation considers that the TCP end-points controls > > routing of the traffic along a certain path in the network=20 > but routing > > information does not reach the end-points. >=20 > We need to sort out priorities and milestones. Short term=20 > goals should=20 > just be about the endpoints acting on their own. In that=20 > case you are=20 > right. However, there is lots of useful speculation about=20 > future work=20 > in which endpoints and routers (or other infrastructure=20 > services) could=20 > work together so that endpoints could take advantage of more=20 > path diversity. > > > Note: The term "path" is from this perspective a bit confusing i.e. > > inverse multiplexed TCP or multi component TCP would probably better > > suite. >=20 > A path is a way of getting from one endpoint to another. Subflows=20 > follow potentially different paths. The collection of paths taken by=20 > all subflows might need a name. A path may be defined as the "trajectory" packet follows to reach the destination (i.e., as determined by a sequence of hops traversed by the packets). As there is no mechanism for TCP to enforce the path followed by the packets in the network I do not see at all where the "longer" term objective could actually lead. Techniques that consist in driving the path followed by packets from the source to the destination (source-routing) in connectionless datagrams networks requires either signaling or encoding the "route" into the packet header.=20 This said, as far as I read you answer we seem to be in agreement ditto "Short term goals should just be about the endpoints acting on their own." we seem to disagree on the long term goals. > > - The BoF presentation considers that controlling onto which > > (sub-)connection the source puts traffic leads to offload=20 > the network > > from performing traffic engineering. Thus, I do not see how=20 > this would > > lead to a situation where the network would be free from any traffic > > engineering ? (I would even say the contrary, this would=20 > lead us back to > > the hyper-aggregation problem). >=20 > WG short term: if an endpoint has multiple interfaces, it can direct=20 > traffic to those on which it sees less congestion (taking=20 > policy, cost, etc. into account). =20 How is policy and cost information fed back to the end-points ?=20 > That will certainly avoid congestion as experienced=20 > by the endpoint, which will certainly do at least as well as=20 > current TCP at lowering congestion in the network. =20 > In the future we can explore interactions between network TE > and endpoint MPTCP. > > Are you concerned about synchronization and oscillations? I am concerned because there is no possibility after this BoF to determine the actual problem statement: is there a need for a linked congestion control scheme because "MP-TCP" is introduced that is perceived as a suitable evolution of TCP or do we want to solve a broader objective for which MP-TCP could be an element of solution ? Indeed, the first presentation of the BoF refers to offloading network traffic engineering operations. Quoting that presentation "We now understand that multipath TCP, if done appropriately, can go a long way towards solving network-wide traffic engineering problems." That statement raises the following issues: o) traffic engineering (=3D put traffic where unused capacity is) = enforces "path diversity" by adapting traffic routing to network conditions with joint traffic and resource-oriented performance objectives, i.e., if TE is not used anymore what would be the incentive to keep diversity in traffic routing (except local topological diversity often activated upon failure occurrence); what would be the reduction factor of diversity ?=20 o) self-fishdness: network will keep at least certain performance objectives and individual end-point/sources each their own, I fail to see how this proposal could reconcile both sides i.e. how does it ensure that the network actions are not antagonistic to the transport one. o) stability conditions (quoting one of the seminal paper in this space "Stability of Multi-Path Dual Congestion Control Algorithms": "...it would be desirable to find decentralized, scalable conditions for the global stability of a multi-path congestion control algorithm in the presence of propagation delays, ..." [...] "... we found decentralized, scalable conditions for local stability in the presence of propagation delays for a particular choice of scheme") are partially verified; this leads me to think that part of this work would be better addressed in the research space (but this is another discussion). So in brief, by considering one aspect of the problem (linked congestion control), one can not a priori state that the global objective (of offloading network-wide traffic engineering) can be reached because the underlying assumptions are not (yet) verified and are sometimes opposed to the conditions at the inception of this scheme. On the other hand, there is no apparent consensus to scope the work (from the replies I received on this list) to a TCP congestion control scheme. > > - 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=20 > state would > > remain permanent since the connection between Address 1 and=20 > 2 would not > > be re-established. So, it may be that some of the decisions=20 > 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=20 > presentations > > are within recovery times achievable using fast re-routing schemes. >=20 > The endpoint (currently) doesn't know what is going on in routing.=20 ... and even if it received routing information, it can not enforce a specific trajectory/ path to its packets (since the path followed by the packet is under control of the network). > MPTCP will use potentially all paths that work. If routing=20 > breaks MPTCP=20 > will stop using broken paths, and when FRR heals those paths=20 > MPTCP will use them again. =20 > > If they are on the same time scale, then on the=20 > broken/healed path you may get packet behavior similar to=20 > current TCP,=20 > except that retransmits can take place on other paths during=20 > the outage. As stated already, when dealing with failovers techniques reversion mechanisms shall be considered otherwise facing overall deterioriation over time. -d. > Scott >=20 From fred@cisco.com Thu Aug 6 16:06: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 1AEF73A6AA8 for ; Thu, 6 Aug 2009 16:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.906 X-Spam-Level: X-Spam-Status: No, score=-105.906 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Pwm+eemz15Xq for ; Thu, 6 Aug 2009 16:06:56 -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 E57AF3A69C2 for ; Thu, 6 Aug 2009 16:06:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADv/ekqrR7PD/2dsb2JhbAC5L4gqkCYFgj+BWYoL X-IronPort-AV: E=Sophos;i="4.43,337,1246838400"; d="scan'208";a="362145488" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Aug 2009 23:06:59 +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 n76N6xEb022930; Thu, 6 Aug 2009 16:06:59 -0700 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n76N6wH4022214; Thu, 6 Aug 2009 23:06:59 GMT Message-Id: From: Fred Baker To: Joe Touch In-Reply-To: <4A783F60.8070406@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 6 Aug 2009 16:06:56 -0700 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> <4A783F60.8070406@isi.edu> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=583; t=1249600019; x=1250464019; c=relaxed/simple; s=sjdkim3002; 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=20[multipathtcp]=20MP=20captain=20going=2 0down=20with=20the=20address=20ship,=20was=3A=20Re=3A=20=20O n=20Thursday's=20Multipath=20TCP=20BOF |Sender:=20; bh=FBSfeFZCHT1qyuG0ONWffyshEGCEYH9FeSwlZMjC+VA=; b=B8jHekoAr4NpncljFjzyDdKSwcK2KDpSCDV1kpBR9qsdDiOvq0UastBpip evc+f9trgXrDkNx9WeD9J882dlgXaFcojjpd/VUTSDgjMNmliiDP5hNIojQl GbZ6ZlBnId; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Thu, 06 Aug 2009 23:06:57 -0000 On Aug 4, 2009, at 7:02 AM, Joe Touch wrote: > The overall problem is that this proposal is creating a new concept - > that a group of addresses are bound together - and assuming we can > make > this meaningful to applications that use TCP. Disagree. We are saying that the application shouldn't be thinking about the network layer address. It should be thinking, perhaps, about the name of the remote system (if given an address, it should be able to do a reverse DNS lookup to verify it, and it should be able to connect to a remote application by name). From touch@ISI.EDU Thu Aug 6 19:41: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 CEE3E3A69A2 for ; Thu, 6 Aug 2009 19:41:37 -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 adybuWaa7KI2 for ; Thu, 6 Aug 2009 19:41:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A235B3A6897 for ; Thu, 6 Aug 2009 19:41:36 -0700 (PDT) Received: from [75.194.91.194] (194.sub-75-194-91.myvzw.com [75.194.91.194]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n772fEHm005439; Thu, 6 Aug 2009 19:41:16 -0700 (PDT) Message-ID: <4A7B9449.9050901@isi.edu> Date: Thu, 06 Aug 2009 19:41:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Fred Baker 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> <4A783F60.8070406@isi.edu> 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] MP captain going down with the address ship, 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, 07 Aug 2009 02:41:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fred Baker wrote: > > On Aug 4, 2009, at 7:02 AM, Joe Touch wrote: > >> The overall problem is that this proposal is creating a new concept - >> that a group of addresses are bound together - and assuming we can make >> this meaningful to applications that use TCP. > > Disagree. We are saying that the application shouldn't be thinking about > the network layer address. It should be thinking, perhaps, about the > name of the remote system (if given an address, it should be able to do > a reverse DNS lookup to verify it, and it should be able to connect to a > remote application by name). While I agree that apps should open connections to DNS names, the common mechanism involves the app querying the DNS, selecting from among a set of responses, and opening a connection to an IP address. This sequence is necessary because TCP doesn't connect DNS names (and ports), it connects IP addresses (and ports). Ultimately, since the app opens a connection to an IP address, it is that address to which it thinks it is talking. Changing the TCP API from "socket pair" to "DNS name/port number" pair (or better, DNSname/portname pair) would be interesting, but not backward compatible with apps that do resolution as an explicit step. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp7lEkACgkQE5f5cImnZrt4CwCgunkKxYJt8Bquk6Cy3sOoxCPh xE4An3tO+kIqYGS9I+Ib34o19ewFqdZJ =nF88 -----END PGP SIGNATURE----- From Michael.Tuexen@lurchi.franken.de Thu Aug 6 19:47:41 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 312483A68E8 for ; Thu, 6 Aug 2009 19:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.386 X-Spam-Level: ** X-Spam-Status: No, score=2.386 tagged_above=-999 required=5 tests=[AWL=0.348, 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 CcY4grEdn3Ci for ; Thu, 6 Aug 2009 19:47:40 -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 060903A69A2 for ; Thu, 6 Aug 2009 19:47:39 -0700 (PDT) Received: from [192.168.1.100] (p508FC092.dip.t-dialin.net [80.143.192.146]) by mail-n.franken.de (Postfix) with ESMTP id 4081D1C0C0BEA; Fri, 7 Aug 2009 04:47:40 +0200 (CEST) Message-Id: <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Joe Touch In-Reply-To: <4A7B9449.9050901@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 04:47:39 +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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> X-Mailer: Apple Mail (2.936) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] MP captain going down with the address ship, 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, 07 Aug 2009 02:47:41 -0000 On Aug 7, 2009, at 4:41 AM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Fred Baker wrote: >> >> On Aug 4, 2009, at 7:02 AM, Joe Touch wrote: >> >>> The overall problem is that this proposal is creating a new >>> concept - >>> that a group of addresses are bound together - and assuming we can >>> make >>> this meaningful to applications that use TCP. >> >> Disagree. We are saying that the application shouldn't be thinking >> about >> the network layer address. It should be thinking, perhaps, about the >> name of the remote system (if given an address, it should be able >> to do >> a reverse DNS lookup to verify it, and it should be able to connect >> to a >> remote application by name). > > While I agree that apps should open connections to DNS names, the > common > mechanism involves the app querying the DNS, selecting from among a > set > of responses, and opening a connection to an IP address. This sequence > is necessary because TCP doesn't connect DNS names (and ports), it > connects IP addresses (and ports). > > Ultimately, since the app opens a connection to an IP address, it is > that address to which it thinks it is talking. > > Changing the TCP API from "socket pair" to "DNS name/port number" pair > (or better, DNSname/portname pair) would be interesting, but not > backward compatible with apps that do resolution as an explicit step. I think connecting to "DNS name/port number" is difficult. Assume that 4 addresses are registered for a name in the DNS, two of them belonging to one host, two of them belonging to a different host. I think you can not terminate one MPTCP connection on two different nodes at the same time... Best regards Michael > > Joe > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkp7lEkACgkQE5f5cImnZrt4CwCgunkKxYJt8Bquk6Cy3sOoxCPh > xE4An3tO+kIqYGS9I+Ib34o19ewFqdZJ > =nF88 > -----END PGP SIGNATURE----- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From touch@ISI.EDU Thu Aug 6 19:50: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 78A0B3A6967 for ; Thu, 6 Aug 2009 19:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 T37VG0625FfP for ; Thu, 6 Aug 2009 19:50:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7EEB73A6A32 for ; Thu, 6 Aug 2009 19:50:56 -0700 (PDT) Received: from [75.194.91.194] (194.sub-75-194-91.myvzw.com [75.194.91.194]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n772oGdJ007243; Thu, 6 Aug 2009 19:50:19 -0700 (PDT) Message-ID: <4A7B9668.3020008@isi.edu> Date: Thu, 06 Aug 2009 19:50:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> In-Reply-To: <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] MP captain going down with the address ship, 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, 07 Aug 2009 02:50:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Tüxen wrote: > On Aug 7, 2009, at 4:41 AM, Joe Touch wrote: > > > > Fred Baker wrote: >>>> >>>> On Aug 4, 2009, at 7:02 AM, Joe Touch wrote: >>>> >>>>> The overall problem is that this proposal is creating a new concept - >>>>> that a group of addresses are bound together - and assuming we can make >>>>> this meaningful to applications that use TCP. >>>> >>>> Disagree. We are saying that the application shouldn't be thinking about >>>> the network layer address. It should be thinking, perhaps, about the >>>> name of the remote system (if given an address, it should be able to do >>>> a reverse DNS lookup to verify it, and it should be able to connect to a >>>> remote application by name). > > While I agree that apps should open connections to DNS names, the common > mechanism involves the app querying the DNS, selecting from among a set > of responses, and opening a connection to an IP address. This sequence > is necessary because TCP doesn't connect DNS names (and ports), it > connects IP addresses (and ports). > > Ultimately, since the app opens a connection to an IP address, it is > that address to which it thinks it is talking. > > Changing the TCP API from "socket pair" to "DNS name/port number" pair > (or better, DNSname/portname pair) would be interesting, but not > backward compatible with apps that do resolution as an explicit step. >> I think connecting to "DNS name/port number" is difficult. Assume that >> 4 addresses are registered for a name in the DNS, two of them belonging to >> one host, two of them belonging to a different host. I think you can >> not terminate one MPTCP connection on two different nodes at the same >> time... Oh, I agree. But that's what I meant when I said that the Internet doesn't have any notion of a "group of IP addresses" being a single machine. Without that notion, you need the captain to go down with the ship, because if the captain's gone you don't know you're on the same ship anymore. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp7lmgACgkQE5f5cImnZruRNACeJiVOIJ+9/McTIzAoX+P4G/WU zn8An3fxhNfTBYPxInkvbqvhByrl6/+F =GLHT -----END PGP SIGNATURE----- From Aleksi.Suhonen@tut.fi Thu Aug 6 20:54:48 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 F0DB43A69A3 for ; Thu, 6 Aug 2009 20:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 IAIe3xF7-Hlw for ; Thu, 6 Aug 2009 20:54:47 -0700 (PDT) Received: from mail-gw1.cc.tut.fi (mail-gw1.cc.tut.fi [130.230.160.15]) by core3.amsl.com (Postfix) with ESMTP id 7C8403A68B4 for ; Thu, 6 Aug 2009 20:54:45 -0700 (PDT) X-AuditID: 82e6a00f-b7b40ae000007078-a9-4a7ba587063b Received: from mail.cc.tut.fi (mail.cc.tut.fi [130.230.1.120]) by mail-gw1.cc.tut.fi (Symantec Brightmail Gateway) with SMTP id A5.35.28792.785AB7A4; Fri, 7 Aug 2009 06:54:47 +0300 (EEST) To: undisclosed-recipients:; Received: from [130.230.52.50] (rotta.atm.tut.fi [130.230.52.50]) by mail.cc.tut.fi (Postfix) with ESMTP id 769B2A412A for ; Fri, 7 Aug 2009 06:54:47 +0300 (EEST) Message-ID: <4A7BA587.6000702@tut.fi> Date: Fri, 07 Aug 2009 06:54:47 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Institute of Communications Engineering User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 CC: Multipath TCP Mailing List 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> In-Reply-To: <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAARA9Oqs= Subject: [multipathtcp] identifying multiple paths, was Re: MP captain going down with the address ship, 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, 07 Aug 2009 03:54:48 -0000 Michael Tüxen wrote: > I think connecting to "DNS name/port number" is difficult. Assume that > 4 addresses are registered for a name in the DNS, two of them belonging to > one host, two of them belonging to a different host. I think you can > not terminate one MPTCP connection on two different nodes at the same > time... I've actually been thinking about this problem (wrt SCTP) earlier and one solution I came up with was DNS hints. The short presentation I gave is online: http://research.nokia.com/files/host-app-based-multi-homing.pdf Incidentally, I mention iSCSI as well on those slides. It is an existing multipathing protocol that runs on top of TCP. Since there has been lots of discussion about implementing MPTCP by using several independent TCP connections and an overlay (such as SSL/TLS) I suggest people look into how iSCSI does multipathing over TCP. I THINK the relevant RFCs are: http://tools.ietf.org/html/3347 http://tools.ietf.org/html/3720 http://tools.ietf.org/html/5048 -- Aleksi Suhonen Department of Communications Engineering Tampere University of Technology From iljitsch@muada.com Fri Aug 7 01:56:07 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 A7B7C3A6E88 for ; Fri, 7 Aug 2009 01:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.364 X-Spam-Level: X-Spam-Status: No, score=-6.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 qVBobVoQaOlr for ; Fri, 7 Aug 2009 01:56:06 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 86EC33A6804 for ; Fri, 7 Aug 2009 01:56:06 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n778taav064651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Aug 2009 10:55:36 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <33E953A9-58C6-4DB6-816D-2FD5E99AC283@muada.com> From: Iljitsch van Beijnum To: Costin Raiciu In-Reply-To: <1EA98911-1122-4A5D-96DA-505E4825047E@cs.ucl.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 10:55:54 +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> <1EA98911-1122-4A5D-96DA-505E4825047E@cs.ucl.ac.uk> X-Mailer: Apple Mail (2.936) 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: Fri, 07 Aug 2009 08:56:07 -0000 On 27 jul 2009, at 14:58, Costin Raiciu wrote: > 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. One important point that goes beyond this particular issue: in multipath TCP, we have the luxory of not having to work 100% of the time. If we try to do multipath and it doesn't work, we still have a normal single path session so we haven't lost anything. This is especially relevant to NAT traversal: with other stuff, if you can't get through the NAT, you're dead in the water. We are still alive in the water, just not swimming as fast as we'd like to. (Unless, of course, we modify TCP so much that the initial subflow won't pass through NATs anymore.) > 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. Basically, what you're saying is that there is no useful middle ground between the one-ended and the two-ended approach. Obviously to some degree this is true, either you're one-ended or two-ended. But the current two-ended approach is very complex, so the gap between the two approaches is large. I can imagine that someone would like more functionality than the one-ended approach provides, but doesn't want to implement all the complexity of the current two-ended approach. By making some parts of your approach optional, it would be easier for people to implement at least some level of multiaddress MPTCP even if they feel that implementing all the mechanisms is too much. From iljitsch@muada.com Fri Aug 7 02:16: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 2F3E83A6EC3 for ; Fri, 7 Aug 2009 02:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 5fwWXRsGs573 for ; Fri, 7 Aug 2009 02:16:01 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 249323A6B74 for ; Fri, 7 Aug 2009 02:15:59 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n779FZ5l064770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Aug 2009 11:15:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <8A45EEE0-BFFD-410C-8DE8-FA703761FEE6@muada.com> From: Iljitsch van Beijnum To: Fred Baker In-Reply-To: <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 11:15:53 +0200 References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> X-Mailer: Apple Mail (2.936) 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, 07 Aug 2009 09:16:02 -0000 On 30 jul 2009, at 11:11, Fred Baker wrote: > 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. How would that be better than existing SACK and with normal fast retransmit executed per path? Since the receiver doesn't know over which path a particular piece of data was sent, or when it was sent, it doesn't really know when to request a retransmission. For instance, if the piece of data was sent 50 ms ago on a 10 ms path then obviously a retransmission would make sense but not so much 50 ms ago on a 250 ms path. We do need to solve the problem where one path fails so the last few packets sent over it will never make it and now that path is waiting for an RTO or even user timeout, while all the packets on other paths proceed to fill up the receive buffer. If the receive buffer can't accommodate for the data sent on alternative paths for an RTO duration on the failed path this means the working paths will stall. We try to address that in the one-ended draft with "slow retransmit" but the problem exists for all multipath stream transports. From iljitsch@muada.com Fri Aug 7 02:19: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 479513A6B74 for ; Fri, 7 Aug 2009 02:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.375 X-Spam-Level: X-Spam-Status: No, score=-6.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 iSY2xSWQ1-0D for ; Fri, 7 Aug 2009 02:19:49 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB013A6ECD for ; Fri, 7 Aug 2009 02:18:57 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n779IZlh064798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 7 Aug 2009 11:18:36 +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; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 11:18:54 +0200 X-Mailer: Apple Mail (2.936) Subject: [multipathtcp] More general congestion control linking 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, 07 Aug 2009 09:19:50 -0000 Hi, After reading some of the mailinglist discussions, it occurs to me that linking congestion control state isn't only useful between subflows belonging to the same multipath TCP session, but could also be applied to separate TCP flows between two hosts (think parallel connections to the same HTTP server) or even TCP flows towards different destinations (such as with BitTorrent). Iljitsch From ayourtch@cisco.com Fri Aug 7 04:06: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 06A7F28C0DD for ; Fri, 7 Aug 2009 04:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 lnC2PIQCmHxb for ; Fri, 7 Aug 2009 04:06:29 -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 C13EB3A6EE2 for ; Fri, 7 Aug 2009 04:06:28 -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 n77B6UwT025930; Fri, 7 Aug 2009 13:06:30 +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 n77B6U5D003459; Fri, 7 Aug 2009 13:06:30 +0200 (CEST) Date: Fri, 7 Aug 2009 13:06:29 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> Message-ID: 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1035978930-1249643189=:3263" Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, was: Re: On Thursday's Multipath TCP BOF 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: Fri, 07 Aug 2009 11:06:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1035978930-1249643189=:3263 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 7 Aug 2009, Michael T=FCxen wrote: > On Aug 7, 2009, at 4:41 AM, Joe Touch wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >>=20 >>=20 >> Fred Baker wrote: >> >=20 >> > On Aug 4, 2009, at 7:02 AM, Joe Touch wrote: >> >=20 >> > > The overall problem is that this proposal is creating a new concept = - >> > > that a group of addresses are bound together - and assuming we can m= ake >> > > this meaningful to applications that use TCP. >> >=20 >> > Disagree. We are saying that the application shouldn't be thinking abo= ut >> > the network layer address. It should be thinking, perhaps, about the >> > name of the remote system (if given an address, it should be able to d= o >> > a reverse DNS lookup to verify it, and it should be able to connect to= a >> > remote application by name). >>=20 >> While I agree that apps should open connections to DNS names, the common >> mechanism involves the app querying the DNS, selecting from among a set >> of responses, and opening a connection to an IP address. This sequence >> is necessary because TCP doesn't connect DNS names (and ports), it >> connects IP addresses (and ports). >>=20 >> Ultimately, since the app opens a connection to an IP address, it is >> that address to which it thinks it is talking. >>=20 >> Changing the TCP API from "socket pair" to "DNS name/port number" pair >> (or better, DNSname/portname pair) would be interesting, but not >> backward compatible with apps that do resolution as an explicit step. > I think connecting to "DNS name/port number" is difficult. Assume that > 4 addresses are registered for a name in the DNS, two of them belonging t= o > one host, two of them belonging to a different host. I think you can > not terminate one MPTCP connection on two different nodes at the same tim= e... IMHO Knowing whether the addresses are on the same host should be rather=20 simple - the clients sends a challenge during the 3WHS, and the=20 server applies the server-unique transform to this challenge and sends the = result=20 to the client. Say, something like SHA1(server_secret_value +=20 client_challenge). The client can compare the results from the connection= =20 attempts - if they are equal, we're talking to the same server or=20 something that asserts that it can act as a single server. Or am I missing something ? thanks, andrew > > Best regards > Michael >>=20 >> Joe >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>=20 >> iEYEARECAAYFAkp7lEkACgkQE5f5cImnZrt4CwCgunkKxYJt8Bquk6Cy3sOoxCPh >> xE4An3tO+kIqYGS9I+Ib34o19ewFqdZJ >> =3DnF88 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >>=20 > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --8323328-1035978930-1249643189=:3263-- From Joerg.Wagner@nw.neclab.eu Fri Aug 7 05:09: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 12FD83A6928 for ; Fri, 7 Aug 2009 05:09:42 -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 ohZEINpk-Rcl for ; Fri, 7 Aug 2009 05:09:41 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4080B3A6F06 for ; Fri, 7 Aug 2009 05:09:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EE1772C0002FE for ; Fri, 7 Aug 2009 14:09:41 +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 NrO2ZjVFuT+h for ; Fri, 7 Aug 2009 14:09:41 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 8FBB92C0002FD for ; Fri, 7 Aug 2009 14:09:36 +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: Fri, 7 Aug 2009 14:09:36 +0200 Message-ID: <50A01DCBF4001B478A524C12CAA7EF4D0AD422@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] More general congestion control linking Thread-Index: AcoXQFTOo56Rvsj5TZmCPmP8xBRzzQAF1Q8w References: From: "Joerg Wagner" To: "Multipath TCP Mailing List" Subject: Re: [multipathtcp] More general congestion control linking 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, 07 Aug 2009 12:14:59 -0000 > be applied to separate TCP flows between two hosts (think parallel=20 > connections to the same HTTP server) One could come up with a counter-scenario regarding "user-experience"... Imagine you browse to a website providing text and some (data intensive) = images. I prefer having the text quickly and I am willing to wait for = the picture a little bit longer. If a coupled transfer would slow-down = the textual data (but result in an overall gain though) I would be = disappointed. > or even TCP flows towards > different destinations (such as with BitTorrent). Maybe here one must differentiate a little bit. Having these flows = compete against each other seems rather odd too, but a competition = against other applications could still be useful (and probably should be = regulated by the end-user). The question is how one can decide where the bottleneck is? E.g. = competition of flows belonging to the same application on a saturated = homegateway makes not much sense (because it wastes packets) but if the = bottleneck is located later on some of the (divergent) paths the flows = should certainly try to adjust to that situation. Can we assume the = homegateway to be the bottleneck always? In any case wouldn't an implementation automatically result in the need = to provide more "internet connection options" to the end-user just to = fulfill all possible wishes?=20 Joerg From ayourtch@cisco.com Fri Aug 7 05:19: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 0EDC928C191 for ; Fri, 7 Aug 2009 05:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] 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 rPzFiGk0V3pd for ; Fri, 7 Aug 2009 05:19:57 -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 D84EB3A6E60 for ; Fri, 7 Aug 2009 05:19:56 -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 n77CJwBi011763; Fri, 7 Aug 2009 14:19:58 +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 n77CJwwM028093; Fri, 7 Aug 2009 14:19:58 +0200 (CEST) Date: Fri, 7 Aug 2009 14:19:57 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Joe Touch In-Reply-To: <4A7B9449.9050901@isi.edu> Message-ID: 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] MP captain going down with the address ship, was: Re: On Thursday's Multipath TCP BOF 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: Fri, 07 Aug 2009 12:19:58 -0000 On Thu, 6 Aug 2009, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Fred Baker wrote: >> >> On Aug 4, 2009, at 7:02 AM, Joe Touch wrote: >> >>> The overall problem is that this proposal is creating a new concept - >>> that a group of addresses are bound together - and assuming we can make >>> this meaningful to applications that use TCP. >> >> Disagree. We are saying that the application shouldn't be thinking about >> the network layer address. It should be thinking, perhaps, about the >> name of the remote system (if given an address, it should be able to do >> a reverse DNS lookup to verify it, and it should be able to connect to a >> remote application by name). > > While I agree that apps should open connections to DNS names, the common > mechanism involves the app querying the DNS, selecting from among a set > of responses, and opening a connection to an IP address. This sequence > is necessary because TCP doesn't connect DNS names (and ports), it > connects IP addresses (and ports). > > Ultimately, since the app opens a connection to an IP address, it is > that address to which it thinks it is talking. > > Changing the TCP API from "socket pair" to "DNS name/port number" pair > (or better, DNSname/portname pair) would be interesting, but not > backward compatible with apps that do resolution as an explicit step. If the MPTCP is backwards-compatible on the wire if one of the sides does not support it (from what I understood that's the case that for best use *both* sides need to be upgraded). This means that there is a possibility to provide such an API. And then the behaviour could be dependant on which API the applications used: 1) if it used conventional TCP API, then the captain sinks with the ship. 2) if it used the new API, then the captain from (1) is not in charge anyway - it'd be the hostname+some kind of identity token (e.g. what I described in my mail to Michael, being the challenge+response parts) - then the problem does not occur. Taking a step back - "why do the apps do the resolution as an explicit step ?" My personal answer to that would be "because noone gave any better alternative". Also because the default resolver is blocking, which creates the problems for the apps written in nonblocking I/O paradigm. So I think the application developers would benefit of a new API that takes the burden off them of coding the resolver/address selection glue. thanks, andrew From Michael.Tuexen@lurchi.franken.de Fri Aug 7 05:27: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 C30463A6928 for ; Fri, 7 Aug 2009 05:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.628 X-Spam-Level: ** X-Spam-Status: No, score=2.628 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_33=0.6, 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 fF3PIPK1x-fM for ; Fri, 7 Aug 2009 05:27:30 -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 A3D563A68A2 for ; Fri, 7 Aug 2009 05:27:29 -0700 (PDT) Received: from [192.168.1.100] (p508FC9EF.dip.t-dialin.net [80.143.201.239]) by mail-n.franken.de (Postfix) with ESMTP id ECAF41C0C0BEA; Fri, 7 Aug 2009 14:27:29 +0200 (CEST) Message-Id: <0B208025-2095-47D5-A1B8-EB707BB0C321@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: ayourtch@cisco.com 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 v936) Date: Fri, 7 Aug 2009 14:27:29 +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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> X-Mailer: Apple Mail (2.936) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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, 07 Aug 2009 12:27:31 -0000 On Aug 7, 2009, at 1:06 PM, Andrew Yourtchenko wrote: > On Fri, 7 Aug 2009, Michael T=FCxen wrote: > >> On Aug 7, 2009, at 4:41 AM, Joe Touch wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> Fred Baker wrote: >>> > > On Aug 4, 2009, at 7:02 AM, Joe Touch wrote: >>> > > > The overall problem is that this proposal is creating a new =20= >>> concept - >>> > > that a group of addresses are bound together - and assuming we =20= >>> can make >>> > > this meaningful to applications that use TCP. >>> > > Disagree. We are saying that the application shouldn't be =20 >>> thinking about >>> > the network layer address. It should be thinking, perhaps, about =20= >>> the >>> > name of the remote system (if given an address, it should be =20 >>> able to do >>> > a reverse DNS lookup to verify it, and it should be able to =20 >>> connect to a >>> > remote application by name). >>> While I agree that apps should open connections to DNS names, the =20= >>> common >>> mechanism involves the app querying the DNS, selecting from among =20= >>> a set >>> of responses, and opening a connection to an IP address. This =20 >>> sequence >>> is necessary because TCP doesn't connect DNS names (and ports), it >>> connects IP addresses (and ports). >>> Ultimately, since the app opens a connection to an IP address, it is >>> that address to which it thinks it is talking. >>> Changing the TCP API from "socket pair" to "DNS name/port number" =20= >>> pair >>> (or better, DNSname/portname pair) would be interesting, but not >>> backward compatible with apps that do resolution as an explicit =20 >>> step. >> I think connecting to "DNS name/port number" is difficult. Assume =20 >> that >> 4 addresses are registered for a name in the DNS, two of them =20 >> belonging to >> one host, two of them belonging to a different host. I think you can >> not terminate one MPTCP connection on two different nodes at the =20 >> same time... > > IMHO Knowing whether the addresses are on the same host should be =20 > rather simple - the clients sends a challenge during the 3WHS, and =20 > the server applies the server-unique transform to this challenge and =20= > sends the result to the client. Say, something like =20 > SHA1(server_secret_value + client_challenge). The client can compare =20= > the results from the connection attempts - if they are equal, we're =20= > talking to the same server or something that asserts that it can act =20= > as a single server. > > Or am I missing something ? One server responds with a SYN+ACK, one with a RST. What do you do? =20 Fail the MTCP connection? Best regards Michael > > thanks, > andrew > > >> >> Best regards >> Michael >>> Joe >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.9 (MingW32) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> iEYEARECAAYFAkp7lEkACgkQE5f5cImnZrt4CwCgunkKxYJt8Bquk6Cy3sOoxCPh >>> xE4An3tO+kIqYGS9I+Ib34o19ewFqdZJ >>> =3DnF88 >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> 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 ayourtch@cisco.com Fri Aug 7 05:54: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 CFA4828C1BE for ; Fri, 7 Aug 2009 05:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] 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 Eip43-AhvYT4 for ; Fri, 7 Aug 2009 05:54:43 -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 E84D128C1C2 for ; Fri, 7 Aug 2009 05:54:19 -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 n77CsL69017724; Fri, 7 Aug 2009 14:54:21 +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 n77CsLtn019095; Fri, 7 Aug 2009 14:54:21 +0200 (CEST) Date: Fri, 7 Aug 2009 14:54:21 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <0B208025-2095-47D5-A1B8-EB707BB0C321@lurchi.franken.de> Message-ID: 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> <0B208025-2095-47D5-A1B8-EB707BB0C321@lurchi.franken.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-280776553-1249649661=:3263" Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, was: Re: On Thursday's Multipath TCP BOF 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: Fri, 07 Aug 2009 12:54:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-280776553-1249649661=:3263 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 7 Aug 2009, Michael T=FCxen wrote: > On Aug 7, 2009, at 1:06 PM, Andrew Yourtchenko wrote: > >> On Fri, 7 Aug 2009, Michael T=FCxen wrote: >>=20 >> > On Aug 7, 2009, at 4:41 AM, Joe Touch wrote: >> >=20 >> > > -----BEGIN PGP SIGNED MESSAGE----- >> > > Hash: SHA1 >> > > Fred Baker wrote: >> > > > > On Aug 4, 2009, at 7:02 AM, Joe Touch wrote: >> > > > > > The overall problem is that this proposal is creating a new= =20 >> > > > > > concept - >> > > > > that a group of addresses are bound together - and assuming we = can=20 >> > > > > make >> > > > > this meaningful to applications that use TCP. >> > > > > Disagree. We are saying that the application shouldn't be think= ing=20 >> > > > > about >> > > > the network layer address. It should be thinking, perhaps, about = the >> > > > name of the remote system (if given an address, it should be able= to=20 >> > > > do >> > > > a reverse DNS lookup to verify it, and it should be able to conne= ct=20 >> > > > to a >> > > > remote application by name). >> > > While I agree that apps should open connections to DNS names, the=20 >> > > common >> > > mechanism involves the app querying the DNS, selecting from among a = set >> > > of responses, and opening a connection to an IP address. This sequen= ce >> > > is necessary because TCP doesn't connect DNS names (and ports), it >> > > connects IP addresses (and ports). >> > > Ultimately, since the app opens a connection to an IP address, it is >> > > that address to which it thinks it is talking. >> > > Changing the TCP API from "socket pair" to "DNS name/port number" pa= ir >> > > (or better, DNSname/portname pair) would be interesting, but not >> > > backward compatible with apps that do resolution as an explicit step= =2E >> > I think connecting to "DNS name/port number" is difficult. Assume that >> > 4 addresses are registered for a name in the DNS, two of them belongin= g=20 >> > to >> > one host, two of them belonging to a different host. I think you can >> > not terminate one MPTCP connection on two different nodes at the same= =20 >> > time... >>=20 >> IMHO Knowing whether the addresses are on the same host should be rather= =20 >> simple - the clients sends a challenge during the 3WHS, and the server= =20 >> applies the server-unique transform to this challenge and sends the resu= lt=20 >> to the client. Say, something like SHA1(server_secret_value +=20 >> client_challenge). The client can compare the results from the connectio= n=20 >> attempts - if they are equal, we're talking to the same server or someth= ing=20 >> that asserts that it can act as a single server. >>=20 >> Or am I missing something ? > One server responds with a SYN+ACK, one with a RST. What do you do? Fail = the > MTCP connection? No, continue working with the one that responded with SYN+ACK and not use= =20 the leg that went to the server responding with RST (maybe retry that=20 sometime later). I'd expect this to be transient condition rather than normal=20 modus operandi - if the host foobar.example.org has two A records, in the= =20 conventional TCP I'd expect to be able to get identical service from=20 either of the two - 'cos otherwise the application will fail 50% of the=20 time. So to that extent the FQDN _is_ the identity at the application layer and= =20 IP addresses are locators. Using the FQDN alone as an identity at=20 transport layer is a bit unsafe, precisely because as Joe mentioned,=20 there is no such concept (yet?) at transport layer - so it'd need to be=20 combined with something else used as a verifier. thanks, andrew > > Best regards > Michael >>=20 >> thanks, >> andrew >>=20 >>=20 >> >=20 >> > Best regards >> > Michael >> > > Joe >> > > -----BEGIN PGP SIGNATURE----- >> > > Version: GnuPG v1.4.9 (MingW32) >> > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> > > iEYEARECAAYFAkp7lEkACgkQE5f5cImnZrt4CwCgunkKxYJt8Bquk6Cy3sOoxCPh >> > > xE4An3tO+kIqYGS9I+Ib34o19ewFqdZJ >> > > =3DnF88 >> > > -----END PGP SIGNATURE----- >> > > _______________________________________________ >> > > multipathtcp mailing list >> > > multipathtcp@ietf.org >> > > https://www.ietf.org/mailman/listinfo/multipathtcp >> >=20 >> > _______________________________________________ >> > multipathtcp mailing list >> > multipathtcp@ietf.org >> > https://www.ietf.org/mailman/listinfo/multipathtcp >> >=20 > --8323328-280776553-1249649661=:3263-- From alan.ford@roke.co.uk Fri Aug 7 07:35:33 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 2CA273A6976 for ; Fri, 7 Aug 2009 07:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.113 X-Spam-Level: X-Spam-Status: No, score=-4.113 tagged_above=-999 required=5 tests=[AWL=-0.514, 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 za54vIs0KRZ3 for ; Fri, 7 Aug 2009 07:35:32 -0700 (PDT) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id 1EB423A6892 for ; Fri, 7 Aug 2009 07:35:31 -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 n77EZSVD019013; Fri, 7 Aug 2009 15:35: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: Fri, 7 Aug 2009 15:35:23 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680830B356@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <8A45EEE0-BFFD-410C-8DE8-FA703761FEE6@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] On Thursday's Multipath TCP BOF Thread-Index: AcoXP7fbVUvmhQaIS76vFefbSczc1AAKlJHA References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com><7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> <8A45EEE0-BFFD-410C-8DE8-FA703761FEE6@muada.com> From: "Ford, Alan" To: "Iljitsch van Beijnum" X-roke-co-uk-MailScanner-ID: n77EZSVD019013 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: 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, 07 Aug 2009 14:35:33 -0000 Hi, > We do need to solve the problem where one path fails so the last few > packets sent over it will never make it and now that path is waiting > for an RTO or even user timeout, while all the packets on other paths > proceed to fill up the receive buffer. If the receive buffer can't > accommodate for the data sent on alternative paths for an RTO duration > on the failed path this means the working paths will stall. We try to > address that in the one-ended draft with "slow retransmit" but the > problem exists for all multipath stream transports. This really depends on the implementation of the sending scheduler, but I don't see it being a particular problem. Consider: two subflows (1 and 2) between nodes A and B. Subflow 2 dies leaving several packets undelivered. When the RTO fires, it may well retransmit on subflow 1 instead.=20 Nevertheless, the receive buffer may well be filling up fast due to subflow 1. Optimisations could occur whereby, as the receiver will be aware of a gap in the data from an early stage (later sequence space is being acked on subflow 1), it may choose to preemptively retransmit on subflow 1 anyway. Regards, Alan From alan.ford@roke.co.uk Fri Aug 7 07:40: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 787F03A6A87 for ; Fri, 7 Aug 2009 07:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[AWL=-0.428, 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 Dxpc3S3XvD69 for ; Fri, 7 Aug 2009 07:40:42 -0700 (PDT) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id 65A8C3A68CE for ; Fri, 7 Aug 2009 07:40:42 -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 n77EeVoV009047; Fri, 7 Aug 2009 15:40:31 +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: Fri, 7 Aug 2009 15:40:29 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680830B35B@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <4A7B9668.3020008@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] MP captain going down with the address ship, was: Re: On Thursday's Multipath TCP BOF Thread-Index: AcoXCe02zZguEuPtRLithvRIeMspvwAYnikA 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><4A783F60.8070406@isi.edu><4A7B9449.9050901@isi.edu><5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> <4A7B9668.3020008@isi.edu> From: "Ford, Alan" To: "Joe Touch" 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: Multipath TCP Mailing List Subject: Re: [multipathtcp] MP captain going down with the address ship, 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, 07 Aug 2009 14:40:43 -0000 Hi, > Oh, I agree. But that's what I meant when I said that the Internet > doesn't have any notion of a "group of IP addresses" being a single machine. >=20 > Without that notion, you need the captain to go down with the ship, > because if the captain's gone you don't know you're on the same ship > anymore. At the risk of going down the analogy rat-hole, what's going on in MPTCP is you, the user, delegate to the captain to set up a connection from a source to a destination. The captain picks his crew (additional subflows), but may fall overboard later. That doesn't stop the ship carrying on to its destination, but you don't care - the connection is up - you trusted the captain to set up whatever was necessary to provide this connection. :-) Regards, Alan From rrs@lakerest.net Fri Aug 7 07:56: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 5D5DD3A6910 for ; Fri, 7 Aug 2009 07:56: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=[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 pqw5ELNH0Tmx for ; Fri, 7 Aug 2009 07:56:07 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id F12CF3A6892 for ; Fri, 7 Aug 2009 07:56:06 -0700 (PDT) Received: from rrs.rtp.extremenetworks.com (66-194-24-3.static.twtelecom.net [66.194.24.3]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n77Eu04Q038652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Aug 2009 10:56:02 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1249656963; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=RC9uzNCgxyF/N2gwfAtfeEXOkBNqBF8xi6otWq3MkRKjUiWq6mQ8orz dc8mzmFG55mW8Um3vaLhj+IkcrOkj/A== Message-Id: <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> From: Randall Stewart To: Iljitsch van Beijnum In-Reply-To: <4A783F60.8070406@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: Fri, 7 Aug 2009 10:55:55 -0400 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> <4A783F60.8070406@isi.edu> X-Mailer: Apple Mail (2.935.3) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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, 07 Aug 2009 14:56:08 -0000 On Aug 4, 2009, at 10:02 AM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Iljitsch van Beijnum wrote: >> On 31 jul 2009, at 11:16, Joe Touch wrote: >> >>> IMO, if an app decides to use multipath explicitly, it might as well >>> have used SCTP. >> >> SCTP in its current form does multiaddressing but not multiple >> paths at >> the same time or even smart path selection. Thats not necessarily true. Janardhan Iyengar published quite a bit of work on Conncurrent Multipath Transport (CMT)... which uses all paths i.e. your multi-path TCP. For some reason I have not seen any of your work mention or look at what he did in that body of work... It is currently implemented in FreeBSD and the only thing lacking is a internet draft/RFC... If you are curious you can take a look at Jana's work. And if I remember right Jana mentioned he might want to document that work in an RFC form ;-) R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From touch@ISI.EDU Fri Aug 7 08:06: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 05F723A6946 for ; Fri, 7 Aug 2009 08:06:35 -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 kvTl24vunu10 for ; Fri, 7 Aug 2009 08:06:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4C0F03A68BB for ; Fri, 7 Aug 2009 08:06:34 -0700 (PDT) Received: from [70.198.239.128] (128.sub-70-198-239.myvzw.com [70.198.239.128]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n77F6LcR011042; Fri, 7 Aug 2009 08:06:23 -0700 (PDT) Message-ID: <4A7C42EC.7020000@isi.edu> Date: Fri, 07 Aug 2009 08:06:20 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Ford, Alan" 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><4A783F60.8070406@isi.edu><4A7B9449.9050901@isi.edu><5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> <4A7B9668.3020008@isi.edu> <2181C5F19DD0254692452BFF3EAF1D680830B35B@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680830B35B@rsys005a.comm.ad.roke.co.uk> 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] MP captain going down with the address ship, 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, 07 Aug 2009 15:06:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ford, Alan wrote: > Hi, > >> Oh, I agree. But that's what I meant when I said that the Internet >> doesn't have any notion of a "group of IP addresses" being a single > machine. >> Without that notion, you need the captain to go down with the ship, >> because if the captain's gone you don't know you're on the same ship >> anymore. > > At the risk of going down the analogy rat-hole, what's going on in MPTCP > is you, the user, delegate to the captain to set up a connection from a > source to a destination. The captain picks his crew (additional > subflows), but may fall overboard later. That doesn't stop the ship > carrying on to its destination, but you don't care - the connection is > up - you trusted the captain to set up whatever was necessary to provide > this connection. Yeah, but if I (the app) signed up for a trip with the captain (which is how the TCP API works, binding to addresses), then I do care that the captain is gone. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp8QusACgkQE5f5cImnZrujzwCfVluKr6IcFNWb4EEYcJd8de27 fS4AoPIViUafPff2xKA09fzBgipw5dT0 =IG6U -----END PGP SIGNATURE----- From touch@ISI.EDU Fri Aug 7 08:16: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 D1AAE3A67AA for ; Fri, 7 Aug 2009 08:16:30 -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 53BFgyK5-7g3 for ; Fri, 7 Aug 2009 08:16:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D26B23A6C35 for ; Fri, 7 Aug 2009 08:16:29 -0700 (PDT) Received: from [70.198.239.128] (128.sub-70-198-239.myvzw.com [70.198.239.128]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n77FGLBx013210; Fri, 7 Aug 2009 08:16:23 -0700 (PDT) Message-ID: <4A7C4541.7080408@isi.edu> Date: Fri, 07 Aug 2009 08:16:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: ayourtch@cisco.com 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> 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] MP captain going down with the address ship, 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, 07 Aug 2009 15:16:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Yourtchenko wrote: >> IMHO Knowing whether the addresses are on the same host should be rather >> simple - the clients sends a challenge during the 3WHS, and the server >> applies the server-unique transform to this challenge and sends the >> result to the client. Say, something like SHA1(server_secret_value + >> client_challenge). The client can compare the results from the >> connection attempts - if they are equal, we're talking to the same >> server or something that asserts that it can act as a single server. > >> Or am I missing something ? First, you need to do SHA1 on every packet, not just the handshakes. Second, what happens when an address moves after a connection happens? E.g. let's say I'm an app that opens a connection to address A, which then goes multipath. Then I open another connection to address A. Does the app know that A isn't A anymore? Or that A from one connection isn't A from another? e.g., now all of a sudden HTTP may communicate with different parties depending on whether it uses persistent connections or separate connections - and since those connections are shared, opened, and closed dynamically, all of a sudden you've introduced nondeterminism in WHO I'm talking to. I'm saying that apps that use TCP ask to talk to an IP address, and keeping a connection up when an address disappears will break apps that don't expect that to happen. This is worse than just impact on things like BGP, e.g. That's why I think the MP goes down with the ship. It doesn't matter if the ship goes down with a RST, a FIN, or disconnection. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp8RUEACgkQE5f5cImnZrsKKgCgmfW0dDQM7ni+omoN0hEVR66/ o1YAoIUaU0A76gVz9d4NQMHBhVOdh5QE =+EBF -----END PGP SIGNATURE----- From ayourtch@cisco.com Fri Aug 7 08:32: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 C817D28C1E7 for ; Fri, 7 Aug 2009 08:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 53tBzW43dXzB for ; Fri, 7 Aug 2009 08:32:29 -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 58BB428C1D0 for ; Fri, 7 Aug 2009 08:32:24 -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 n77FWQN8015339; Fri, 7 Aug 2009 17:32:26 +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 n77FWPrm009268; Fri, 7 Aug 2009 17:32:25 +0200 (CEST) Date: Fri, 7 Aug 2009 17:32:25 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Joe Touch In-Reply-To: <4A7C4541.7080408@isi.edu> Message-ID: 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> <4A7C4541.7080408@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] MP captain going down with the address ship, was: Re: On Thursday's Multipath TCP BOF 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: Fri, 07 Aug 2009 15:32:30 -0000 On Fri, 7 Aug 2009, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Andrew Yourtchenko wrote: >>> IMHO Knowing whether the addresses are on the same host should be rather >>> simple - the clients sends a challenge during the 3WHS, and the server >>> applies the server-unique transform to this challenge and sends the >>> result to the client. Say, something like SHA1(server_secret_value + >>> client_challenge). The client can compare the results from the >>> connection attempts - if they are equal, we're talking to the same >>> server or something that asserts that it can act as a single server. >> >>> Or am I missing something ? > > First, you need to do SHA1 on every packet, not just the handshakes. No. when we're talking about subflows (which, each by themselves, look and smell like normal TCP flows - with 3whs), once Bob and Alice establish the subflow, they can assume (as much as the TCP allows) they are talking between themselves simply because of the seq#/ack#. If Carol gets Alice's address later, and Bob tries to send a packet, then the subflow will reset. Note, that here I used hashing just to make the spoofing a bit more difficult. They could as well send an UUID or any other sufficiently distinct ID within the SYN-ACK segments. > > Second, what happens when an address moves after a connection happens? > E.g. let's say I'm an app that opens a connection to address A, which > then goes multipath. Then I open another connection to address A. > > Does the app know that A isn't A anymore? Or that A from one connection > isn't A from another? e.g., now all of a sudden HTTP may communicate > with different parties depending on whether it uses persistent > connections or separate connections - and since those connections are > shared, opened, and closed dynamically, all of a sudden you've > introduced nondeterminism in WHO I'm talking to. Yes. That's why an API based on names would be needed to avoid sinking the captain :-) > > I'm saying that apps that use TCP ask to talk to an IP address, and > keeping a connection up when an address disappears will break apps that > don't expect that to happen. This is worse than just impact on things > like BGP, e.g. > > That's why I think the MP goes down with the ship. It doesn't matter if > the ship goes down with a RST, a FIN, or disconnection. In the address-based API, that is a fair proposal - because we don't know at which time the APP decides to do getpeername() (in which we'd need to return the captain name). That's for the conservative approach. And those who want to promise they don't want to use addresses, would use the name-based API instead. thanks, andrew > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkp8RUEACgkQE5f5cImnZrsKKgCgmfW0dDQM7ni+omoN0hEVR66/ > o1YAoIUaU0A76gVz9d4NQMHBhVOdh5QE > =+EBF > -----END PGP SIGNATURE----- > From lars.eggert@nokia.com Sat Aug 8 00:52: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 ACF1F3A67A5 for ; Sat, 8 Aug 2009 00:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 Njdg4iMyMegF for ; Sat, 8 Aug 2009 00:52:20 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 9E16C3A6964 for ; Sat, 8 Aug 2009 00:52:19 -0700 (PDT) Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n787qERD053678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Aug 2009 10:52:14 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Iljitsch van Beijnum In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-33-827794694; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 8 Aug 2009 10:52:14 +0300 References: X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Sat, 08 Aug 2009 10:52:14 +0300 (EEST) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] More general congestion control linking 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, 08 Aug 2009 07:52:20 -0000 --Apple-Mail-33-827794694 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit RFC2140 RFC3124 Effects of Ensemble-TCP. Lars Eggert, John Heidemann and Joe Touch. ACM Computer Communication Review (CCR), Vol. 30, No. 1, January 2000, pp. 15-29. https://fit.nokia.com/lars/papers/ensemble-tcp.pdf Lars On 2009-8-7, at 12:18, Iljitsch van Beijnum wrote: > Hi, > > After reading some of the mailinglist discussions, it occurs to me > that linking congestion control state isn't only useful between > subflows belonging to the same multipath TCP session, but could also > be applied to separate TCP flows between two hosts (think parallel > connections to the same HTTP server) or even TCP flows towards > different destinations (such as with BitTorrent). > > Iljitsch > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail-33-827794694 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 MBwGCSqGSIb3DQEJBTEPFw0wOTA4MDgwNzUyMTRaMCMGCSqGSIb3DQEJBDEWBBQ+J8boeMLTSUth pQGHcL0iJ9uCIjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAEFE97cKdEn7GsGU81V8r2mtHIzSaD+N7yGlQtylkYOzIj1TI0fVh LZekeFMaQ/Gfvlju4oTP2lbsGKNnbzmpd06LPk/obPPvwyRYTee11Z3QBEctOq6zKxKQHMqG17v4 zgBU8o8moSqs3ZC7CiMxe+bCDUgZdO+NZF2rhwasi8902sMC+PQ6+/RcB5flbBPxIEkj3tq4pFRk OMEwZgdimcQv9KGGVCBc67pgrqHxu/BzZXrL8hwwbWvyhZep0jj9dnBR5X5vJJdyrlxw6JCipUFb yPPaXhWwxFUa2FsRQVJ++9u8S01/jkaPXuXt5MWcxHNFKAFgaSDlKTFC69JocAAAAAAAAA== --Apple-Mail-33-827794694-- From lars.eggert@nokia.com Sat Aug 8 00:54: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 6E4043A6B05 for ; Sat, 8 Aug 2009 00:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 bdAwPU08+2F2 for ; Sat, 8 Aug 2009 00:54:17 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id DA9423A6CA7 for ; Sat, 8 Aug 2009 00:54:11 -0700 (PDT) Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n787s7CZ053782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Aug 2009 10:54:07 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Joerg Wagner In-Reply-To: <50A01DCBF4001B478A524C12CAA7EF4D0AD422@VENUS.office> Content-Type: multipart/signed; boundary=Apple-Mail-34-827907479; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 8 Aug 2009 10:54:06 +0300 References: <50A01DCBF4001B478A524C12CAA7EF4D0AD422@VENUS.office> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Sat, 08 Aug 2009 10:54:07 +0300 (EEST) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] More general congestion control linking 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, 08 Aug 2009 07:54:18 -0000 --Apple-Mail-34-827907479 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-8-7, at 15:09, Joerg Wagner wrote: >> be applied to separate TCP flows between two hosts (think parallel >> connections to the same HTTP server) > One could come up with a counter-scenario regarding "user- > experience"... > Imagine you browse to a website providing text and some (data > intensive) images. I prefer having the text quickly and I am willing > to wait for the picture a little bit longer. If a coupled transfer > would slow-down the textual data (but result in an overall gain > though) I would be disappointed. see the results for the "HTML-pre" scheme in https://fit.nokia.com/lars/papers/ensemble-tcp.pdf Lars >> or even TCP flows towards >> different destinations (such as with BitTorrent). > Maybe here one must differentiate a little bit. Having these flows > compete against each other seems rather odd too, but a competition > against other applications could still be useful (and probably > should be regulated by the end-user). > The question is how one can decide where the bottleneck is? E.g. > competition of flows belonging to the same application on a > saturated homegateway makes not much sense (because it wastes > packets) but if the bottleneck is located later on some of the > (divergent) paths the flows should certainly try to adjust to that > situation. Can we assume the homegateway to be the bottleneck always? > > In any case wouldn't an implementation automatically result in the > need to provide more "internet connection options" to the end-user > just to fulfill all possible wishes? > > Joerg > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail-34-827907479 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 MBwGCSqGSIb3DQEJBTEPFw0wOTA4MDgwNzU0MDdaMCMGCSqGSIb3DQEJBDEWBBSfzKKgqyZxu9iv lnLaIXsSGhU3/TCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAMI/Hk0UwZJ1fNJjj+UygbmwWcIwHEmh6F88akmIsb9sgoY9DrQ4x 9Z4U8938ankDhwmE7yGr/H0R/8WVCl7FOBG5P06yWWgQk43i3pqCu/vuR8ZFcvuDWu2Rbk3Uu7xo pYH6mAfbvDNEmC5bPgCixohIMNeIc/Ip7yLzfz/8cpEceY3fx1R3d3PTHXMMh6Zco1a5jC4aahHR A1EvLBWzFeg9derO5HHqS1qq4oK8GyvP23QiYWpimOCnlmmhOeAHzQT9T9PlG6PvGjC3kmeAYNEX pP/+KXh37VsNoMOmeFmLQOv+LF5Xzf98BTSGSQhEG2VayUT6xy2KBTZojSfLwwAAAAAAAA== --Apple-Mail-34-827907479-- From lars.eggert@nokia.com Sat Aug 8 00:57:10 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 5B4BB3A69ED for ; Sat, 8 Aug 2009 00:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 E2u6pwbFnscH for ; Sat, 8 Aug 2009 00:57:09 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 6B5A83A6964 for ; Sat, 8 Aug 2009 00:57:09 -0700 (PDT) Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n787v4xk053983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Aug 2009 10:57:04 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> From: Lars Eggert To: Randall Stewart In-Reply-To: <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> Content-Type: multipart/signed; boundary=Apple-Mail-35-828084415; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 8 Aug 2009 10:57:03 +0300 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> <4A783F60.8070406@isi.edu> <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Sat, 08 Aug 2009 10:57:04 +0300 (EEST) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 07:57:10 -0000 --Apple-Mail-35-828084415 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-8-7, at 17:55, Randall Stewart wrote: > Thats not necessarily true. Janardhan Iyengar published quite a bit > of work on Conncurrent Multipath Transport (CMT)... which uses all > paths > i.e. your multi-path TCP. For some reason I have not seen any of > your work > mention or look at what he did in that body of work... It is currently > implemented in FreeBSD and the only thing lacking is a internet > draft/RFC... CMT was brought up several times in the discussion on- and off-list. And I at least was under the impression that the reason it wasn't in an ID yet is that the coupled congestion control bit wasn't worked out yet for CMT? Lars --Apple-Mail-35-828084415 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 MBwGCSqGSIb3DQEJBTEPFw0wOTA4MDgwNzU3MDRaMCMGCSqGSIb3DQEJBDEWBBQgJUEpw4WKJdKZ 7XS1nBnCh5aDQzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAH3mlDB2Aii9Ax3eZetgD29Q8gZyxXsX3aBtbvXdaeKi6IbfQyq8D agTRpY+HMldQHoODkwuDqnIyaQg3f53LGXfBrMSmGqsZGD4EjvNpaMTaRbuTcLQYq/RNC486WG/6 wb4ywLxj9Ew0Sfbs4xQ+oNdjvSLusBS/YJMS4Pww0Z29Ru2xubJpYJmy9AsHovn84L/prkyHiCMC guFBqSQmgyooy68+q/5mD6+AQlX3IjhoZf6UyAOee2E+Aa8W/HzvNtWWMAT3iN7jdvH7qMij0Rlp qE9SZnHKStW+9/yRotXSqG8BGKVvybaksCFc9lTaolJ0REv/cBttfZXqEcBjKQAAAAAAAA== --Apple-Mail-35-828084415-- From lars.eggert@nokia.com Sat Aug 8 01:09: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 58CFD3A6CB7 for ; Sat, 8 Aug 2009 01:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 9jsEscB2iNI1 for ; Sat, 8 Aug 2009 01:09:37 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 06DF428C0FA for ; Sat, 8 Aug 2009 01:09:26 -0700 (PDT) Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7889LUf054576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Aug 2009 11:09:22 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <34494212-8907-47E3-9AF1-AC2BB3F48942@nokia.com> From: Lars Eggert To: Joe Touch In-Reply-To: <4A7C42EC.7020000@isi.edu> Content-Type: multipart/signed; boundary=Apple-Mail-36-828822237; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 8 Aug 2009 11:09:21 +0300 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><4A783F60.8070406@isi.edu><4A7B9449.9050901@isi.edu><5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> <4A7B9668.3020008@isi.edu> <2181C5F19DD0254692452BFF3EAF1D680830B35B@rsys005a.comm.ad.roke.co.uk> <4A7C42EC.7020000@isi.edu> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Sat, 08 Aug 2009 11:09:22 +0300 (EEST) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 08:09:38 -0000 --Apple-Mail-36-828822237 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-8-7, at 18:06, Joe Touch wrote: > Ford, Alan wrote: >> At the risk of going down the analogy rat-hole, what's going on in >> MPTCP >> is you, the user, delegate to the captain to set up a connection >> from a >> source to a destination. The captain picks his crew (additional >> subflows), but may fall overboard later. That doesn't stop the ship >> carrying on to its destination, but you don't care - the connection >> is >> up - you trusted the captain to set up whatever was necessary to >> provide >> this connection. > > Yeah, but if I (the app) signed up for a trip with the captain > (which is > how the TCP API works, binding to addresses), then I do care that the > captain is gone. It's clear that some apps signed up for a trip in general (A), while others signed up for a trip with a specific captain (B). We have two ways forward: (1) MPTCP off by default, enabled only for apps in class A (2) MPTCP on by default, disabled only for apps in class B I believe Joe is saying that because we cannot enumerate or otherwise identify all the apps in class B, approach (1) is the one we need to go with. And we actually know that a non-trivial number of apps are in class A (in my opinion, everything that can run on top of TLS, because those apps bind to a TLS association endpoint and not a port). And once MPTCP is out there, I expect app designer to quickly move to it for protocols that don't work over it from the beginning. I agree that (2) would lead to more impact/larger benefits, because more traffic would be multipath-enabled. But at the moment, that's not a recommendation we can make. Once people have run experiments with (2) in non-trivial deployments, we may well find that the set of apps in class B is very small. At that point, we can still move to approach (2). Lars --Apple-Mail-36-828822237 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 MBwGCSqGSIb3DQEJBTEPFw0wOTA4MDgwODA5MjJaMCMGCSqGSIb3DQEJBDEWBBT7WsJOiStkp5qF kvvhKNTp0NPdJzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAapaJYa16QxmaMqbfDi19uPD55cLGl1TCcmS3WEiRLgCb/ox4SKm6 VApoCoT2QW+F4ufV9vuooGAErpe0Kt+6M3rgaXs36eQk9O6vBRGxQUJKzkuKhalctyWKI2KDOUvp GtxOKjisc7r/Df51ePPAvkC8JCJnGTbtT3J3a4WCQP+Z6otXK1DqW6zyTrtm3OOspuToDE+Z1QVf I+iRPY5aX27G1VSu7swKfbqAMW6loCJAgvvixnetE2gwqqcTotLnlEQ4fx/UkiJznSsGW/+opPt4 8on6Sn4FAGyvC8ybrPavNEld3krN1LW93isZ+T5+Ou+O/aSps/AYlyEZA87NtgAAAAAAAA== --Apple-Mail-36-828822237-- From Michael.Tuexen@lurchi.franken.de Sat Aug 8 01:25: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 8B8A53A6AA6 for ; Sat, 8 Aug 2009 01:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.329 X-Spam-Level: ** X-Spam-Status: No, score=2.329 tagged_above=-999 required=5 tests=[AWL=0.291, 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 W+VnGzgOTD8m for ; Sat, 8 Aug 2009 01:25:57 -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 7E91F3A6895 for ; Sat, 8 Aug 2009 01:25:57 -0700 (PDT) Received: from [192.168.1.100] (p508FC9EF.dip.t-dialin.net [80.143.201.239]) by mail-n.franken.de (Postfix) with ESMTP id BA6371C0C0BC0; Sat, 8 Aug 2009 10:25:57 +0200 (CEST) Message-Id: <935655A5-08A7-4122-B376-40FBB29B5142@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Lars Eggert In-Reply-To: <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 8 Aug 2009 10:25:56 +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> <4A783F60.8070406@isi.edu> <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> X-Mailer: Apple Mail (2.936) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 08:25:58 -0000 On Aug 8, 2009, at 9:57 AM, Lars Eggert wrote: > Hi, > > On 2009-8-7, at 17:55, Randall Stewart wrote: >> Thats not necessarily true. Janardhan Iyengar published quite a bit >> of work on Conncurrent Multipath Transport (CMT)... which uses all >> paths >> i.e. your multi-path TCP. For some reason I have not seen any of >> your work >> mention or look at what he did in that body of work... It is >> currently >> implemented in FreeBSD and the only thing lacking is a internet >> draft/RFC... > > CMT was brought up several times in the discussion on- and off-list. > And I at least was under the impression that the reason it wasn't in > an ID yet is that the coupled congestion control bit wasn't worked > out yet for CMT? That is right. But one can use the CC suggested by Mark. What CMT also provides are the procedures describing how to live with one sequence number space for all paths. Unlike MPTCP, which has a separate sequence number space for all paths... Best regards Michael > > Lars_______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From lars.eggert@nokia.com Sat Aug 8 02:41: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 625C53A6AC1 for ; Sat, 8 Aug 2009 02:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 Ho8mKOKxoXcI for ; Sat, 8 Aug 2009 02:41:52 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 5CD0A3A6765 for ; Sat, 8 Aug 2009 02:41:52 -0700 (PDT) Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n789fkRC059036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Aug 2009 12:41:46 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <0C64351D-1D06-44E9-A7CF-566C8EDFCF6B@nokia.com> From: Lars Eggert To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <935655A5-08A7-4122-B376-40FBB29B5142@lurchi.franken.de> Content-Type: multipart/signed; boundary=Apple-Mail-1-834367364; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 8 Aug 2009 12:41:46 +0300 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> <4A783F60.8070406@isi.edu> <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> <935655A5-08A7-4122-B376-40FBB29B5142@lurchi.franken.de> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Sat, 08 Aug 2009 12:41:47 +0300 (EEST) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 09:41:53 -0000 --Apple-Mail-1-834367364 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, On 2009-8-8, at 11:25, Michael T=FCxen wrote: > That is right. But one can use the CC suggested by Mark. oh, absolutely. I'm halfway expecting Jana to be hacking it into CMT =20 already :-) Lars= --Apple-Mail-1-834367364 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 MBwGCSqGSIb3DQEJBTEPFw0wOTA4MDgwOTQxNDdaMCMGCSqGSIb3DQEJBDEWBBTeRd24X5C4tNYo cHwmI8RMt6m7bTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAZE8y5XodVixYj5XgTWYchUea87tbpVePe7EPg8HZESZoiM5EubA9 gRHVO0DnlAY68UbAf1FYfB6uU/iEpY8lOS0qjMiuxOEDSmXaql6cigIpTW3e0hNhMeaZhKj0FBMz ndG87yQ+4fRrjSQ7V2szcaYkar9v/yobREjuYvAqkGiNUofrYiORVq8qGnwHQ96WGQZ5GUe3OPAm jOzKBQdCzBuTRWDNrkx/NE9o2kD+HyZ2nxsuEMQ36mm5Rt4PJq40XQV1iikRjzlNjJ2BDMHGadyv KGQa261EG1/JrYUEW5GovqC08MV8u9PDH5x+tBvNM3wLI2fbBh32ZFv1H/FJnwAAAAAAAA== --Apple-Mail-1-834367364-- From iljitsch@muada.com Sat Aug 8 02:45: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 5F72F3A67ED for ; Sat, 8 Aug 2009 02:45:29 -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 CG4cM7wJCiT1 for ; Sat, 8 Aug 2009 02:45:28 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 769773A6838 for ; Sat, 8 Aug 2009 02:45:28 -0700 (PDT) Received: from [10.163.93.135] ([80.27.101.136]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n789ixYG072782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Aug 2009 11:45:05 +0200 (CEST) (envelope-from iljitsch@muada.com) 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> <4A783F60.8070406@isi.edu> <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> Message-Id: <860F6F52-BA1C-48A3-9A0C-29661AF56A7C@muada.com> From: Iljitsch van Beijnum To: Lars Eggert In-Reply-To: <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Date: Sat, 8 Aug 2009 11:45:35 +0200 Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 09:45:29 -0000 On 8 aug 2009, at 09:57, Lars Eggert wrote: > CMT was brought up several times in the discussion on- and off-list. > And I at least was under the impression that the reason it wasn't in > an ID yet is that the coupled congestion control bit wasn't worked > out yet for CMT? There's a bunch of papers but no overarching specification, not sure why this work hasn't been brought to the IETF, but immaturity would be one explanation. From Michael.Tuexen@lurchi.franken.de Sat Aug 8 02:49: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 095713A6DA3 for ; Sat, 8 Aug 2009 02:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.293 X-Spam-Level: ** X-Spam-Status: No, score=2.293 tagged_above=-999 required=5 tests=[AWL=0.255, 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 wcsqHWMBlqMZ for ; Sat, 8 Aug 2009 02:49:38 -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 EFD7328C19A for ; Sat, 8 Aug 2009 02:48:50 -0700 (PDT) Received: from [192.168.1.100] (p508FC236.dip.t-dialin.net [80.143.194.54]) by mail-n.franken.de (Postfix) with ESMTP id 364DC1C0C0BC0; Sat, 8 Aug 2009 11:48:52 +0200 (CEST) Message-Id: <987C5D90-7F59-488D-A0E6-3CFF5E2CF35C@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Iljitsch van Beijnum In-Reply-To: <860F6F52-BA1C-48A3-9A0C-29661AF56A7C@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 8 Aug 2009 11:48:51 +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> <4A783F60.8070406@isi.edu> <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> <860F6F52-BA1C-48A3-9A0C-29661AF56A7C@muada.com> X-Mailer: Apple Mail (2.936) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 09:49:39 -0000 On Aug 8, 2009, at 11:45 AM, Iljitsch van Beijnum wrote: > On 8 aug 2009, at 09:57, Lars Eggert wrote: > >> CMT was brought up several times in the discussion on- and off- >> list. And I at least was under the impression that the reason it >> wasn't in an ID yet is that the coupled congestion control bit >> wasn't worked out yet for CMT? > > There's a bunch of papers but no overarching specification, not sure > why this work hasn't been brought to the IETF, but immaturity would > be one explanation. .. but it isn't. It is because the missing point was shared bottleneck detection where we had no solution for. Without it, it would not have made it through the standardisation process. But using Marks CC algorithm this problem is gone... Best regards Michael > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From Michael.Tuexen@lurchi.franken.de Sat Aug 8 03:32: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 E3B273A6EB4 for ; Sat, 8 Aug 2009 03:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.265 X-Spam-Level: ** X-Spam-Status: No, score=2.265 tagged_above=-999 required=5 tests=[AWL=0.227, 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 MIIUrwGO-Xzh for ; Sat, 8 Aug 2009 03:32:36 -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 1C8CE3A6ED1 for ; Sat, 8 Aug 2009 03:32:35 -0700 (PDT) Received: from [192.168.1.100] (p508FC236.dip.t-dialin.net [80.143.194.54]) by mail-n.franken.de (Postfix) with ESMTP id 85A4B1C0C0BEA; Sat, 8 Aug 2009 12:32:36 +0200 (CEST) Message-Id: <9A2F14E9-DA4F-47E0-9B0A-25CA2800922B@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Lars Eggert In-Reply-To: <0C64351D-1D06-44E9-A7CF-566C8EDFCF6B@nokia.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 v936) Date: Sat, 8 Aug 2009 12:32:35 +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> <4A783F60.8070406@isi.edu> <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> <935655A5-08A7-4122-B376-40FBB29B5142@lurchi.franken.de> <0C64351D-1D06-44E9-A7CF-566C8EDFCF6B@nokia.com> X-Mailer: Apple Mail (2.936) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 10:32:37 -0000 On Aug 8, 2009, at 11:41 AM, Lars Eggert wrote: > Hi, > > On 2009-8-8, at 11:25, Michael T=FCxen wrote: >> That is right. But one can use the CC suggested by Mark. > > oh, absolutely. I'm halfway expecting Jana to be hacking it into CMT =20= > already :-) I don't know. If he doesn't do it I do it after getting a couple of things clarified with Marks proposal... > > Lars From john@jlc.net Sat Aug 8 07:18: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 57BB33A6B9E for ; Sat, 8 Aug 2009 07:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=0.331, 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 FtxlZKiqkOmP for ; Sat, 8 Aug 2009 07:18:21 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 225893A682E for ; Sat, 8 Aug 2009 07:18:21 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 19B0D33C6B; Sat, 8 Aug 2009 10:18:14 -0400 (EDT) Date: Sat, 8 Aug 2009 10:18:14 -0400 From: John Leslie To: Lars Eggert Message-ID: <20090808141814.GB95725@verdi> References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <00275A5B436CA441900CB10936742A3802B1BEC1@FRVELSMBS22.ad2.ad.alcatel.com> <20090731084915.GV9935@verdi> <98FF5E69-6491-4D56-B0E7-EE26EC266139@muada.com> <4A7B9668.3020008@isi.edu> <2181C5F19DD0254692452BFF3EAF1D680830B35B@rsys005a.comm.ad.roke.co.uk> <4A7C42EC.7020000@isi.edu> <34494212-8907-47E3-9AF1-AC2BB3F48942@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34494212-8907-47E3-9AF1-AC2BB3F48942@nokia.com> User-Agent: Mutt/1.4.1i Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 14:18:22 -0000 Lars Eggert wrote: > > We have two ways forward: > > (1) MPTCP off by default, enabled only for apps in class A > (2) MPTCP on by default, disabled only for apps in class B For my BGP machines, I want MPTCP off, period. For either of Lars' approaches we need to define some mechanism to say which applications opt in or opt out. Given the differing Operating Systems in use on the Internet, this may not be trivial. > I believe Joe is saying that because we cannot enumerate or otherwise > identify all the apps in class B, approach (1) is the one we need to > go with. Joe is taking a somewhat extreme "conservative" position, which IMHO makes sense for something we unleash on the 'Net without warning. I'm not sure it makes sense for something clearly labeled "Experimental," but we are hoping to unleash this eventually, so it would be good to see a way forward to that. > And we actually know that a non-trivial number of apps are in class > A (in my opinion, everything that can run on top of TLS, because > those apps bind to a TLS association endpoint and not a port). I'm not clear that we have any handle on what apps might be making assumptions that MPTCP would break, beyond the BGP case. BGP is, frankly, a hack put together in ancient history (1989) to propagate routing information along the same "fabric" that does the forwarding. To "simplify" sharing the routing information, a "reliable" transmission protocol was specified: meaning that we want retransmission of garbled or dropped packets. We depend upon this "connection" being able to send and receive "keep-alive" messages to indicate that the link is useful for the layer-2 forwarding we will do. We could just as well have done everything at layer-2 with our own retransmissions, but TCP seemed easier at the time. In retrospect, it was probably the wrong choice, because it constrains BGP timeouts according to TCP parameters which will inevitably be optimized for very different needs. (MPTCP for BGP sessions would break the assumption that layer-2 forwarding from source-IP to destination-IP and vice-versa is proven by the occasional keep-alive being received.) I have thought of another case where MPTCP might confuse an app: "POP-before-SMTP" is a commonly-used hack to determine that an email sending client should be trusted. The remote IP address of a POP client retrieving email is recorded, and the SMTP server is told to trust that IP address for a few minutes. In this case, a mobile user using MPTCP could initially connect to the POP server from one IP address and complete the retrieval after the initial IP address was no longer useful: the SMTP server would be instructed to trust the no-longer-usable IP address instead of the new IP address that would in fact be used for the SMTP session that followed. (The same thing could happen with a multihomed client whose preferred link went down due to a fibre cut.) But it's not clear to me that taking down the MPTCP connection would do anything to help here: indeed, I think users would be happier to receive their email and have to "check mail" twice in order to send. > And once MPTCP is out there, I expect app designer to quickly move > to it for protocols that don't work over it from the beginning. There may be legacy apps that nobody wants to re-compile: thus it could make sense for a host-level option to determine whether MPTCP would be used for "legacy" API Open calls. Always in the past, the "dinosaur" apps have persisted on a reasonably limited number of hosts: often "dinosaurs" themselves. ;^) > I agree that (2) would lead to more impact/larger benefits, because > more traffic would be multipath-enabled. The multi-homed and mobility benefits _depend_upon_ the majority of apps making use of MPTCP. > But at the moment, that's not a recommendation we can make. I believe we _could_ run useful experiments with Lars' option-2, with a host-level opt-in. But for the eventual Standards-track MPTCP, we should IMHO design some kind of application-level opt-in/opt-out. (This need not necessarily be part of the Open() call.) > Once people have run experiments with (2) in non-trivial deployments, > we may well find that the set of apps in class B is very small. At > that point, we can still move to approach (2). I think it would be best for the choice of (1) or (2) to be a host-level configuration. That way, the experiments can collect actual data on cases of observed problems. -- John Leslie From fred@cisco.com Sat Aug 8 08:26: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 A9DFA28C112 for ; Sat, 8 Aug 2009 08:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.433 X-Spam-Level: X-Spam-Status: No, score=-105.433 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, 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 jmr88y4p5+Hd for ; Sat, 8 Aug 2009 08:26:58 -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 B67A53A6BCA for ; Sat, 8 Aug 2009 08:26:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF82fUqrR7PD/2dsb2JhbAC1Uogrj3cFhBeKEA X-IronPort-AV: E=Sophos;i="4.43,346,1246838400"; d="scan'208";a="363308681" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 08 Aug 2009 15:27:02 +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 n78FR22s007657; Sat, 8 Aug 2009 08:27:02 -0700 Received: from [192.168.1.100] ([10.21.119.160]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n78FR1tt028954; Sat, 8 Aug 2009 15:27:02 GMT Message-Id: <5C7FDD90-ED66-4CAF-9F2A-418DE3A88435@cisco.com> From: Fred Baker To: Joe Touch In-Reply-To: <4A7B9449.9050901@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 15:08:26 -0700 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=767; t=1249745222; x=1250609222; c=relaxed/simple; s=sjdkim3002; 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=20[multipathtcp]=20MP=20captain=20going=2 0down=20with=20the=20address=20ship,=20was=3A=20Re=3A=20=20O n=20Thursday's=20Multipath=20TCP=20BOF |Sender:=20; bh=ZwYs6wH/mSbsoVhgf91jIuO9tAj225gVMmUWs3VTiOM=; b=N/Vaydc1rsbIpiickAkijdu95I07b8mt0NlrU4K9+jU1EcdZdZ6Ul8MF1C uCfLFtf0sWS4omHZN45RO9+FnnSmC4JLzi/kT7qVpeaNJi/WyzJeKstxEwX1 XdIjVRLJOh; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 15:26:59 -0000 On Aug 6, 2009, at 7:41 PM, Joe Touch wrote: > While I agree that apps should open connections to DNS names, the > common mechanism involves the app querying the DNS, selecting from > among a set of responses, and opening a connection to an IP address. > This sequence is necessary because TCP doesn't connect DNS names > (and ports), it connects IP addresses (and ports). Except that if we had proper APIs, we would give the API the name (which is what the application wants to connect to) and the API would give TCP/etc the address to use - and in this case, the set of addresses. There is no reason for the application to ever know the address, because the only thing that has any concept of the address is two layers below it. From fred@cisco.com Sat Aug 8 08:26: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 BD2663A6BCA for ; Sat, 8 Aug 2009 08:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.438 X-Spam-Level: X-Spam-Status: No, score=-105.438 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, 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 QPVD70928syF for ; Sat, 8 Aug 2009 08:26:59 -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 0BBC93A6BC3 for ; Sat, 8 Aug 2009 08:26:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF82fUqrR7MV/2dsb2JhbAC1Uogrj3cFhBeKEA X-IronPort-AV: E=Sophos;i="4.43,346,1246838400"; d="scan'208";a="363308685" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Aug 2009 15:27:02 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n78FR2l2026078; Sat, 8 Aug 2009 08:27:02 -0700 Received: from [192.168.1.100] ([10.21.119.160]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n78FR1tu028954; Sat, 8 Aug 2009 15:27:02 GMT Message-Id: From: Fred Baker To: Joe Touch In-Reply-To: <4A7B9668.3020008@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 15:11:56 -0700 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> <4A7B9668.3020008@isi.edu> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1022; t=1249745222; x=1250609222; c=relaxed/simple; s=sjdkim1004; 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=20[multipathtcp]=20MP=20captain=20going=2 0down=20with=20the=20address=20ship,=20was=3A=20Re=3A=20=20O n=20Thursday's=20Multipath=20TCP=20BOF |Sender:=20; bh=Mac1k1luuzYvP5Dbnqv9j3oHI/IYjto9YYA1Qcbfb4o=; b=GrNjRu7o3fnshZxEL85afcGzMomcJBM5f2ap4Kx4mW51u4LlF+HLMUuagt U5W0UjH+NmH3FAYWISLSeIOLgCVdSAQ6gvUj9q+1oo+2M1pkcrvsIskLfIfA nUsumNrFJDd2jSaHTpy9uy0jSO5cikRcdcYaKDDWNcktwAJ3Rc9Mo=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 15:26:59 -0000 On Aug 6, 2009, at 7:50 PM, Joe Touch wrote: > Oh, I agree. But that's what I meant when I said that the Internet > doesn't have any notion of a "group of IP addresses" being a single > machine. > > Without that notion, you need the captain to go down with the ship, > because if the captain's gone you don't know you're on the same ship > anymore. I think you're getting the cart somewhat before the horse. "Multipath TCP" (which likely isn't TCP at all, but is some form of multipath transport) absolutely has to understand that a stated set of addresses instantiates a remote machine, and by the way this machine has a set of addresses, and by the way addresses that are not in the relevant set are probably a security consideration. If the desire is that we build such a thing, the requirement is that the internet-as-we-use-it develop a concept of such an association of addresses. Don't lop off the idea because it doesn't exist. Look at what it takes to create it. From fred@cisco.com Sat Aug 8 08:27: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 15BA93A6BC3 for ; Sat, 8 Aug 2009 08:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.443 X-Spam-Level: X-Spam-Status: No, score=-105.443 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, 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 IKm5Vr4is-hN for ; Sat, 8 Aug 2009 08:26:59 -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 4030C28C0E4 for ; Sat, 8 Aug 2009 08:26:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF82fUqrR7PE/2dsb2JhbAC1Uogrj3cFhBc X-IronPort-AV: E=Sophos;i="4.43,346,1246838400"; d="scan'208";a="363308689" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Aug 2009 15:27:02 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n78FR2hq019246; Sat, 8 Aug 2009 08:27:02 -0700 Received: from [192.168.1.100] ([10.21.119.160]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n78FR1tv028954; Sat, 8 Aug 2009 15:27:02 GMT Message-Id: <9B9B6A63-85FD-48F2-BC44-8B2F69EEFDA5@cisco.com> From: Fred Baker To: Iljitsch van Beijnum In-Reply-To: <8A45EEE0-BFFD-410C-8DE8-FA703761FEE6@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 15:18:12 -0700 References: <47ECE9B1-DE9C-4E12-ABCA-287BD8289351@ericsson.com> <7FE6BBA6-0BF4-470B-8AF9-5AE5786ED50E@cisco.com> <8A45EEE0-BFFD-410C-8DE8-FA703761FEE6@muada.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2204; t=1249745222; x=1250609222; c=relaxed/simple; s=sjdkim4002; 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=20[multipathtcp]=20On=20Thursday's=20Mult ipath=20TCP=20BOF |Sender:=20; bh=4stEC/r4aVInDEtnlEvbdTn843uBlVt7y8K0EHUjY8k=; b=kAX335lqvhaKxxPC48PkgkY8/ntfvvbmV60acft8djDeGrcfn8qsAseLdE 9cW04fmzY3+KWWUlTVV4J6h6IYi5ahnO0UzE0bnLjqCFcePiSzAzGxbqxXyh QbAKa31QTp; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 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: Sat, 08 Aug 2009 15:27:00 -0000 On Aug 7, 2009, at 2:15 AM, Iljitsch van Beijnum wrote: > On 30 jul 2009, at 11:11, Fred Baker wrote: > >> 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. > > How would that be better than existing SACK and with normal fast > retransmit executed per path? > > Since the receiver doesn't know over which path a particular piece > of data was sent, or when it was sent, it doesn't really know when > to request a retransmission. If you use the example approach I suggested, it absolutely does. If I know that my peer is sending me cwnd bytes or messages per RTT and I have not received piece SSN-k*cwnd, the larger k is the smaller the probability that I am ever going to receive it. With that algorithm, the question is what value of k is the right crossover point. > For instance, if the piece of data was sent 50 ms ago on a 10 ms > path then obviously a retransmission would make sense but not so > much 50 ms ago on a 250 ms path. well, yes. But more to the point, if I have several paths with 25, 50, and 500 ms RTTs, we're observing that we may only want to use the 25 and 50 ms paths (pruning the long delay path) and might specifically want to retransmit a segment that got no ack in 100 ms. Why not use SACK and fast retransmit? think about the reordered- arrival behavior of a a set of paths with 25 and 50 ms RTT (never mind the 500 one), and how SACK and fast retransmit respond to them. A NACK is more stable. > We do need to solve the problem where one path fails so the last few > packets sent over it will never make it and now that path is waiting > for an RTO or even user timeout, while all the packets on other > paths proceed to fill up the receive buffer. If the receive buffer > can't accommodate for the data sent on alternative paths for an RTO > duration on the failed path this means the working paths will stall. > We try to address that in the one-ended draft with "slow retransmit" > but the problem exists for all multipath stream transports. From cabo@tzi.org Sat Aug 8 08:51: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 268BC3A6BFF for ; Sat, 8 Aug 2009 08:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.805 X-Spam-Level: X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HELO_EQ_DE=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 HyNquKPVR1Lk for ; Sat, 8 Aug 2009 08:51:31 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 0799B3A6E51 for ; Sat, 8 Aug 2009 08:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n78Fp02S020920; Sat, 8 Aug 2009 17:51:00 +0200 (CEST) Received: from [192.168.217.107] (p5489F3D4.dip.t-dialin.net [84.137.243.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 55DE0BDAD; Sat, 8 Aug 2009 17:51:00 +0200 (CEST) From: Carsten Bormann To: Fred Baker In-Reply-To: <5C7FDD90-ED66-4CAF-9F2A-418DE3A88435@cisco.com> 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> <5C7FDD90-ED66-4CAF-9F2A-418DE3A88435@cisco.com> Message-Id: <764EED22-2BD7-422A-9D6A-C3023423FE47@tzi.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: Sat, 8 Aug 2009 17:50:58 +0200 X-Mailer: Apple Mail (2.935.3) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 15:51:32 -0000 On Aug 8, 2009, at 00:08, Fred Baker wrote: > if we had proper APIs Sorry for pointing out the obvious, but it may be worth pointing back to Stuart Cheshire's plenary talk: http://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf page 34 onwards. (Stuart's point here being that the IPv6 migration situation has already made the 1980's programming interfaces obsolete, exactly for the reason that the socket programming interface exposes IP addresses to the program. It could not really have been designed in a different way in 1982/1983 -- DNS was only just starting to exist!) Gruesse, Carsten From touch@ISI.EDU Sat Aug 8 15:19: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 EC7453A69BC for ; Sat, 8 Aug 2009 15:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 tzrvBY4BaZs4 for ; Sat, 8 Aug 2009 15:19:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9AC623A6C57 for ; Sat, 8 Aug 2009 15:19:06 -0700 (PDT) Received: from [75.194.15.54] (54.sub-75-194-15.myvzw.com [75.194.15.54]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n78MID1B009942; Sat, 8 Aug 2009 15:18:16 -0700 (PDT) Message-ID: <4A7DF9A4.8080603@isi.edu> Date: Sat, 08 Aug 2009 15:18:12 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Fred Baker 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> <4A783F60.8070406@isi.edu> <4A7B9449.9050901@isi.edu> <5ABFE334-456E-4FE8-BC11-39BE38B746D0@lurchi.franken.de> <4A7B9668.3020008@isi.edu> 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] MP captain going down with the address ship, 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: Sat, 08 Aug 2009 22:19:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fred Baker wrote: ... > I think you're getting the cart somewhat before the horse. "Multipath > TCP" (which likely isn't TCP at all, but is some form of multipath > transport) absolutely has to understand that a stated set of addresses > instantiates a remote machine, and by the way this machine has a set of > addresses, and by the way addresses that are not in the relevant set are > probably a security consideration. If the desire is that we build such a > thing, the requirement is that the internet-as-we-use-it develop a > concept of such an association of addresses. > > Don't lop off the idea because it doesn't exist. Look at what it takes > to create it. If we're creating it, then please let's use a different protocol number. The only reason my concerns are relevant is how it would change the TCP API, and whether it can be backward compatible. IMO, it simply can't. We can *assume* it is, and find places where that assumption breaks, but that's all we can try to do. If this is about creating a true fix, then let's do that (or didn't we already in HIP, e.g.?) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp9+aQACgkQE5f5cImnZru34QCeIJabMD7KI85oim+zJfNMSVAg rgYAoJY///DDIijNF3u0agbvTl74qR6P =jKWt -----END PGP SIGNATURE----- From brian.e.carpenter@gmail.com Sat Aug 8 17:04: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 AEC923A69D0 for ; Sat, 8 Aug 2009 17:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 LpEYhUcnxMZi for ; Sat, 8 Aug 2009 17:04:08 -0700 (PDT) Received: from mail-pz0-f178.google.com (mail-pz0-f178.google.com [209.85.222.178]) by core3.amsl.com (Postfix) with ESMTP id 1941D3A6B5E for ; Sat, 8 Aug 2009 17:04:01 -0700 (PDT) Received: by pzk8 with SMTP id 8so2385775pzk.31 for ; Sat, 08 Aug 2009 17:04:03 -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=U/w2BV/vKnO/nIhKfZMQdBcYdkHjjB4vhf+c/Ya+Alk=; b=sEQNswV7OZY2sg+dExepESLxhY+rFWsd3LW57aRqjxL0+UYS77M/kbDt+G0z5Or+BI eIvd9YtIOnAt1qsTzGRGnH0ANGftcDrhYG8RP3ch6rwL/idHcERet4vHODh39ozS31eK qJ+xpyX6BLJfuT93QnVw4Hr7FuOVaLULaHEpg= 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=PB59p1WitWYtYLmvbkHHejB+SrRmgiz6J0kytwjgPrgCDi+GxmgLZiTcyKLub5rXSX mpqaBhWwiZNmFxaJmCjVjuyK0Dtdl4qzm4aREmTE1mlRqJ45iAGybSWcpgvcL5gtY9cq YgP884r/AISHWVB3vZEocxrL+PgP3A6IRFTgs= Received: by 10.114.77.19 with SMTP id z19mr3946188waa.61.1249776243003; Sat, 08 Aug 2009 17:04:03 -0700 (PDT) Received: from ?10.1.1.4? (118-92-209-139.dsl.dyn.ihug.co.nz [118.92.209.139]) by mx.google.com with ESMTPS id v25sm4352419wah.11.2009.08.08.17.03.59 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Aug 2009 17:04:01 -0700 (PDT) Message-ID: <4A7E1262.2050302@gmail.com> Date: Sun, 09 Aug 2009 12:03:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lars Eggert References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] More general congestion control linking 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, 09 Aug 2009 00:04:09 -0000 I've been wondering how experience with GridFTP relates to all this. Googling for gridftp performance congestion gives quite a few interesting results, including http://damsl.cis.udel.edu/projects/phoebus/phoebus_gridftp.pdf There are measurements on some serious running code there. Brian From C.Raiciu@cs.ucl.ac.uk Mon Aug 10 05:10: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 5059A3A69D7 for ; Mon, 10 Aug 2009 05:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=1.332, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 sT9EK2D9hBwy for ; Mon, 10 Aug 2009 05:10:49 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by core3.amsl.com (Postfix) with SMTP id 993B93A68DF for ; Mon, 10 Aug 2009 05:10:48 -0700 (PDT) Received: from bells3.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 10 Aug 2009 13:10:44 +0100 Received: from prayer by bells3.cs.ucl.ac.uk with local (Exim 4.54) id 1MaTgY-000Fkp-O1; Mon, 10 Aug 2009 13:09:06 +0100 From: C.Raiciu@cs.ucl.ac.uk To: =?ISO-8859-1?Q?Michael_T=FCxen?= Date: 10 Aug 2009 13:09:06 +0100 X-Mailer: Prayer v1.0.16 X-Originating-IP: [92.81.235.65] In-Reply-To: <935655A5-08A7-4122-B376-40FBB29B5142@lurchi.franken.de> Message-ID: 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> <4A783F60.8070406@isi.edu> <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> <935655A5-08A7-4122-B376-40FBB29B5142@lurchi.franken.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Mon, 10 Aug 2009 12:10:50 -0000 Hi, The main reason for not using CMT is that it works with SCTP and SCTP=20 doesn't work with NATs. The single sequence space is actually more of a "legacy" thing in CMT,=20 borrowed from SCTP - according to Jana's comments in a discussion we had in= =20 Stockholm. It turns out one gets many benefits from multiple sequence spaces. In=20 addition, the single sequence space does NOT always ensure the sender can= =20 tell which path delivered a packet. For details why we chose two sequence= =20 spaces instead of one see the deisgn decisions document:=20 http://www.cs.ucl.ac.uk/staff/C.Raiciu/files/mtcp-design.pdf Cheers, Costin=20 On Aug 8 2009, Michael T=FCxen wrote: >On Aug 8, 2009, at 9:57 AM, Lars Eggert wrote: > >> Hi, >> >> On 2009-8-7, at 17:55, Randall Stewart wrote: >>> Thats not necessarily true. Janardhan Iyengar published quite a bit >>> of work on Conncurrent Multipath Transport (CMT)... which uses all =20 >>> paths >>> i.e. your multi-path TCP. For some reason I have not seen any of =20 >>> your work >>> mention or look at what he did in that body of work... It is =20 >>> currently >>> implemented in FreeBSD and the only thing lacking is a internet =20 >>> draft/RFC... >> >> CMT was brought up several times in the discussion on- and off-list. =20 >> And I at least was under the impression that the reason it wasn't in =20 >> an ID yet is that the coupled congestion control bit wasn't worked =20 >> out yet for CMT? >That is right. But one can use the CC suggested by Mark. What CMT >also provides are the procedures describing how to live with one >sequence number space for all paths. >Unlike MPTCP, which has a separate sequence number >space for all paths... > >Best regards >Michael >> >> Lars_______________________________________________ >> 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 Michael.Tuexen@lurchi.franken.de Mon Aug 10 05: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 1E5B93A6881 for ; Mon, 10 Aug 2009 05:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.242 X-Spam-Level: ** X-Spam-Status: No, score=2.242 tagged_above=-999 required=5 tests=[AWL=0.204, 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 Fh3gcOJhSkx7 for ; Mon, 10 Aug 2009 05:36:14 -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 BF06A3A6784 for ; Mon, 10 Aug 2009 05:36:13 -0700 (PDT) Received: from [192.168.1.100] (p508FEBBD.dip.t-dialin.net [80.143.235.189]) by mail-n.franken.de (Postfix) with ESMTP id 1C3031C0B4613; Mon, 10 Aug 2009 14:36:13 +0200 (CEST) Message-Id: <406A0855-A394-4C16-94EB-775EA05B0AA3@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: C.Raiciu@cs.ucl.ac.uk 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 v936) Date: Mon, 10 Aug 2009 14:36:12 +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> <4A783F60.8070406@isi.edu> <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> <935655A5-08A7-4122-B376-40FBB29B5142@lurchi.franken.de> X-Mailer: Apple Mail (2.936) Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Mon, 10 Aug 2009 12:36:15 -0000 On Aug 10, 2009, at 2:09 PM, C.Raiciu@cs.ucl.ac.uk wrote: > Hi, > > The main reason for not using CMT is that it works with SCTP and =20 > SCTP doesn't work with NATs. ... you could use SCTP/UDP/IP, which is supported by legacy NATs. The =20= problem not solved by CMT is the shared bottleneck detection. But is not not a =20= problem when using Marks CC... > > The single sequence space is actually more of a "legacy" thing in =20 > CMT, borrowed from SCTP - according to Jana's comments in a =20 > discussion we had in Stockholm. > > It turns out one gets many benefits from multiple sequence spaces. =20 > In addition, the single sequence space does NOT always ensure the =20 > sender can tell which path delivered a packet. For details why we =20 > chose two sequence spaces instead of one see the deisgn decisions =20 > document: http://www.cs.ucl.ac.uk/staff/C.Raiciu/files/mtcp-design Maybe I was not clear. I think having separate sequence number spaces =20= helps in multipath transport. I just wanted to point out that CMT in SCTP has to deal with the problem of having only one sequence number space, a =20 problem MPTCP does not have. > .pdf > > Cheers, > Costin > On Aug 8 2009, Michael T=FCxen wrote: > >> On Aug 8, 2009, at 9:57 AM, Lars Eggert wrote: >> >>> Hi, >>> >>> On 2009-8-7, at 17:55, Randall Stewart wrote: >>>> Thats not necessarily true. Janardhan Iyengar published quite a bit >>>> of work on Conncurrent Multipath Transport (CMT)... which uses =20 >>>> all paths >>>> i.e. your multi-path TCP. For some reason I have not seen any of =20= >>>> your work >>>> mention or look at what he did in that body of work... It is =20 >>>> currently >>>> implemented in FreeBSD and the only thing lacking is a internet =20= >>>> draft/RFC... >>> >>> CMT was brought up several times in the discussion on- and off-=20 >>> list. And I at least was under the impression that the reason it =20= >>> wasn't in an ID yet is that the coupled congestion control bit =20 >>> wasn't worked out yet for CMT? >> That is right. But one can use the CC suggested by Mark. What CMT >> also provides are the procedures describing how to live with one >> sequence number space for all paths. >> Unlike MPTCP, which has a separate sequence number >> space for all paths... >> >> Best regards >> Michael >>> >>> Lars_______________________________________________ >>> 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 iljitsch@muada.com Tue Aug 11 04:19:48 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 79A803A709F for ; Tue, 11 Aug 2009 04:19:48 -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 OQgasV7N0cc8 for ; Tue, 11 Aug 2009 04:19:47 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 721C53A7088 for ; Tue, 11 Aug 2009 04:19:47 -0700 (PDT) Received: from [87.76.102.57] (Iljitsch-iPhone.visitors.har2009.net [87.76.102.57]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7BBIQPw004106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 13:18:27 +0200 (CEST) (envelope-from iljitsch@muada.com) 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> <4A783F60.8070406@isi.edu> <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> <935655A5-08A7-4122-B376-40FBB29B5142@lurchi.franken.de> Message-Id: From: Iljitsch van Beijnum To: "C.Raiciu@cs.ucl.ac.uk" In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Date: Tue, 11 Aug 2009 13:19:11 +0200 Cc: Multipath TCP Mailing List , Joe Touch Subject: Re: [multipathtcp] MP captain going down with the address ship, 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: Tue, 11 Aug 2009 11:19:48 -0000 On 10 aug 2009, at 14:09, C.Raiciu@cs.ucl.ac.uk wrote: > It turns out one gets many benefits from multiple sequence spaces. I disagree. It's a terrible hack. > In addition, the single sequence space does NOT always ensure the > sender can tell which path delivered a packet. When a packet is retransmitted over another path then an ACK doesn't tell you which instance made it. Not a big deal IMO but if it is, a two-ended MPTCP can easily indicate that a packet is a retransmission / ACK of a retransmission in an option. > Iljitsch From janardhan.iyengar@fandm.edu Wed Aug 12 15:26: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 2A6D03A6948 for ; Wed, 12 Aug 2009 15:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 2azgRsTLUU7P for ; Wed, 12 Aug 2009 15:26:44 -0700 (PDT) Received: from zimfe2.fandm.edu (zimfe2.fandm.edu [155.68.1.75]) by core3.amsl.com (Postfix) with ESMTP id CB0BA3A6924 for ; Wed, 12 Aug 2009 15:26:40 -0700 (PDT) Received: from surutti.fandm.edu (93-158-10-239.subs.ibrowse.com [93.158.10.239]) by zimfe2.fandm.edu (Postfix) with ESMTP id 0F06F116938C; Wed, 12 Aug 2009 18:24:03 -0400 (EDT) Message-ID: <4A834100.1030103@fandm.edu> Date: Thu, 13 Aug 2009 00:24:00 +0200 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= 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> <4A783F60.8070406@isi.edu> <66B8D216-016F-4041-8C89-ABCF12BDE6CD@lakerest.net> <64241308-70D9-4A27-969F-E4E9C4E4D6F4@nokia.com> <935655A5-08A7-4122-B376-40FBB29B5142@lurchi.franken.de> <406A0855-A394-4C16-94EB-775EA05B0AA3@lurchi.franken.de> In-Reply-To: <406A0855-A394-4C16-94EB-775EA05B0AA3@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Multipath TCP Mailing List , C.Raiciu@cs.ucl.ac.uk Subject: Re: [multipathtcp] MP captain going down with the address ship, was: Re: On Thursday's Multipath TCP BOF 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: Wed, 12 Aug 2009 22:26:45 -0000 Hi all, I haven't read all the email on the list, but I wanted to quickly respond to a couple of points that I read in my skim of a couple of threads (I am traveling). Apologies if I'm repeating what's already been said: 1/ Yes, we would like to incorporate the CC work from MPTCP into CMT, and turn it into a draft. Which is why that should be a separate doc in the MPTCP suite of docs. 2/ CMT has been implemented and it is a part of the SCTP implementation for FreeBSD. 3/ Single sequence space was an active choice for CMT: you can get CMT without a single on-the-wire change to SCTP, which was a goal. And, no receiver mods are required either. CMT will work on a multihomed SCTP association, with zero SCTP receiver modifications. 4/ One of the benefits of having HeartBeats in SCTP is that you can use HBs to distinguish between different paths when trying to determine which one is working. When you don't have HBs, as with TCP, you have to use data for probing, and you *need* to use a separate sequence space as Costin mentions for determining which path delivered a packet. 5/ If you can get SCTP through a NAT, CMT will get through as well; CMT makes no on-the-wire changes to SCTP. Thanks, - jana Michael Tüxen wrote: > On Aug 10, 2009, at 2:09 PM, C.Raiciu@cs.ucl.ac.uk wrote: > >> Hi, >> >> The main reason for not using CMT is that it works with SCTP and SCTP >> doesn't work with NATs. > ... you could use SCTP/UDP/IP, which is supported by legacy NATs. The > problem > not solved by CMT is the shared bottleneck detection. But is not not a > problem > when using Marks CC... >> >> The single sequence space is actually more of a "legacy" thing in CMT, >> borrowed from SCTP - according to Jana's comments in a discussion we >> had in Stockholm. >> >> It turns out one gets many benefits from multiple sequence spaces. In >> addition, the single sequence space does NOT always ensure the sender >> can tell which path delivered a packet. For details why we chose two >> sequence spaces instead of one see the deisgn decisions document: >> http://www.cs.ucl.ac.uk/staff/C.Raiciu/files/mtcp-design > Maybe I was not clear. I think having separate sequence number spaces helps > in multipath transport. I just wanted to point out that CMT in SCTP has > to deal with the problem of having only one sequence number space, a > problem > MPTCP does not have. >> .pdf >> >> Cheers, >> Costin >> On Aug 8 2009, Michael Tüxen wrote: >> >>> On Aug 8, 2009, at 9:57 AM, Lars Eggert wrote: >>> >>>> Hi, >>>> >>>> On 2009-8-7, at 17:55, Randall Stewart wrote: >>>>> Thats not necessarily true. Janardhan Iyengar published quite a bit >>>>> of work on Conncurrent Multipath Transport (CMT)... which uses all >>>>> paths >>>>> i.e. your multi-path TCP. For some reason I have not seen any of >>>>> your work >>>>> mention or look at what he did in that body of work... It is >>>>> currently >>>>> implemented in FreeBSD and the only thing lacking is a internet >>>>> draft/RFC... >>>> >>>> CMT was brought up several times in the discussion on- and >>>> off-list. And I at least was under the impression that the reason >>>> it wasn't in an ID yet is that the coupled congestion control bit >>>> wasn't worked out yet for CMT? >>> That is right. But one can use the CC suggested by Mark. What CMT >>> also provides are the procedures describing how to live with one >>> sequence number space for all paths. >>> Unlike MPTCP, which has a separate sequence number >>> space for all paths... >>> >>> Best regards >>> Michael >>>> >>>> Lars_______________________________________________ >>>> 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 >>> >> > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From bhooma@apple.com Fri Aug 14 11:45: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 E06ED3A6D43 for ; Fri, 14 Aug 2009 11:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 oSRGsxuNx636 for ; Fri, 14 Aug 2009 11:45:52 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 497333A6D27 for ; Fri, 14 Aug 2009 11:45:52 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 0A7A871E45F3 for ; Fri, 14 Aug 2009 11:45:57 -0700 (PDT) X-AuditID: 1180711d-b7c7aae0000053b3-1a-4a85b0e42bfe Received: from il0204d-dhcp22.apple.com (il0204d-dhcp22.apple.com [17.202.46.22]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 1F.00.21427.4E0B58A4; Fri, 14 Aug 2009 11:45:56 -0700 (PDT) From: Padma Bhooma Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Fri, 14 Aug 2009 11:45:56 -0700 Message-Id: <7502F8BA-A32F-4523-B286-5739F177C05A@apple.com> To: multipathtcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Subject: [multipathtcp] receive window considerations 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, 14 Aug 2009 18:45:53 -0000 Hello, I have a couple of questions about receive window management across multiple sub flows. The draft (draft-ford-mptcp-multiaddressed-01) says that receive window will be shared across the sub flows. If some of the later sub flows (in sequence space) fill up the receiver's socket buffer, the receive window seen by earlier sub flows will become smaller. This might increase the delay seen by an application. How will fragmentation in socket buffer be handled? Will the receive window be the total un-filled memory left or will it be the next hole to be filled? I am sorry if I missed any discussion related to this and I will appreciate any pointer to such discussion. Thanks, Padma From c.raiciu@cs.ucl.ac.uk Tue Aug 18 00:12: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 7FBCC3A6914 for ; Tue, 18 Aug 2009 00:12:19 -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 rmudzDi7TRA1 for ; Tue, 18 Aug 2009 00:12:18 -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 9BCC73A6A90 for ; Tue, 18 Aug 2009 00:12:18 -0700 (PDT) Received: from [212.121.255.27] (helo=[172.16.249.133]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1MdIQ1-000MNG-JS; Tue, 18 Aug 2009 07:43:42 +0100 In-Reply-To: <7502F8BA-A32F-4523-B286-5739F177C05A@apple.com> References: <7502F8BA-A32F-4523-B286-5739F177C05A@apple.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38047EDD-7536-4022-B893-F1FC2AA77A07@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Sat, 15 Aug 2009 21:00:50 +0300 To: Padma Bhooma X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] receive window considerations 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, 18 Aug 2009 07:12:19 -0000 Hi, I am not sure I completely understand your question(s), but here's the way I see receiver window issues. The receiver window specifies at connection level how much data the receiver is willing to accept past the (data level )cumulative ack. If data is received that is not in order, this cannot be passed to the application until earlier data arrives; this means that if there is a hole, the receive window will not move on. It will only move on when the (data level) cumulative ack moves on. This single receive window, computed probably from the amount of memory available to the socket (but never shrank once offered, as in Linux kernel implementations), is advertised to the remote end on all subflows. Each subflow now carries a receive window that makes sense at connection level, and that tells the receiver what to accept. How (and if) this same receive window is used to *validate* subflow sequence numbers is open to discussion. Clearly, on any given subflow, the sender must not send more data than allowed by the connection level receive window.This means we can use the same receive window to drop packets with out-of-window subflow sequence number. Cheers Costin On 14 Aug 2009, at 21:45, Padma Bhooma wrote: > Hello, > > I have a couple of questions about receive window management across > multiple sub flows. The draft (draft-ford-mptcp-multiaddressed-01) > says that receive window will be shared across the sub flows. If > some of the later sub flows (in sequence space) fill up the > receiver's socket buffer, the receive window seen by earlier sub > flows will become smaller. This might increase the delay seen by an > application. > > How will fragmentation in socket buffer be handled? Will the > receive window be the total un-filled memory left or will it be the > next hole to be filled? > > I am sorry if I missed any discussion related to this and I will > appreciate any pointer to such discussion. > > Thanks, > Padma_______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From bhooma@apple.com Fri Aug 21 06:48: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 90D603A6845 for ; Fri, 21 Aug 2009 06:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 2N9ly4nv77no for ; Fri, 21 Aug 2009 06:48:42 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id BE8C33A698B for ; Fri, 21 Aug 2009 06:48:42 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id B2DC56EDEE01; Fri, 21 Aug 2009 06:48:48 -0700 (PDT) X-AuditID: 11807130-b7bdfae000004bc9-30-4a8ea5c0b4b2 Received: from [17.151.78.169] (Unknown_Domain [17.151.78.169]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id C3.88.19401.0C5AE8A4; Fri, 21 Aug 2009 06:48:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Padma Bhooma In-Reply-To: <38047EDD-7536-4022-B893-F1FC2AA77A07@cs.ucl.ac.uk> Date: Fri, 21 Aug 2009 06:48:47 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7622036B-C0C0-4345-A89F-B7385C97AA13@apple.com> References: <7502F8BA-A32F-4523-B286-5739F177C05A@apple.com> <38047EDD-7536-4022-B893-F1FC2AA77A07@cs.ucl.ac.uk> To: Costin Raiciu X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] receive window considerations 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, 21 Aug 2009 13:48:43 -0000 Hi, Thanks for clarifying this for me. Since the cumulative-ack was described as sub flow level ack, I was not clear about receive window. But it is possible to compute the data level cumulative ack and make sense out of the receive window. I think one question is to decide how to stripe the available data in the sender's buffer across multiple sub flows. Will it be one packet worth of data at a time or will the socket buffer be divided across the sub flows based on the bandwidth available on that connection. Both of them will work but I am just curious to know if you have decided on one of these two methods or some other method.. Thanks, Padma On Aug 15, 2009, at 11:00 AM, Costin Raiciu wrote: > Hi, > > I am not sure I completely understand your question(s), but here's > the way I see receiver window issues. > > The receiver window specifies at connection level how much data the > receiver is willing to accept past the (data level )cumulative ack. > If data is received that is not in order, this cannot be passed to > the application until earlier data arrives; this means that if there > is a hole, the receive window will not move on. It will only move on > when the (data level) cumulative ack moves on. This single receive > window, computed probably from the amount of memory > available to the socket (but never shrank once offered, as in Linux > kernel implementations), is advertised to the remote end on all > subflows. > > Each subflow now carries a receive window that makes sense at > connection level, and that tells the receiver what to accept. How > (and if) this same receive window is used to *validate* subflow > sequence numbers is open to discussion. > Clearly, on any given subflow, the sender must not send more data > than allowed by the connection level receive window.This means we > can use the same receive window to drop packets with out-of-window > subflow sequence number. > > Cheers > Costin > > > On 14 Aug 2009, at 21:45, Padma Bhooma wrote: > >> Hello, >> >> I have a couple of questions about receive window management across >> multiple sub flows. The draft (draft-ford-mptcp-multiaddressed-01) >> says that receive window will be shared across the sub flows. If >> some of the later sub flows (in sequence space) fill up the >> receiver's socket buffer, the receive window seen by earlier sub >> flows will become smaller. This might increase the delay seen by an >> application. >> >> How will fragmentation in socket buffer be handled? Will the >> receive window be the total un-filled memory left or will it be the >> next hole to be filled? >> >> I am sorry if I missed any discussion related to this and I will >> appreciate any pointer to such discussion. >> >> Thanks, >> Padma_______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > From maysam.yabandeh@epfl.ch Sun Aug 23 12:31: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 D33D33A694A for ; Sun, 23 Aug 2009 12:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 7PgnR417amh9 for ; Sun, 23 Aug 2009 12:31:51 -0700 (PDT) Received: from smtp3.epfl.ch (smtp3.epfl.ch [128.178.224.226]) by core3.amsl.com (Postfix) with SMTP id EF4673A672E for ; Sun, 23 Aug 2009 12:31:50 -0700 (PDT) Received: (qmail 27432 invoked by uid 107); 23 Aug 2009 19:31:53 -0000 X-Virus-Scanned: ClamAV Received: from ditsbsrv7.epfl.ch (128.178.50.85) by smtp3.epfl.ch (AngelmatoPhylax SMTP proxy); Sun, 23 Aug 2009 21:31:53 +0200 Received: from ditsbsrv7.epfl.ch (localhost.localdomain [127.0.0.1]) by ditsbsrv7.epfl.ch (8.13.8/8.13.8) with ESMTP id n7NJVrSd001502 for ; Sun, 23 Aug 2009 21:31:53 +0200 Received: (from apache@localhost) by ditsbsrv7.epfl.ch (8.13.8/8.13.8/Submit) id n7NJVmCM001498 for multipathtcp@ietf.org; Sun, 23 Aug 2009 21:31:48 +0200 Received: from tsf-wpa-1-182.epfl.ch (tsf-wpa-1-182.epfl.ch [128.178.251.182]) by webmail.epfl.ch (Horde Framework) with HTTP; Sun, 23 Aug 2009 21:31:48 +0200 Message-ID: <20090823213148.10293jesddurdzqc@webmail.epfl.ch> Date: Sun, 23 Aug 2009 21:31:48 +0200 From: maysam.yabandeh@epfl.ch To: multipathtcp@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) X-EPFL-User: maysam.yabandeh@EPFL X-Scanned-By: MIMEDefang 2.63 on 128.178.50.85 Subject: [multipathtcp] Multipath IP for single-home sources 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, 23 Aug 2009 19:35:09 -0000 Hi, Do we really need multipath TCP? Can not we address the problem simply at the IP layer? Consider the scenario of a single sender which has two paths to the destination with average latency of l1 and l2 (l2 > l1). The IP layer needs to alternate the packets between these two paths; t1 (t2) is the time the outgoing packets are redirected to first (second) path. If t2 > (l2-l1), then the unnecessary fast-retransmits/recovery events are avoided automatically. The secret is that the interleaved receptions of the packets at the destination does not trigger the fast-retransmits/recovery timer, even though the packets are received reordered. The details can be read at pages 3276-3278, Section 6.2 of this paper: "Improving performance of transport protocols in multipath transferring schemes" available at http://dx.doi.org/10.1016/j.comcom.2007.02.017 Regards, Maysam Yabandeh PS: If you do not have access to the paper, a preliminary version of the paper is also accessible at this address: http://web.ut.ac.ir/routerlab/members/yabandeh/journal-reordering-v1.1.pdf From iljitsch@muada.com Mon Aug 24 08:05:56 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 8AC593A6D43 for ; Mon, 24 Aug 2009 08:05:56 -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 oiTq1k+KQQHi for ; Mon, 24 Aug 2009 08:05:52 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1AA3A6E2C for ; Mon, 24 Aug 2009 08:05:52 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7OF5Dkp000958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Aug 2009 17:05:13 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Padma Bhooma In-Reply-To: <7502F8BA-A32F-4523-B286-5739F177C05A@apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Aug 2009 17:05:44 +0200 References: <7502F8BA-A32F-4523-B286-5739F177C05A@apple.com> X-Mailer: Apple Mail (2.936) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] receive window considerations 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, 24 Aug 2009 15:05:56 -0000 On 14 aug 2009, at 20:45, Padma Bhooma wrote: > How will fragmentation in socket buffer be handled? Will the receive > window be the total un-filled memory left or will it be the next > hole to be filled? The receive buffer makes it possible for the sender to send data for at least some time while the application isn't accepting the data. Because a stream protocol like TCP requires the data to be delivered to the application in the same order as it was sent, the receive buffer will fill up when a segment is lost. If n was lost, n+1, n +2, ... can't be delivered to the application until n has been retransmitted successfully. In order to maintain compatibility with existing applications, the above must be true for a multipath TCP the same way it is for existing TCP. The problem with multipath TCP is that if one path has a loss, this will create a hole in the data stream so subsequent segments have to remain in the receive buffer. If the missing segment isn't retransmitted quickly, the receive buffer will fill up and the entire session will stall, even though one or more subflows are progressing without trouble. For normal losses fast retransmit will solve the problem for the most part, of if not fast retransmit, then a normal retransmission after a small delay. However, if one path is broken the session will enter a state where there is very little progress until the broken path is taken down. To avoid any slowdowns because of all of this, the one-ended MPTCP draft has a "slow retransmit" algorithm that retransmits the missing data before the receive buffer fills up. http://tools.ietf.org/html/draft-van-beijnum-1e-mp-tcp-00 From iljitsch@muada.com Mon Aug 24 08:19: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 B25203A6E26 for ; Mon, 24 Aug 2009 08:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 uv-LV0pU-QkZ for ; Mon, 24 Aug 2009 08:19:29 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 8923C3A6E62 for ; Mon, 24 Aug 2009 08:19:07 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7OFIVTg001041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Aug 2009 17:18:32 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <480FBA16-C4A1-44B9-A141-4F9B1553C5F9@muada.com> From: Iljitsch van Beijnum To: maysam.yabandeh@epfl.ch In-Reply-To: <20090823213148.10293jesddurdzqc@webmail.epfl.ch> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Aug 2009 17:19:02 +0200 References: <20090823213148.10293jesddurdzqc@webmail.epfl.ch> X-Mailer: Apple Mail (2.936) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath IP for single-home sources 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, 24 Aug 2009 15:19:29 -0000 On 23 aug 2009, at 21:31, maysam.yabandeh@epfl.ch wrote: > Do we really need multipath TCP? Can not we address the problem > simply at the IP layer? That would only be helpful if we don't have to duplicate TCP state in the IP layer. As far as I can tell from your paper, you want the IP layer to distribute the packets over the paths such that fast retransmit is avoided. This can only be done by at the very least tracking per-destination state, but probably requires per-session state. Introducing this state into the IP layer is a duplication of effort because it already exists in the TCP layer. Also, in the TCP layer we can simply ignore the conditions that would normally trigger fast retransmit if they are merely caused by the use of multiple paths, so we can know for sure what we need to do, rather than one layer tricking another into exhibiting the desired behavior. From Scott.Brim@gmail.com Mon Aug 24 08:47: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 687203A6E0E for ; Mon, 24 Aug 2009 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 iK6UOM1xfOD0 for ; Mon, 24 Aug 2009 08:47:51 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 75CBA3A686E for ; Mon, 24 Aug 2009 08:47:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAA9TkkpAZnmf/2dsb2JhbACRWq0zhxSPZIQaBQ X-IronPort-AV: E=Sophos;i="4.44,266,1249257600"; d="scan'208";a="55295078" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2009 15:47:57 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7OFlvTl002830 for ; Mon, 24 Aug 2009 11:47:57 -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 n7OFlvMd013878 for ; Mon, 24 Aug 2009 15:47:57 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, 24 Aug 2009 11:47:56 -0400 Received: from cisco.com ([10.86.255.11]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 11:47:56 -0400 Date: Mon, 24 Aug 2009 11:47:50 -0400 From: Scott Brim To: Multipath TCP Mailing List Message-ID: <20090824154750.GE19260@cisco.com> Mail-Followup-To: Scott Brim , Multipath TCP Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 24 Aug 2009 15:47:56.0432 (UTC) FILETIME=[3FB94900:01CA24D2] Authentication-Results: rtp-dkim-2; header.From=Scott.Brim@gmail.com; dkim=neutral Subject: [multipathtcp] BOF minutes 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: Mon, 24 Aug 2009 15:47:52 -0000 (finally) http://www.ietf.org/proceedings/75/minutes/mptcp.txt Scott From m.yabandeh@gmail.com Mon Aug 24 08:48: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 1091C28C232 for ; Mon, 24 Aug 2009 08:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 6-nC-6YmHaVq for ; Mon, 24 Aug 2009 08:48:21 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id 4148128C23E for ; Mon, 24 Aug 2009 08:48:21 -0700 (PDT) Received: by ywh4 with SMTP id 4so3281211ywh.17 for ; Mon, 24 Aug 2009 08:48:24 -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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=fgNpfwtMpBvVmn4hA+lo3leAeVwV2+dfFZqdFIMiZxQ=; b=qB7+GhYl9jkqC0ML7mAJgxZOyi5z+TlERfZDqNGXLsCWQlebCltUtR/D/pey0t9tfK nM3Hzyb1XVwjh4B1Cf3PQzdwh18XVPqJEduvymC6BeHJK+9scIfsHmhj3RHhMXhG14pv kglwjaVmMgsJU3QFYzCL3Ig16JG1bD3ZvydA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JEbb3x5vwRWUiPoG9IYWPnsDNhCLJBnJhgjPe82J9h3ujCP5lXnR9iIHKv7T1B/sKW AP85hXXHlPZzUF1eLJsDNAkS+XJnaeTWFtVX96sM8gNrJadYusX/taPNX+os7WJfGOeH C6ZggseWxTS+LAqC8IHZQ4jbd2v2dtyHlwUM8= MIME-Version: 1.0 Sender: m.yabandeh@gmail.com Received: by 10.100.56.17 with SMTP id e17mr4823033ana.100.1251128904681; Mon, 24 Aug 2009 08:48:24 -0700 (PDT) In-Reply-To: <480FBA16-C4A1-44B9-A141-4F9B1553C5F9@muada.com> References: <20090823213148.10293jesddurdzqc@webmail.epfl.ch> <480FBA16-C4A1-44B9-A141-4F9B1553C5F9@muada.com> Date: Mon, 24 Aug 2009 17:48:24 +0200 X-Google-Sender-Auth: 4b6db0592b93e00c Message-ID: From: Maysam Yabandeh To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath IP for single-home sources 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, 24 Aug 2009 15:49:47 -0000 On Mon, Aug 24, 2009 at 5:19 PM, Iljitsch van Beijnum wrote: > On 23 aug 2009, at 21:31, maysam.yabandeh@epfl.ch wrote: > >> Do we really need multipath TCP? Can not we address the problem simply at >> the IP layer? > > That would only be helpful if we don't have to duplicate TCP state in the IP > layer. As far as I can tell from your paper, you want the IP layer to > distribute the packets over the paths such that fast retransmit is avoided. > This can only be done by at the very least tracking per-destination state, > but probably requires per-session state. Introducing this state into the IP > layer is a duplication of effort because it already exists in the TCP layer. > You have a valid point. However, the only state the IP layer needs to keep is latency of the paths and the last time a packet is forwarded to them. It is true that it is kind of duplication, but some people think that i) the amount of extra states are negligible and ii) it would be a neater solution compared to updating TCP layer, specially that the mentioned changes to the IP layer must be limited to a few lines. > Also, in the TCP layer we can simply ignore the conditions that would > normally trigger fast retransmit if they are merely caused by the use of > multiple paths, so we can know for sure what we need to do, rather than one > layer tricking another into exhibiting the desired behavior. > It could be true, if we knew for sure that the condition has triggered because of multipath effect and not other normal reasons. Differentiating between these two is not easy and adds extra complexities to the TCP layer. Regards, Maysam Yabandeh From iljitsch@muada.com Tue Aug 25 02:30: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 C83263A67B7 for ; Tue, 25 Aug 2009 02:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 2s3lEJoN+5Gl for ; Tue, 25 Aug 2009 02:30:51 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id BB12328C18D for ; Tue, 25 Aug 2009 02:30:50 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7P9UEUK008627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Aug 2009 11:30:15 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <6D98F4E5-1E59-443A-9372-1E634DD26365@muada.com> From: Iljitsch van Beijnum To: Maysam Yabandeh 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 v936) Date: Tue, 25 Aug 2009 11:30:46 +0200 References: <20090823213148.10293jesddurdzqc@webmail.epfl.ch> <480FBA16-C4A1-44B9-A141-4F9B1553C5F9@muada.com> X-Mailer: Apple Mail (2.936) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath IP for single-home sources 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, 25 Aug 2009 09:30:51 -0000 On 24 aug 2009, at 17:48, Maysam Yabandeh wrote: > You have a valid point. However, the only state the IP layer needs to > keep is latency of the paths and the last time a packet is forwarded > to them. It is true that it is kind of duplication, but some people > think that i) the amount of extra states are negligible and ii) it > would be a neater solution compared to updating TCP layer, specially > that the mentioned changes to the IP layer must be limited to a few > lines. Not sure if the IP changes are that simple: you would need a good way to measure RTTs. RTTs are always variable because of normal burstiness but also depend on packet size. So this is not entirely trivial. Another issue is that the requirement to avoid fast retransmit limits the possible distributions of the packets, so an IP-based solution can't be as flexible shifting traffic away from congested paths as a TCP-based solution. The only advantage that I see of an IP-based solution is that it could be implemented in routers or middleboxes. >> Also, in the TCP layer we can simply ignore the conditions that would >> normally trigger fast retransmit if they are merely caused by the >> use of >> multiple paths, so we can know for sure what we need to do, rather >> than one >> layer tricking another into exhibiting the desired behavior. > It could be true, if we knew for sure that the condition has triggered > because of multipath effect and not other normal reasons. > Differentiating between these two is not easy and adds extra > complexities to the TCP layer. With SACK we know which packet was acknoweledged and if we remember which path that packet was sent over, we can do fast retransmit for each path separately. See the one-ended multipath TCP draft.