From Internet-Drafts@ietf.org Fri Jan 7 14:15:02 2011 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 7A78428C100; Fri, 7 Jan 2011 14:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW-mtPPBybAr; Fri, 7 Jan 2011 14:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8423A694D; Fri, 7 Jan 2011 14:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110107221501.12322.92659.idtracker@localhost> Date: Fri, 07 Jan 2011 14:15:01 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-congestion-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : Coupled Congestion Control for Multipath Transport Protocols Author(s) : C. Raiciu, et al. Filename : draft-ietf-mptcp-congestion-01.txt Pages : 12 Date : 2011-01-07 Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as TCP New Reno independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, hence achieving resource pooling. This would increase the overall utilization of the network and also its robustness to failure. This document presents a congestion control algorithm which couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggresiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-congestion-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mptcp-congestion-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-07140154.I-D@ietf.org> --NextPart-- From lars.eggert@nokia.com Tue Jan 11 00:48:11 2011 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 886FA3A6A17 for ; Tue, 11 Jan 2011 00:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.623 X-Spam-Level: X-Spam-Status: No, score=-108.623 tagged_above=-999 required=5 tests=[AWL=1.976, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0zLJ8n-Rf-C for ; Tue, 11 Jan 2011 00:48:10 -0800 (PST) Received: from mgw-da01.nokia.com (mgw-da01.ext.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id F3F893A69BF for ; Tue, 11 Jan 2011 00:48:09 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0B8oNGE016113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Jan 2011 10:50:24 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-38-748524264; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 11 Jan 2011 10:50:20 +0200 In-Reply-To: <01157F64-007A-4D31-8C5D-2119BD701A2E@nokia.com> To: "multipathtcp@ietf.org Mailing List" References: <01157F64-007A-4D31-8C5D-2119BD701A2E@nokia.com> Message-Id: <4EBBBB31-9739-4283-8F90-2ABAF133C4C2@nokia.com> X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 11 Jan 2011 10:50:20 +0200 (EET) X-Nokia-AV: Clean Subject: Re: [multipathtcp] AD Review: draft-ietf-mptcp-architecture-03 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 Jan 2011 08:48:11 -0000 --Apple-Mail-38-748524264 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I put this ID on the IESG agenda for next week. Can you ASAP do a quick = rev that fixes some of the nits below? On 2010-12-17, at 14:01, Lars Eggert wrote: > Summary: good to go. >=20 > I'll start the IETF last call. Please take the comments below as = last-call comments. I will make this last call longer than normal, due = to the holiday season. >=20 > Lars >=20 >=20 > Section 1., paragraph 2: >> By the application of resource pooling[3], these available = resources >=20 > Nit: s/pooling[3]/pooling [3]/ (also check other reference citations > for a missing space before them) >=20 >=20 > Section 1.2., paragraph 0: >> 1.2. Terminology >=20 > I'd be somewhat useful to reorder the terms such that definitions > appear before they are used, as much as possible. >=20 >=20 > Section 1.2., paragraph 2: >> Path Identifier: Within the context of a multi-addressed multipath >> TCP, a path is defined by the source and destination (address, >> port) pairs (i.e. a 4-tuple). >=20 > Why is a Path identified by something that includes port numbers? > Because of ECMP? >=20 >=20 > Section 1.2., paragraph 6: >> Subflow: A flow of TCP packets operating over an individual path, >> which forms part of a larger Multipath TCP connection. >=20 > s/packet/segment/ (please check this throughout the document, = "packet" > is often used where "segment" is meant) >=20 >=20 > Section 1.3., paragraph 4: >> The scenario could have any number of addresses (1 or more) on each >> host, so long as the number of paths available between the two = hosts >> is 2 or more (i.e. num_addr(A) * num_addr(B) > 1). The paths = created >> by these address combinations through the Internet need not be >> entirely disjoint - shared bottlenecks will be addressed by the >> Multipath TCP congestion controller. >=20 > "will be addressed" is imprecise. Maybe: "potential fairness issues > introduced by joint bottlenecks need to be handled by..." >=20 >=20 > Section 1.3., paragraph 5: >> Furthermore, the paths through >> the Internet may be interrupted by any number of middleboxes >> including NATs and Firewalls. >=20 > Middleboxes don't really "interrupt" a path. Maybe rephrase with "are > present"? >=20 >=20 > Section 1.3., paragraph 6: >> Finally, although the diagram refers >> to the Internet, Multipath TCP may be used over any network where >> there are multiple paths that could be used concurrently. >=20 > Not sure if there is much value in mentioning this. (Plus, we do > assume an _IP_ network.) >=20 >=20 > Section 2.1., paragraph 3: >> o Improve Resilience: Multipath TCP MUST support the use of = multiple >> paths interchangeably for resilience purposes, by permitting >> packets to be sent and re-sent on any available path. >=20 > I think you mean "segments" (i.e., chunks of the bytestream) here, = and > not IP packets. >=20 >=20 > Section 2.1., paragraph 5: >> As distribution of traffic among available paths and responses to >> congestion are done in accordance with resource pooling >> principles[3], a secondary effect of meeting these goals is that >> widespread use of Multipath TCP over the Internet should optimize >> overall network utility by shifting load away from congested >> bottlenecks and by taking advantage of spare capacity wherever >> possible. >=20 > s/optimize/improve/ (it won't be optimal unless there is global > deployment *and* the mechanism itself is optimal) >=20 >=20 > Section 2.2.1., paragraph 3: >> A multipath-capable equivalent of TCP SHOULD retain backward >> compatibility with existing TCP APIs, so that existing applications >> can use the newer transport merely by upgrading the operating = systems >> of the end-hosts. >=20 > Any reason why this is not a MUST? I think this is critical; = otherwise > we'd already have seen widespread use of SCTP. >=20 >=20 > Section 2.2.2., paragraph 1: >> In the traditional Internet architecture, network devices operate = at >> the network layer and lower layers, with the layers above the = network >> layer instantiated only at the end-hosts. While this architecture, >> shown in Figure 2, was initially largely adhered to, this layering = no >> longer reflects the "ground truth" in the Internet with the >> proliferation of middleboxes[8]. Middleboxes routinely interpose = on >> the transport layer; sometimes even completely terminating = transport >> connections, thus leaving the application layer as the first real >> end-to-end layer, as shown in Figure 3. >=20 > And even application level protocols often define roles for > intermediaries, e.g., SIP and HTTP. >=20 >=20 > Section 2.4., paragraph 1: >> standardised. The de facto standard stream-based transport = protocol >=20 > s/de facto standard/by far most widely used/ (TCP *is* of course a > standard...) >=20 >=20 > Section 3., paragraph 7: >> behaving as a TCP flow in network, is an instantiation of the >=20 > Nit: s/in network/in the network/ >=20 >=20 > Section 4., paragraph 10: >> shared bottlneck. An algorithm to support this is specified in >=20 > Nit: s/bottlneck./bottleneck./ >=20 >=20 > Section 4., paragraph 12: >> own sequence number, acks, and passes them to network. The = receiving >=20 > Nit: s/acks,/ACKs,/ >=20 >=20 > Section 5.1., paragraph 3: >> receiver must determine how subflow-level data (carying subflow >=20 > Nit: s/(carying/(carrying/ >=20 >=20 > Section 5.1., paragraph 6: >> be permissable for the mapping to be sent periodically and cover = more >=20 > Nit: s/permissable/permissible/ >=20 >=20 > Section 5.2., paragraph 2: >> to-end semantics. It means that once a packet is acked at the >=20 > Nit: s/acked/ACKed/ >=20 >=20 > Section 5.2., paragraph 4: >> a subflow traversing a transparent proxy: if the proxy acks a = segment >=20 > Nit: s/acks/ACKs/ >=20 >=20 > Section 5.2., paragraph 6: >> Therefore, to provide a fully robust multipath TCP solution, MPTCP >> SHOULD feature explicit connection-level acknowledgements, in >=20 > After all of this argumentation in the previous paragraphs, why is > this not a MUST? Esp. since in the first paragraph you already say > "MPTCP features..." which in essence is a MUST. >=20 >=20 > Section 5.2., paragraph 10: >> maintain subflow integrity, as per the network compatiblity goal. = By >=20 > Nit: s/compatiblity/compatibility/ >=20 >=20 > Section 5.2., paragraph 11: >> doing this, throughput will be wasted, and it is unclear at this >> point what the optimal retransmit strategy is. >=20 > I think "throughput will be wasted" sounds too harsh. Maybe "some > efficiency is lost"? >=20 >=20 > Section 5.3., paragraph 6: >> The resulting buffer size should be small enough for practical use. >> However, there may be extreme cases where fast, high throughput = paths >> (e.g. 100Mb/s, 10ms RTT) are used in conjunction with slow paths >> (e.g. 1Mb/s, 1000ms RTT). In that case the required receive buffer >> would be 12.5MB, which is likely too big. In these cases a = Multipath >> TCP scheduler SHOULD use only the fast path, potentially falling = back >> to the slow path if the fast path fails. >=20 > Please rephrase the last sentence so that it not specific to the > example given, since we're trying to state a general rule here. = Maybe: > "it may be prudent to only use some of the fastest available paths = for > the MPTCP connection" or something like that >=20 >=20 > Section 5.4., paragraph 3: >> The MPTCP protocol design will, however, use TCP Options for this >> additional signalling. This has been chosen as the mechanism most >> fitting in with the goals as specified in Section 2.=20 >=20 > Aside: Instead of using several different TCP Option numbers, I = wonder > if we can use one TCP Option Number for MPTCP and disambiguate based > on the Length field what kind of MPTCP option we have? (Assuming all > our different option kinds have different lengths...) >=20 >=20 > Section 5.5., paragraph 1: >> Currently, the network does not expose multiple paths between = hosts. >=20 > This isn't really capturing it. The network *does* expose this, *if* > the paths begin and end at different IP addresses. I think you mean > that the network doesn't expose the availability of path diversity = *in > the network* for paths between the same two IP addresses. >=20 >=20 > Section 5.5., paragraph 2: >> that these paths, whilst not necesarily entirely non-overlapping, >=20 > Nit: s/necesarily/necessarily/ >=20 >=20 > Section 5.5., paragraph 4: >> Multiple different (source, destination) address pairs will thus be >> used as path selectors in most cases. Each path will be identified >> by a TCP 4-tuple (i.e. source address, destination address, source >> port, destination port), however, which can allow the extension of >> MPTCP to use such 4-tuples as path selectors. This will allow = hosts >> to use MPTCP to load balance to different ports, for example if the >> network routes different ports over different paths (which may be = the >> case with technologies such as Equal Cost MultiPath (ECMP) routing >> [16]). >=20 > So actually, you use a five-tuple, it's just that the protocol number > component is always 6 (TCP) in our case. There are ECMP schemes where > the resulting paths are different when only the protocol number > component is different. I'd prefer if we could talk about five-tuples > and path IDs, since paths are not usually something that is specific > to one transport protocol. (And you actually do already talk about > five-tuples in the next section...) >=20 >=20 > Section 5.5., paragraph 6: >> The modularity of path management will permit alternative = mechanisms >> to be employed if appropriate in the future. >=20 > What modularity of path management? Nothing in this section so far > talks about modularity. Suggest to drop this paragraph. >=20 >=20 > Section 5.8., paragraph 11: >=20 >> o The desire to support a 'break-before-make' (as well as a 'make- >> before-break') approach to adding subflows implies that a host >> cannot rely on using a pre-existing subflow to support the >> addition of a new one. >=20 > But I don't think we want to support "unlimited" break-before-make, > i.e., just because we had the connection up yesterday doesn't mean I > should still be able to join a new first flow into it today. In other > words, we want to support break-before-make for some limited amount = of > break time only. >=20 >=20 > Section 7., paragraph 3: >> just basic datagram delivery. A miriad of middleboxes are deployed >=20 > Nit: s/miriad/myriad/ >=20 >=20 > Section 7., paragraph 15: >> o Segmentation and Colescing: middleboxes (or even something as >=20 > Nit: s/Colescing:/Coalescing:/ >=20 >=20 > Section 12.2., paragraph 7: >> [9] Carpenter, B., "Internet Transparency", RFC 2775, >> February 2000. >=20 > Unused Reference: '9' is defined on line 1108, but no explicit > reference was found in the text >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail-38-748524264 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDExMTA4NTAyMFowIwYJKoZIhvcNAQkE MRYEFJypmEaz3O5LF18wZkjN8jNMIYrdMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AAsdir6YEyndiCp8/ITegUy303rAbyqywp+/c3zrDkG5oBMCNbEO1ONHHZf9iY4Jgbx3TW91rLtq ZHp8XGwUmYctxhdhBeSARVUfB1vnsV2qtdY219bqjCwmodFibeZhaaYd7YFFsYVU5NypVxuk36R/ OkKaTM44l3+8qjfbphyIsNVAm4JEQa3eF1Sg49yVOlKlhlmiOGqBwqp68QlPhOa9GNAWY3Ejf1FG rX7TRuORl09bX3j/OGQr9UlvWv91KAWTmkSMmxxSUCxZh0/YyXvyVzED0PaT4Lfbkp0nGYh07Y/i WIeCRkIX8+QRMl7W9CTeK0ky1jbFmjxSuyCGMjwAAAAAAAA= --Apple-Mail-38-748524264-- From marcelo@it.uc3m.es Tue Jan 11 01:59:15 2011 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 5B38F28C11B for ; Tue, 11 Jan 2011 01:59:15 -0800 (PST) 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=[AWL=0.000, 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 yC-GzYfZPsJw for ; Tue, 11 Jan 2011 01:59:14 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id E67EA3A63EB for ; Tue, 11 Jan 2011 01:59:13 -0800 (PST) X-uc3m-safe: yes Received: from r190-132-81-96.dialup.mobile.ancel.net.uy (r190-132-81-96.dialup.mobile.ancel.net.uy [190.132.81.96]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 5676BBEFBDE; Tue, 11 Jan 2011 11:01:26 +0100 (CET) Message-ID: <4D2C2A72.9030202@it.uc3m.es> Date: Tue, 11 Jan 2011 11:01:22 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: multipathtcp@ietf.org, Lars Eggert , "EARDLEY, Phil" , Yoshifumi Nishida References: <53803E46-DF33-4818-890F-879F761BC796@nokia.com> In-Reply-To: <53803E46-DF33-4818-890F-879F761BC796@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17886.003 Subject: Re: [multipathtcp] AD Review: draft-ietf-mptcp-threat-06 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 Jan 2011 09:59:15 -0000 thanks for the review. I have posted a 07 version with all the changes regards, marcelo El 17/12/10 13:56, Lars Eggert escribió: > Summary: good to go. > > I'll start the IETF last call. Please take the comments below as last-call comments. I will make this last call longer than normal, due to the holiday season. > > Lars > > INTRODUCTION, paragraph 2: >> Threat Analysis for Multi-addressed/Multi-path TCP > Might make sense to align the title with the title of the spec, which > is "TCP Extensions for Multipath Operation with Multiple Addresses", > so maybe "Threat Analysis for TCP Extensions for Multipath Operation > with Multiple Addresses"? > > done > INTRODUCTION, paragraph 5: >> Multi-path TCP (MPTCP for short) describes the extensions proposed >> for TCP so that each endpoint of a given TCP connection can use >> multiple IP addresses to exchange data (instead of a single IP >> address per endpoint as currently defined). > Not quite correct: It's not that *each* endpoint can use multiple > addresses, it's that two endpoints can use multiple *paths*. (You say > this in the next section, maybe combine?) Also fix this in the > introduction, which is basically a copy of the abstract. > > done > Section 2., paragraph 1: >> some form of path selector. There are multiple options for such path > s/such path/such a path/ > done > Section 2., paragraph 2: >> a particular approach, namely MPTCP approaches that rely on the usage > s/namely MPTCP approaches that rely/namely MPTCP, that relies/ > done > Section 2., paragraph 3: >> of multiple IP address per endpoint and that use different source- > s/use/uses/ > done > Section 2., paragraph 4: >> destination address pairs as a mean to express different paths. So, >> in the rest of this note, the MPTCP expression will refer to this >> Multi-addressed flavour of Multi-path TCP. > Please cite the spec here. > > done > Section 2., paragraph 5: >> In this note we perform a threat analysis for MPTCP. Introducing the >> support of multiple addresses per endpoint in a single TCP connection >> may result in additional vulnerabilities. > ...compared to single-path TCP. > done > Section 2., paragraph 6: >> is to help the MPTCP protocol designers to create a MPTCP that is as > s/to create/create/ and s/a MPTCP/an MPTCP specification/ > done > Section 2., paragraph 7: >> secure as the current TCP. It is a non goal of this analysis to help > s/non goal/non-goal/ > done > Section 3., paragraph 1: >> There is significant amount of previous work in terms of analysis of > Nit: s/is significant/is a significant/ > done > Section 3., paragraph 3: >> is at stake. In other words, if a binding between two address is > Nit: s/two address/two addresses/ > done > Section 3., paragraph 8: >> basis for this analysis, there are a set of characteristics that are > s/there are a set/there is a set/ > done > Section 5., paragraph 4: >> possible or not for the attacker to send such packet. At this stage, > s/such packet/such a packet/ > done > Section 5., paragraph 5: >> ACKs for the data sent using a given a given address pair should come > s/a given a given/a given/ > done > Section 5., paragraph 10: >> with MPTCP is one where the attacker initiates a a communication with > s/a a/a/ done > > Section 6.1., paragraph 4: >> MPTCP connection. This means that there will be two source of > s/two source/two sources/ > done > Section 6.2., paragraph 3: >> There are several type of approaches that provide some protection > s/several type/several types/ > done > Section 6.2., paragraph 4: >> subflow and then validate the following subflows by using an keyed > s/an keyed/a keyed/ > > done > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From Internet-Drafts@ietf.org Tue Jan 11 02:15:03 2011 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 056DE3A6A15; Tue, 11 Jan 2011 02:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zf57QdiBZ0p; Tue, 11 Jan 2011 02:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A1D3A6A2F; Tue, 11 Jan 2011 02:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111101502.17196.14485.idtracker@localhost> Date: Tue, 11 Jan 2011 02:15:02 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-threat-07.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 10:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses Author(s) : M. Bagnulo Filename : draft-ietf-mptcp-threat-07.txt Pages : 17 Date : 2011-01-11 Multi-path TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. In particular, some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP protocol. This note includes a threat analysis for MPTCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-threat-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mptcp-threat-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11020547.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Jan 11 02:45:02 2011 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 B401D28C122; Tue, 11 Jan 2011 02:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2q90iif626I; Tue, 11 Jan 2011 02:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD17A28C114; Tue, 11 Jan 2011 02:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111104501.25338.6182.idtracker@localhost> Date: Tue, 11 Jan 2011 02:45:01 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-architecture-04.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 10:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : Architectural Guidelines for Multipath TCP Development Author(s) : A. Ford, et al. Filename : draft-ietf-mptcp-architecture-04.txt Pages : 28 Date : 2011-01-11 Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput. This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP protocol. This document lists certain high level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-architecture-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mptcp-architecture-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11024326.I-D@ietf.org> --NextPart-- From prvs=699273c739=alan.ford@roke.co.uk Tue Jan 11 02:57:18 2011 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 A595928C26E for ; Tue, 11 Jan 2011 02:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 GI0XiPwh+1gz for ; Tue, 11 Jan 2011 02:57:17 -0800 (PST) Received: from gse-mta-29.emailfiltering.com (gse-mta-29-tx.emailfiltering.com [194.116.198.160]) by core3.amsl.com (Postfix) with ESMTP id 9564828C100 for ; Tue, 11 Jan 2011 02:57:16 -0800 (PST) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by gse-mta-29.emailfiltering.com with emfmta (version 4.6.0.72) vanilla id 254135784 for multipathtcp@ietf.org; a788f95d8b4e9062; Tue, 11 Jan 2011 10:59:32 +0000 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, 11 Jan 2011 10:59:30 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680BF532BD@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <01157F64-007A-4D31-8C5D-2119BD701A2E@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] AD Review: draft-ietf-mptcp-architecture-03 Thread-Index: Acud4mZPuFgqb0b/S7u3hMMPARdX+wTmmL4Q References: <01157F64-007A-4D31-8C5D-2119BD701A2E@nokia.com> From: "Ford, Alan" To: "Lars Eggert" , Subject: Re: [multipathtcp] AD Review: draft-ietf-mptcp-architecture-03 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 Jan 2011 10:57:18 -0000 Thanks for your comments, Lars. A new version addressing them is available at: http://www.ietf.org/id/draft-ietf-mptcp-architecture-04.txt Details of changes inline... > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On > Behalf Of Lars Eggert > Sent: 17 December 2010 12:02 > To: multipathtcp@ietf.org Mailing List > Subject: [multipathtcp] AD Review: draft-ietf-mptcp-architecture-03 >=20 > Summary: good to go. >=20 > I'll start the IETF last call. Please take the comments below as last-call > comments. I will make this last call longer than normal, due to the holiday > season. >=20 > Lars >=20 >=20 > Section 1., paragraph 2: > > By the application of resource pooling[3], these available resources >=20 > Nit: s/pooling[3]/pooling [3]/ (also check other reference citations > for a missing space before them) All fixed I think. > Section 1.2., paragraph 0: > > 1.2. Terminology >=20 > I'd be somewhat useful to reorder the terms such that definitions > appear before they are used, as much as possible. This is slightly tricky due to interdependence, but "Multipath TCP" moved to the top. > Section 1.2., paragraph 2: > > Path Identifier: Within the context of a multi-addressed multipath > > TCP, a path is defined by the source and destination (address, > > port) pairs (i.e. a 4-tuple). >=20 > Why is a Path identified by something that includes port numbers? > Because of ECMP? Yes, this is explained in Section 5.5. Quite why this definition was still there I don't know, I've removed it - it adds nothing to clarity being this early. > Section 1.2., paragraph 6: > > Subflow: A flow of TCP packets operating over an individual path, > > which forms part of a larger Multipath TCP connection. >=20 > s/packet/segment/ (please check this throughout the document, "packet" > is often used where "segment" is meant) All changed where appropriate. > Section 1.3., paragraph 5: > > Furthermore, the paths through > > the Internet may be interrupted by any number of middleboxes > > including NATs and Firewalls. >=20 > Middleboxes don't really "interrupt" a path. Maybe rephrase with "are > present"? Difficult wording to get right... text changed to: Furthermore, the paths through the Internet often do not provide a pure end-to-end service, and instead may be affected by middleboxes such as NATs and Firewalls. > Section 1.3., paragraph 6: > > Finally, although the diagram refers > > to the Internet, Multipath TCP may be used over any network where > > there are multiple paths that could be used concurrently. >=20 > Not sure if there is much value in mentioning this. (Plus, we do > assume an _IP_ network.) Removed. > Section 2.2.1., paragraph 3: > > A multipath-capable equivalent of TCP SHOULD retain backward > > compatibility with existing TCP APIs, so that existing applications > > can use the newer transport merely by upgrading the operating systems > > of the end-hosts. >=20 > Any reason why this is not a MUST? I think this is critical; otherwise > we'd already have seen widespread use of SCTP. Only compatibility with the most commonly used features is really required. Anyway, text changed. > Section 2.2.2., paragraph 1: > > In the traditional Internet architecture, network devices operate at > > the network layer and lower layers, with the layers above the network > > layer instantiated only at the end-hosts. While this architecture, > > shown in Figure 2, was initially largely adhered to, this layering no > > longer reflects the "ground truth" in the Internet with the > > proliferation of middleboxes[8]. Middleboxes routinely interpose on > > the transport layer; sometimes even completely terminating transport > > connections, thus leaving the application layer as the first real > > end-to-end layer, as shown in Figure 3. >=20 > And even application level protocols often define roles for > intermediaries, e.g., SIP and HTTP. These are application-level intermediaries, however, which is a bit out of scope for MPTCP. The section is concentrating on middleboxes that exist at the transport layer. I couldn't find an appropriate way of inserting this into this section without going off on a non-MPTCP-relevant tangent; I hope you're ok with it still left out. > Section 5.2., paragraph 6: > > Therefore, to provide a fully robust multipath TCP solution, MPTCP > > SHOULD feature explicit connection-level acknowledgements, in >=20 > After all of this argumentation in the previous paragraphs, why is > this not a MUST? Esp. since in the first paragraph you already say > "MPTCP features..." which in essence is a MUST. It doesn't need to be a MUST if the implementation can be sure of behaviour of the network and endpoints. So I've changed it to: "MPTCP for use on the public Internet MUST feature explicit connection-level acknowledgements". > Section 5.3., paragraph 6: > > The resulting buffer size should be small enough for practical use. > > However, there may be extreme cases where fast, high throughput paths > > (e.g. 100Mb/s, 10ms RTT) are used in conjunction with slow paths > > (e.g. 1Mb/s, 1000ms RTT). In that case the required receive buffer > > would be 12.5MB, which is likely too big. In these cases a Multipath > > TCP scheduler SHOULD use only the fast path, potentially falling back > > to the slow path if the fast path fails. >=20 > Please rephrase the last sentence so that it not specific to the > example given, since we're trying to state a general rule here. Maybe: > "it may be prudent to only use some of the fastest available paths for > the MPTCP connection" or something like that Now reads: In extreme cases such as this example, it may be prudent to only use some of the fastest available paths for the MPTCP connection, potentially using the slow path(s) for backup only. > Section 5.4., paragraph 3: > > The MPTCP protocol design will, however, use TCP Options for this > > additional signalling. This has been chosen as the mechanism most > > fitting in with the goals as specified in Section 2. >=20 > Aside: Instead of using several different TCP Option numbers, I wonder > if we can use one TCP Option Number for MPTCP and disambiguate based > on the Length field what kind of MPTCP option we have? (Assuming all > our different option kinds have different lengths...) Seb's already answered that one - it's a bit limiting. However, to save on option numbers, a sub-code could be used (at the cost of an additional octet). But this is out of scope for the architecture, anyway (it only says that Options will be used, not how they'll be used). > Section 5.5., paragraph 1: > > Currently, the network does not expose multiple paths between hosts. >=20 > This isn't really capturing it. The network *does* expose this, *if* > the paths begin and end at different IP addresses. I think you mean > that the network doesn't expose the availability of path diversity *in > the network* for paths between the same two IP addresses. Now reads: Currently, the network does not expose path diversity between pairs of IP addresses. In order to achieve path diversity from today's IP networks, in the typical case MPTCP uses multiple addresses at one or both hosts to infer different paths across the network. > Section 5.5., paragraph 4: > > Multiple different (source, destination) address pairs will thus be > > used as path selectors in most cases. Each path will be identified > > by a TCP 4-tuple (i.e. source address, destination address, source > > port, destination port), however, which can allow the extension of > > MPTCP to use such 4-tuples as path selectors. This will allow hosts > > to use MPTCP to load balance to different ports, for example if the > > network routes different ports over different paths (which may be the > > case with technologies such as Equal Cost MultiPath (ECMP) routing > > [16]). >=20 > So actually, you use a five-tuple, it's just that the protocol number > component is always 6 (TCP) in our case. There are ECMP schemes where > the resulting paths are different when only the protocol number > component is different. I'd prefer if we could talk about five-tuples > and path IDs, since paths are not usually something that is specific > to one transport protocol. (And you actually do already talk about > five-tuples in the next section...) Fair enough... All changed to "five-tuple". > Section 5.5., paragraph 6: > > The modularity of path management will permit alternative mechanisms > > to be employed if appropriate in the future. >=20 > What modularity of path management? Nothing in this section so far > talks about modularity. Suggest to drop this paragraph. I was going to drop it, but then thought it makes an important point, just badly worded. Now reads: The path management is a separate function from the packet scheduling, subflow interface, and congestion control functions of MPTCP, as documented in Section 4. As such it would be feasible to replace this IP-address-based design with an alternative path selection mechanism in the future, with no significant changes to the other functional components. > Section 5.8., paragraph 11: >=20 > > o The desire to support a 'break-before-make' (as well as a 'make- > > before-break') approach to adding subflows implies that a host > > cannot rely on using a pre-existing subflow to support the > > addition of a new one. >=20 > But I don't think we want to support "unlimited" break-before-make, > i.e., just because we had the connection up yesterday doesn't mean I > should still be able to join a new first flow into it today. In other > words, we want to support break-before-make for some limited amount of > break time only. I've added "time-limited", but of course it's entirely up to implementations, just like retaining TCP state today. However long it is, it doesn't change the implication that's stated. > Section 12.2., paragraph 7: > > [9] Carpenter, B., "Internet Transparency", RFC 2775, > > February 2000. >=20 > Unused Reference: '9' is defined on line 1108, but no explicit > reference was found in the text I think the nits tool is broken :) (Adding spaces fixed that one, it's always been there on Page 8). I've also addressed Cullen's two minor comments by adding the following to "Network Compatibility": Middleboxes may also cause some TCP features to be able to exist on one subflow but not another. Typically these will be at the subflow level (such as SACK [10]) and thus do not affect the connection-level behaviour. In the future, any proposed TCP connection-level extensions should consider how they can co-exist with MPTCP. And the following to Interactions with Applications: TCP features the ability to send out-of-band ("Urgent") data. Although the use of Urgent data is not recommended (see [20]), MPTCP SHOULD still support this feature if requested by an application. An MPTCP implementation SHOULD send the Urgent data on one subflow of the MPTCP connection; it MAY choose this to be the best performing subflow. Thanks, Alan From prvs=699273c739=alan.ford@roke.co.uk Tue Jan 11 08:09:32 2011 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 9749728C2BD for ; Tue, 11 Jan 2011 08:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, 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 8JnlvqLCXt2M for ; Tue, 11 Jan 2011 08:09:31 -0800 (PST) Received: from ixe-mta-29.emailfiltering.com (ixe-mta-29-tx.emailfiltering.com [194.116.199.160]) by core3.amsl.com (Postfix) with ESMTP id 517BA3A698E for ; Tue, 11 Jan 2011 08:09:30 -0800 (PST) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by ixe-mta-29.emailfiltering.com with emfmta (version 4.6.0.72) vanilla id 253387282 for multipathtcp@ietf.org; ddf2d6702a4a0c96; Tue, 11 Jan 2011 16:11:46 +0000 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, 11 Jan 2011 16:11:33 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680BF5355C@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reducing option number usage Thread-Index: AcuxqjbWjKS4IlO1RjmiIu6GPivT+A== From: "Ford, Alan" To: Subject: [multipathtcp] Reducing option number usage 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 Jan 2011 16:09:32 -0000 Hi all, Lars commented a few weeks ago about whether we could reduce MPTCP's requirement on IANA's limited set of TCP option numbers by having a single MPTCP type and inferring the sub-type by the length of the option. This itself would likely be difficult to implement and not be particularly extensible; however, we could use a limited number of options, with a sub-type field. I looked again at the TCP options we have in MPTCP, and came to the following conclusions: * MP_CAPABLE and MP_JOIN have spare bits; we could use 4 as a sub-type field. * ADD_ADDR, REM_ADDR, MP_PRIO and MP_FAIL are signals that can be sent on duplicate ACKs and so there is sufficient space that we can use additional bits for a sub-type field, too. * DATA_ACK and DSN_MAP are often (but not always) seen together. They can be combined under a different option subtype. * DATA_FIN is no longer required. To expand on the last two points: If the DATA_ACK and DSN_MAP were combined, we could end up with an option that looks a bit like this ("Flags" is a set of bits that define the contents - currently, we'd be looking at: DSN_MAP present; DATA_ACK present; DSN_MAP is eight bytes rather than four; DATA_ACK is eight bytes. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+---------------+ | Kind=3DMPTCP | Length | Subtype | Flags | +---------------+---------------+--------------+---------------+ | Data ACK (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Data Sequence Number (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Subflow Sequence Number (4 octets) | +-------------------------------+------------------------------+ | Data-level Length (2 octets) | Checksum (2 octets) |=20 +-------------------------------+------------------------------+ In the course of thinking about this, I have realised we don't need an explicit DATA_FIN option. DATA_FIN can be implied by a DSN_MAP where the mapping covers the FIN of the subflow. Thoughts? Cheers, Alan From philip.eardley@bt.com Tue Jan 18 10:30:11 2011 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 826123A707D for ; Tue, 18 Jan 2011 10:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.755 X-Spam-Level: X-Spam-Status: No, score=-101.755 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6, 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 r3L6YHOzQhgX for ; Tue, 18 Jan 2011 10:30:08 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by core3.amsl.com (Postfix) with ESMTP id C258C3A707C for ; Tue, 18 Jan 2011 10:30:07 -0800 (PST) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 18 Jan 2011 18:32:45 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.127]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Tue, 18 Jan 2011 18:32:44 +0000 From: To: , Date: Tue, 18 Jan 2011 18:32:44 +0000 Thread-Topic: Reducing option number usage Thread-Index: AcuxqjbWjKS4IlO1RjmiIu6GPivT+AFkGkCw Message-ID: <9510D26531EF184D9017DF24659BB87F3275E953DF@EMV65-UKRD.domain1.systemhost.net> References: <2181C5F19DD0254692452BFF3EAF1D680BF5355C@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680BF5355C@rsys005a.comm.ad.roke.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multipathtcp] Reducing option number usage 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 Jan 2011 18:30:11 -0000 Any comments? We would like to do an update soon, including this & the security decision,= in order that we can still be on track for our aim of WGLC before Prague. thanks -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Ford, Alan Sent: 11 January 2011 16:12 To: multipathtcp@ietf.org Subject: [multipathtcp] Reducing option number usage Hi all, Lars commented a few weeks ago about whether we could reduce MPTCP's requirement on IANA's limited set of TCP option numbers by having a single MPTCP type and inferring the sub-type by the length of the option. This itself would likely be difficult to implement and not be particularly extensible; however, we could use a limited number of options, with a sub-type field. I looked again at the TCP options we have in MPTCP, and came to the following conclusions: * MP_CAPABLE and MP_JOIN have spare bits; we could use 4 as a sub-type field. * ADD_ADDR, REM_ADDR, MP_PRIO and MP_FAIL are signals that can be sent on duplicate ACKs and so there is sufficient space that we can use additional bits for a sub-type field, too. * DATA_ACK and DSN_MAP are often (but not always) seen together. They can be combined under a different option subtype. * DATA_FIN is no longer required. To expand on the last two points: If the DATA_ACK and DSN_MAP were combined, we could end up with an option that looks a bit like this ("Flags" is a set of bits that define the contents - currently, we'd be looking at: DSN_MAP present; DATA_ACK present; DSN_MAP is eight bytes rather than four; DATA_ACK is eight bytes. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+---------------+ | Kind=3DMPTCP | Length | Subtype | Flags | +---------------+---------------+--------------+---------------+ | Data ACK (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Data Sequence Number (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Subflow Sequence Number (4 octets) | +-------------------------------+------------------------------+ | Data-level Length (2 octets) | Checksum (2 octets) |=20 +-------------------------------+------------------------------+ In the course of thinking about this, I have realised we don't need an explicit DATA_FIN option. DATA_FIN can be implied by a DSN_MAP where the mapping covers the FIN of the subflow. Thoughts? Cheers, Alan _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From touch@isi.edu Tue Jan 18 12:28:40 2011 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 CC57F3A7078 for ; Tue, 18 Jan 2011 12:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbS7yjXWuiYN for ; Tue, 18 Jan 2011 12:28:38 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 4F1F63A7069 for ; Tue, 18 Jan 2011 12:28:38 -0800 (PST) Received: from [204.140.194.213] (guest-wireless-204-140-194-213.usc.edu [204.140.194.213]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p0IKUZw0005257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 18 Jan 2011 12:30:45 -0800 (PST) Message-ID: <4D35F86B.1020006@isi.edu> Date: Tue, 18 Jan 2011 12:30:35 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ford, Alan" References: <2181C5F19DD0254692452BFF3EAF1D680BF5355C@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680BF5355C@rsys005a.comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p0IKUZw0005257 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Reducing option number usage 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 Jan 2011 20:28:40 -0000 Hi, all, On 1/11/2011 8:11 AM, Ford, Alan wrote: > Hi all, > > Lars commented a few weeks ago about whether we could reduce MPTCP's > requirement on IANA's limited set of TCP option numbers by having a > single MPTCP type and inferring the sub-type by the length of the > option. This itself would likely be difficult to implement and not be > particularly extensible; however, we could use a limited number of > options, with a sub-type field. I'm a bit confused by that conclusion. IMO, there is no reason a single TCP extension should ever need more than one TCP option type. Can you clarify why this would need to be the case here? Joe From lars.eggert@nokia.com Tue Jan 18 23:56:08 2011 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 A14C83A6FB2 for ; Tue, 18 Jan 2011 23:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=-1.697, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, 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 qcWwFMRPtlyL for ; Tue, 18 Jan 2011 23:56:08 -0800 (PST) Received: from mgw-da01.nokia.com (unknown [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id E544C3A6F90 for ; Tue, 18 Jan 2011 23:56:07 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0J7wjEi029420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 09:58:46 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-34--710862327; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4D35F86B.1020006@isi.edu> Date: Wed, 19 Jan 2011 09:58:37 +0200 Message-Id: References: <2181C5F19DD0254692452BFF3EAF1D680BF5355C@rsys005a.comm.ad.roke.co.uk> <4D35F86B.1020006@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 19 Jan 2011 09:58:42 +0200 (EET) X-Nokia-AV: Clean Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Reducing option number usage 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, 19 Jan 2011 07:56:09 -0000 --Apple-Mail-34--710862327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2011-1-18, at 22:30, Joe Touch wrote: > I'm a bit confused by that conclusion. IMO, there is no reason a = single TCP extension should ever need more than one TCP option type. Can = you clarify why this would need to be the case here? MPTCP uses several different kinds of options. That can be expressed by = using several TCP option numbers, or by using one TCP option number and = an internal "option kind" field. The latter is much cleaner than the = former, but makes each MPTCP option a bit longer. One complication is = that option space is so limited that option length matters (maybe more = so than architectural cleanliness.) I think the current proposal is a hybrid: use internal "option kind" = fields where option length doesn't matter, but still use more than one = TCP option number for those MPTCP options where length does matter. I can live with the hybrid although it's not the cleanest possible = approach. Lars= --Apple-Mail-34--710862327 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDExOTA3NTgzN1owIwYJKoZIhvcNAQkE MRYEFLeVxKZ3JscD37A5mJXeg5o8IXOYMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AKfJw3SsXANJ7FyoWXurBq/1ELWLsNZPDOk50x8eLEiqJN6dot3I2dTi7IEQFQZoSJiCUOSTbqCD 0/0lJ/uYOwQwJpyONiGm+AgRePk8CUnzUSyyjGrzx1mMgxod+S4Kq0lE2EEtz4pbnIebIwwLZKGC ide2WryPFvyQwmx7lFCF5HL9hDhF0TDHM3+GuncxKSFPe6VQuX6t3HJbj5e+Gw9rQ0j1Oi0NigNT ngpfKhKehdildsQT+k78wv/y5RyDsS9w4JBkIecwOShejn0Yr4+qzkxhvrDmvi5xtWrK7JI/IoDK 3uyrKci0Syl50bcG+jcVrCfncg2lLYIscJgUvkEAAAAAAAA= --Apple-Mail-34--710862327-- From prvs=8000571a42=alan.ford@roke.co.uk Wed Jan 19 01:16:30 2011 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 A6A323A70D7 for ; Wed, 19 Jan 2011 01:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 esHSzubayM9P for ; Wed, 19 Jan 2011 01:16:29 -0800 (PST) Received: from gse-mta-29.emailfiltering.com (gse-mta-29-tx.emailfiltering.com [194.116.198.160]) by core3.amsl.com (Postfix) with ESMTP id 5212D3A6E80 for ; Wed, 19 Jan 2011 01:16:29 -0800 (PST) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by gse-mta-29.emailfiltering.com with emfmta (version 4.8.0.410) vanilla id 261236392 for multipathtcp@ietf.org; 5f40a707de4cb97c; Wed, 19 Jan 2011 09:19:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jan 2011 09:19:06 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680C02946C@rsys005a.comm.ad.roke.co.uk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Reducing option number usage Thread-Index: Acu3rrv1914JKYRHQ/2dphhS7rr5dAACm6iQ References: <2181C5F19DD0254692452BFF3EAF1D680BF5355C@rsys005a.comm.ad.roke.co.uk> <4D35F86B.1020006@isi.edu> From: "Ford, Alan" To: "Lars Eggert" , "Joe Touch" Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Reducing option number usage 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, 19 Jan 2011 09:16:30 -0000 Hi Lars, Joe, Yes, although I never actually specified how many a "limited number" would be :) Indeed, having thought about this some more I think we will be fine with a single option type, so long as we can live with four bits for a sub-type field.=20 The MP_CAPABLE and MP_JOIN options used on the SYNs are sufficiently space-constrained that we cannot really go beyond four bits there. All other options could spare up to 8 bits for a full octet of sub-type, but that would require two TCP option types (one for the SYN packet options and one for other signals). This is the trade-off we have - anybody got any strong opinions? At the moment I am favouring the four-bit sub-type field, with a single allocated TCP option (and deal with any new problems in a later MPTCP version ;) ). Regards, Alan > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 19 January 2011 07:59 > To: Joe Touch > Cc: Ford, Alan; multipathtcp@ietf.org > Subject: Re: [multipathtcp] Reducing option number usage >=20 > Hi, >=20 > On 2011-1-18, at 22:30, Joe Touch wrote: > > I'm a bit confused by that conclusion. IMO, there is no reason a single TCP > extension should ever need more than one TCP option type. Can you clarify why > this would need to be the case here? >=20 > MPTCP uses several different kinds of options. That can be expressed by using > several TCP option numbers, or by using one TCP option number and an internal > "option kind" field. The latter is much cleaner than the former, but makes > each MPTCP option a bit longer. One complication is that option space is so > limited that option length matters (maybe more so than architectural > cleanliness.) >=20 > I think the current proposal is a hybrid: use internal "option kind" fields > where option length doesn't matter, but still use more than one TCP option > number for those MPTCP options where length does matter. >=20 > I can live with the hybrid although it's not the cleanest possible approach. >=20 > Lars From yoshifumi.nishida@gmail.com Wed Jan 19 01:21:57 2011 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 D34D63A6E80 for ; Wed, 19 Jan 2011 01:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 GXDPIiDaWRGI for ; Wed, 19 Jan 2011 01:21:57 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id E48373A70DA for ; Wed, 19 Jan 2011 01:21:56 -0800 (PST) Received: by wwi17 with SMTP id 17so396197wwi.1 for ; Wed, 19 Jan 2011 01:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=0pDiKZ8IdcgthgXEKij/lDX4vVB3gBNfTH17CTFNu6U=; b=PH10oKUYpMQUci2mRCKPpSC3WRdkDXKHh8wfQGuew9i35vmlAu4OpP4BaleKUa8zmz myveL6HVBnDPJbZooEtgS3wkc5BmT6OdeeTbG61iXCg2NfKJcl2kwxwwRtSmxVN/eBJP DISeXVARMcrC8yVJHke08ym8Q4y7bgrtUY2e0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=WV+qpx50dUN9+XfuDXu2ZXnvBZLf8JQkNbLC25Kmw5N505y7uyYTsgJAZyyX3hJCfF wz9Bzpr0GR5vScGW0niJVu4CoLQgoiyLZ7z1yx8KfmFSXwWLCKzgDA58c2iDsUYMzegr 1X6jhiexheHaGXq2d3XPgVbuCfQPjXfB8swGk= MIME-Version: 1.0 Received: by 10.216.177.211 with SMTP id d61mr2185232wem.76.1295429075875; Wed, 19 Jan 2011 01:24:35 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.216.170.199 with HTTP; Wed, 19 Jan 2011 01:24:35 -0800 (PST) Date: Wed, 19 Jan 2011 01:24:35 -0800 X-Google-Sender-Auth: kVPibX9wB5mEYmNMitYuJT58CaI Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] 3 way subflow setup 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, 19 Jan 2011 09:21:57 -0000 Hello, please correct me if I'm wrong. In the last interim meeting, Marcelo mentioned about a proposal to use 3 packets handshake for subflow setup with HMAC based solution. As far as I remember, Alan answered it's possible. This sounds interesting to me and worth discussing. Or, is there any big flaw in this idea? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From lars.eggert@nokia.com Wed Jan 19 01:25:58 2011 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 B33933A7028 for ; Wed, 19 Jan 2011 01:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.106 X-Spam-Level: X-Spam-Status: No, score=-103.106 tagged_above=-999 required=5 tests=[AWL=-1.611, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, 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 i1GThwH5jXaX for ; Wed, 19 Jan 2011 01:25:58 -0800 (PST) Received: from mgw-da01.nokia.com (unknown [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 0E9853A6E80 for ; Wed, 19 Jan 2011 01:25:58 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0J9SZaE002256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 11:28:37 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-43--705472135; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680C02946C@rsys005a.comm.ad.roke.co.uk> Date: Wed, 19 Jan 2011 11:28:27 +0200 Message-Id: <6DDBB6E7-B15D-4C67-AD97-9BC293D67616@nokia.com> References: <2181C5F19DD0254692452BFF3EAF1D680BF5355C@rsys005a.comm.ad.roke.co.uk> <4D35F86B.1020006@isi.edu> <2181C5F19DD0254692452BFF3EAF1D680C02946C@rsys005a.comm.ad.roke.co.uk> To: "Ford, Alan" X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 19 Jan 2011 11:28:33 +0200 (EET) X-Nokia-AV: Clean Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Reducing option number usage 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, 19 Jan 2011 09:25:58 -0000 --Apple-Mail-43--705472135 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2011-1-19, at 11:19, Ford, Alan wrote: > At the moment I am favouring the four-bit sub-type > field, with a single allocated TCP option (and deal with any new > problems in a later MPTCP version ;) ). Sounds good to me. Lars --Apple-Mail-43--705472135 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDExOTA5MjgyOFowIwYJKoZIhvcNAQkE MRYEFD9FcrnIaEaAqDhmP2Ws14uS2tapMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AJWTHrOwprvxWsvhlEJCFsS0U6R6q9yoptVplcfYlHNcCYzImcxr9yoTHTiEBWZKKEj004jWhDBN sdOz7f7a0URjyrMm44iIXjRfAnjV9nR6M0Rdyjy5nyfe9hUov5kkLK/AD9em8Uidv2xEq+HNgX9W 6bW77TbheaKPzR8p8KxuQm+gt+tglqAYQwk+7RqMUPuDyO0p40844FnjK9XfIFhhhM3okJF4dbB+ MhDXTzoRnTX/uCN7LW+gMUfYwusNygx8vS19enCQ4WSRkEI6q6yiXzzHKJ5KqZw3oG5n7wUR/ZOJ rR0dltaKsvtSnpiXTA9W2VC1uwtc1k5XxcMQwaIAAAAAAAA= --Apple-Mail-43--705472135-- From philip.eardley@bt.com Wed Jan 19 06:23:21 2011 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 351DF3A712A for ; Wed, 19 Jan 2011 06:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.041 X-Spam-Level: X-Spam-Status: No, score=-102.041 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 TDeajEg4JA0b for ; Wed, 19 Jan 2011 06:23:16 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id 769003A70F5 for ; Wed, 19 Jan 2011 06:23:16 -0800 (PST) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 19 Jan 2011 14:25:56 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.127]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 19 Jan 2011 14:25:55 +0000 From: To: Date: Wed, 19 Jan 2011 14:25:54 +0000 Thread-Topic: Please review "Coupled Congestion Control for Multipath Transport Protocols" Thread-Index: Acu35MfQgcoqc8EjRMS2cjFBjdZuTQ== Message-ID: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F3275F300AEEMV65UKRDdoma_" MIME-Version: 1.0 Cc: multipathtcp@ietf.org Subject: [multipathtcp] Please review "Coupled Congestion Control for Multipath Transport Protocols" 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, 19 Jan 2011 14:23:21 -0000 --_000_9510D26531EF184D9017DF24659BB87F3275F300AEEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Multipath TCP WG has developed a congestion control algorithm that enab= les a TCP connection to use multiple paths. http://tools.ietf.org/html/draft-ietf-mptcp-congestion We're hoping to WG Last Call this document in February, so it would be grea= t if anyone from ICCRG could review it Thanks, Phil & Yoshifumi MPTCP WG Chairs Abstract Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as TCP New Reno independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, hence achieving resource pooling. This would increase the overall utilization of the network and also its robustness to failure. This document presents a congestion control algorithm which couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggresiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. --_000_9510D26531EF184D9017DF24659BB87F3275F300AEEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Multipath TC= P WG has developed a congestion control algorithm that enables a TCP connec= tion to use multiple paths.  

http://tools.= ietf.org/html/draft-ietf-mptcp-congestion

 

We’re hoping to WG L= ast Call this document in February, so it would be great if anyone from ICC= RG could review it

 

=

Thanks,

Phil & = Yoshifumi

MPTCP WG Chairs

 

Abstract<= /p>

 

   Often endpoints are c= onnected by multiple paths, but communications

&n= bsp;  are usually restricted to a single path per connection.  Re= source

   usage within the network woul= d be more efficient were it possible for

 &n= bsp; these multiple paths to be used concurrently.  Multipath TCP is a=

   proposal to achieve multipath trans= port in TCP.

 

&nb= sp;  New congestion control algorithms are needed for multipath transp= ort

   protocols such as Multipath TCP,= as single path algorithms have a

   se= ries of issues in the multipath context.  One of the prominent

   problems is that running existing algorithm= s such as TCP New Reno

   independently= on each path would give the multipath flow more than

=

   its fair share at a bottleneck link traversed by more tha= n one of its

   subflows.  Further= , it is desirable that a source with multiple paths

   paths, hence achieving re= source pooling.  This would increase the

&nb= sp;  overall utilization of the network and also its robustness to

   failure.

 

   This document presents a congest= ion control algorithm which couples

   = the congestion control algorithms running on different subflows by

   linking their increase functions, and dynami= cally controls the

   overall aggresive= ness of the multipath flow.  The result is a

   practical algorithm that is fair to TCP at bottlenecks while = moving

   traffic away from congested l= inks.

 

= = --_000_9510D26531EF184D9017DF24659BB87F3275F300AEEMV65UKRDdoma_-- From michawe@ifi.uio.no Wed Jan 19 12:10:37 2011 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 4E7173A71BB for ; Wed, 19 Jan 2011 12:10:37 -0800 (PST) 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 UuOKeZ6nl9T1 for ; Wed, 19 Jan 2011 12:10:36 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id E685D3A71AF for ; Wed, 19 Jan 2011 12:10:35 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1PfeP5-0002LN-TN; Wed, 19 Jan 2011 21:13:15 +0100 Received: from cpe-138-217-72-158.lnse4.lon.bigpond.net.au ([138.217.72.158] helo=[192.168.2.6]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1PfeP3-0008UR-S1; Wed, 19 Jan 2011 21:13:15 +0100 Message-Id: <57C8C185-B26F-4130-BB6C-7EB41C1E88BF@ifi.uio.no> From: Michael Welzl To: philip.eardley@bt.com In-Reply-To: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 Jan 2011 07:13:06 +1100 References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 12 sum msgs/h 5 total rcpts 5716 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F8790FB86A852ED2D594BDB6402A8A1321F3CC69 X-UiO-SPAM-Test: remote_host: 138.217.72.158 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 15 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: multipathtcp@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [multipathtcp] Please review "Coupled Congestion Control for Multipath Transport Protocols" 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, 19 Jan 2011 20:10:37 -0000 I'll do it! Cheers, Michael On Jan 20, 2011, at 1:25 AM, = wrote: > The Multipath TCP WG has developed a congestion control algorithm =20 > that enables a TCP connection to use multiple paths. > http://tools.ietf.org/html/draft-ietf-mptcp-congestion > > We=92re hoping to WG Last Call this document in February, so it would =20= > be great if anyone from ICCRG could review it > > Thanks, > Phil & Yoshifumi > MPTCP WG Chairs > > Abstract > > Often endpoints are connected by multiple paths, but communications > are usually restricted to a single path per connection. Resource > usage within the network would be more efficient were it possible =20= > for > these multiple paths to be used concurrently. Multipath TCP is a > proposal to achieve multipath transport in TCP. > > New congestion control algorithms are needed for multipath =20 > transport > protocols such as Multipath TCP, as single path algorithms have a > series of issues in the multipath context. One of the prominent > problems is that running existing algorithms such as TCP New Reno > independently on each path would give the multipath flow more than > its fair share at a bottleneck link traversed by more than one of =20= > its > subflows. Further, it is desirable that a source with multiple =20 > paths > available will transfer more traffic using the least congested of =20= > the > paths, hence achieving resource pooling. This would increase the > overall utilization of the network and also its robustness to > failure. > > This document presents a congestion control algorithm which couples > the congestion control algorithms running on different subflows by > linking their increase functions, and dynamically controls the > overall aggresiveness of the multipath flow. The result is a > practical algorithm that is fair to TCP at bottlenecks while moving > traffic away from congested links. > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From Karen.Nielsen@tieto.com Thu Jan 20 04:40:25 2011 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 AD70A3A71AE for ; Thu, 20 Jan 2011 04:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jsed2cKbUZBB for ; Thu, 20 Jan 2011 04:40:22 -0800 (PST) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by core3.amsl.com (Postfix) with ESMTP id F23523A7106 for ; Thu, 20 Jan 2011 04:40:21 -0800 (PST) X-AuditID: 83cfa824-b7cf4ae000002241-d4-4d382dd67985 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 6F.60.08769.6DD283D4; Thu, 20 Jan 2011 14:43:02 +0200 (EET) Received: from EXMB03.eu.tieto.com ([131.207.136.30]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Thu, 20 Jan 2011 14:43:02 +0200 From: To: Date: Thu, 20 Jan 2011 14:43:01 +0200 Thread-Topic: multipath congestion control and RFC 2861 Thread-Index: Acu4n5MaZobdsoAHS1KIkcenzzvUWw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B0A52F0F0B9EXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAARci5Uo= Subject: [multipathtcp] multipath congestion control and RFC 2861 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, 20 Jan 2011 12:40:25 -0000 --_000_CF340E42AED0874C81947E18863DE77B0A52F0F0B9EXMB03eutieto_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In the context of multipath TCP and coupled congestion control, I am wonder= ing what the thoughts are in respect to the limitation put on growth of not fully utilized congestion windows by RF= C 2861 - as exemplified by the following text from RFC 2861. "For the separate issue of the increase of the congestion window in response to an acknowledgement, we believe the correct behavior is for the sender to increase the congestion window only if the window was full when the acknowledgment arrived." The question seems relevant in connection with multipath TCP as it impacts = to willingness (and possibility) of TCP to "instantly" redistribute traffic from one failed path to other pa= ths - or perhaps more strictly speaking: to have n-1 paths absorb the traffic previously distributed on n paths. Also the issue becomes very relevant when discussing the applicability of t= he multipath congestion control to SCTP (CMT-SCTP) as SCTP (RFC 4960) in text at least (not sure about all implementations) i= ncorporates the RFC 2861 constrains on growth of not utilized CWNDs. Thanks. BR, Karen ***************************************************************************= ************** Karen Egede Nielsen Software Architect, Ph.D. Tieto Denmark A/S IP Solutions, Telecom & Media Skanderborgvej 232, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com Please note: The information contained in this message may be legally privi= leged and confidential and protected from disclosure. If the reader of this= message is not the intended recipient, you are hereby notified that any un= authorised use, distribution or copying of this communication is strictly p= rohibited. If you have received this communication in error, please notify = us immediately by replying to the message and deleting it from your compute= r. Thank You. --_000_CF340E42AED0874C81947E18863DE77B0A52F0F0B9EXMB03eutieto_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
In the context of multipath TCP and coupled congestion control, I am w= ondering what the thoughts are in respect to
the limitation put on growth of not fully utilized congestion windows = by RFC 2861 – as exemplified by the following text from RFC 2861.
 
  "For the sep= arate issue of the increase of the congestion window in
   response to= an acknowledgement, we believe the correct behavior is
   for the sen= der to increase the congestion window only if the window
   was full wh= en the acknowledgment arrived."
 
The question seems relevant in connection with multipath TCP as it imp= acts to willingness (and possibility)
of TCP to “instantly” redistribute traffic from one failed= path to other paths – or perhaps more strictly speaking: to have n-1= paths absorb
the traffic previously distributed on n paths.
 
Also the issue becomes very relevant when discussing the applicability= of the multipath congestion control to SCTP (CMT-SCTP)
as SCTP (RFC 4960)  in text at least (not sure about all implemen= tations) incorporates the RFC 2861 constrains on growth of not utilized CWN= Ds.
 
Thanks.
 
BR, Karen
 
 
***********************= ******************************************************************
Karen Egede Nielsen=
Software Architect, Ph.D.<= /font>
 
Tieto Denmark A/S
IP Solutions, Telecom &= ; Media
Skanderborgvej 232, 8260 V= iby J, DK-Denmark
Direct Phone / Mobile += ;45 25134336
E-mail: karen.nielsen@tiet= o.com
**************************= ***************************************************************
 
Please note: The inform= ation contained in this message may be legally privileged and confidential = and protected from disclosure. If the reader of this message is not the int= ended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is= strictly prohibited. If you have received this communication in error, ple= ase notify us immediately by replying to the message and deleting it from y= our computer. Thank You.
 
 
 
 
 
 --_000_CF340E42AED0874C81947E18863DE77B0A52F0F0B9EXMB03eutieto_-- From christoph.paasch@uclouvain.be Thu Jan 20 05:40:03 2011 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 8B4373A7123 for ; Thu, 20 Jan 2011 05:40:03 -0800 (PST) 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 0WqvDw7pSIdz for ; Thu, 20 Jan 2011 05:40:02 -0800 (PST) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 518283A7125 for ; Thu, 20 Jan 2011 05:40:02 -0800 (PST) Received: from cpaasch-mac.localnet (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 686C2E8849 for ; Thu, 20 Jan 2011 14:42:00 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp1.sgsi.ucl.ac.be 686C2E8849 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1295530920; bh=HUy4urxd55HaoK3oF18oTF9pQ8MiiIqVGGqiNItdEmU=; h=From:Reply-To:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding:Message-Id; b=Yord5vQ5P37SDzYVYOZfcNpHXoQXI+arWxJyCgxBPs7DLpPMl7T5UvqDHv0WiPvPp bzIbTv8GGsI43FzzrOUmwGjQKtYfW64yWTt0mvMKmI20GJEN73y1AavTAIGIc4Q6wi w17OgxWD2e4wzIprFXC433YO+N1tYPSoEZNiS3zk= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: "MultiPath TCP - IETF WG" Date: Thu, 20 Jan 2011 14:41:58 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.5.5; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201101201441.59202.christoph.paasch@uclouvain.be> X-Virus-Scanned: clamav-milter 0.96.5-exp at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 686C2E8849.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Linux Kernel MultiPath TCP --- new release available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 13:40:03 -0000 Hi all, we released a new version of the MultiPath TCP implementation in the Linux= =20 Kernel. Version 0.5 is now available for download. This release supports the Coupled Congestion Control as described in draft- ietf-mptcp-congestion-01. Also many bugs have been fixed for this release. =2D General Information is available at: http://inl.info.ucl.ac.be/mptcp https://scm.info.ucl.ac.be/trac/mptcp/wiki =2D Get the patch from: https://scm.info.ucl.ac.be/trac/mptcp/downloads =2D To contribute, provide feedback or ask questions, subscribe to the mptc= p- developpers mailing-list: https://listes-2.sipr.ucl.ac.be/sympa/info/mptcp-dev Regards, Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From khle@rim.com Thu Jan 20 10:00:27 2011 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 0E6F33A7161 for ; Thu, 20 Jan 2011 10:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 EwyqvZQUv3se for ; Thu, 20 Jan 2011 10:00:26 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 07E9E3A7155 for ; Thu, 20 Jan 2011 10:00:25 -0800 (PST) X-AuditID: 0a401fcb-b7ba1ae000000a54-df-4d3878dd14bb Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 9D.87.02644.DD8783D4; Thu, 20 Jan 2011 13:03:09 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Jan 2011 13:03:10 -0500 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: Thu, 20 Jan 2011 12:03:06 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05A48905@XCH02DFW.rim.net> In-Reply-To: <6DDBB6E7-B15D-4C67-AD97-9BC293D67616@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Reducing option number usage Thread-Index: Acu3u0Q/EdcxhOmcTlyuUywplMzyBwBDngAA References: <2181C5F19DD0254692452BFF3EAF1D680BF5355C@rsys005a.comm.ad.roke.co.uk><4D35F86B.1020006@isi.edu><2181C5F19DD0254692452BFF3EAF1D680C02946C@rsys005a.comm.ad.roke.co.uk> <6DDBB6E7-B15D-4C67-AD97-9BC293D67616@nokia.com> From: "Khiem Le" To: "Lars Eggert" , "Ford, Alan" X-OriginalArrivalTime: 20 Jan 2011 18:03:10.0392 (UTC) FILETIME=[4C58D380:01CBB8CC] X-Brightmail-Tracker: AAAAAwAAAZEXMpcWFzNPJQ== Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Reducing option number usage 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, 20 Jan 2011 18:00:27 -0000 Hi all, Using one TCP option with a subtype is a clean approach, but 4 bits for the subtype is rather small. It would be prudent to have a hook to enable possible future MPTCP extensions. I would propose we reserve one specific 4-bit code in the subtype, say 0000, for possible future extensions. That is, if the 4-bit subtype matches the specific 0000 pattern, that will indicate the presence of additional bits for the subtype. We need to worry about defining the additional bits only if and when the need arises. Khiem -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Wednesday, January 19, 2011 3:28 AM To: Ford, Alan Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Reducing option number usage On 2011-1-19, at 11:19, Ford, Alan wrote: > At the moment I am favouring the four-bit sub-type field, with a > single allocated TCP option (and deal with any new problems in a later > MPTCP version ;) ). Sounds good to me. Lars ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From dreibh@iem.uni-due.de Thu Jan 20 12:45:28 2011 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 368F03A6825 for ; Thu, 20 Jan 2011 12:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZd++aDfEM+6 for ; Thu, 20 Jan 2011 12:45:27 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by core3.amsl.com (Postfix) with ESMTP id 4C7EC3A6824 for ; Thu, 20 Jan 2011 12:45:25 -0800 (PST) Received: from lupo.localnet (p5086D399.dip.t-dialin.net [80.134.211.153]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p0KKdAmQ018730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jan 2011 21:39:15 +0100 From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics To: multipathtcp@ietf.org Date: Thu, 20 Jan 2011 20:59:15 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.37dreibholz; KDE/4.5.5; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1562289.NhSThEyVGy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201101202059.17652.dreibh@iem.uni-due.de> X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Cc: Karen.Nielsen@tieto.com Subject: Re: [multipathtcp] multipath congestion control and RFC 2861 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, 20 Jan 2011 20:45:28 -0000 --nextPart1562289.NhSThEyVGy Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Donnerstag 20 Januar 2011, Karen.Nielsen@tieto.com wrote: > Hi, >=20 > In the context of multipath TCP and coupled congestion control, I am > wondering what the thoughts are in respect to the limitation put on growth > of not fully utilized congestion windows by RFC 2861 - as exemplified by > the following text from RFC 2861. >=20 > "For the separate issue of the increase of the congestion window in > response to an acknowledgement, we believe the correct behavior is > for the sender to increase the congestion window only if the window > was full when the acknowledgment arrived." >=20 > The question seems relevant in connection with multipath TCP as it impacts > to willingness (and possibility) of TCP to "instantly" redistribute > traffic from one failed path to other paths - or perhaps more strictly > speaking: to have n-1 paths absorb the traffic previously distributed on n > paths. >=20 > Also the issue becomes very relevant when discussing the applicability of > the multipath congestion control to SCTP (CMT-SCTP) as SCTP (RFC 4960) in > text at least (not sure about all implementations) incorporates the RFC > 2861 constrains on growth of not utilized CWNDs. Dear Karen, on reception of an acknowledgement, CMT-SCTP (and CMT/RP-SCTP as well) only= =20 increases the CWND of a path if its window had been fully utilised before. Best regards =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Thomas Dreibholz University of Duisburg-Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D---------------------------------------------------------------------- E-Mail: dreibh@iem.uni-due.de Homepage: http://www.iem.uni-due.de/~dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --nextPart1562289.NhSThEyVGy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk04lBUACgkQ32BbsHYPLWW7wQCfW2SG/m6Qy0mpLUZNbkSeYJq/ AgsAoIA3eN4xISU5wjVQV3drEGBgPUxz =SrqJ -----END PGP SIGNATURE----- --nextPart1562289.NhSThEyVGy-- From Karen.Nielsen@tieto.com Thu Jan 20 23:37:10 2011 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 A4C193A68E3 for ; Thu, 20 Jan 2011 23:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 g1t5p7Avvy05 for ; Thu, 20 Jan 2011 23:37:09 -0800 (PST) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by core3.amsl.com (Postfix) with ESMTP id 61F633A68E1 for ; Thu, 20 Jan 2011 23:37:08 -0800 (PST) X-AuditID: 83cfa824-b7cf4ae000002241-9d-4d3938486496 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 46.4F.08769.848393D4; Fri, 21 Jan 2011 09:39:52 +0200 (EET) Received: from EXMB03.eu.tieto.com ([131.207.136.30]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Fri, 21 Jan 2011 09:39:52 +0200 From: To: , Date: Fri, 21 Jan 2011 09:39:50 +0200 Thread-Topic: [multipathtcp] multipath congestion control and RFC 2861 Thread-Index: Acu44hvImhC94T6HTQ+LMP7S39A/qwAW/uAA Message-ID: References: <201101202059.17652.dreibh@iem.uni-due.de> In-Reply-To: <201101202059.17652.dreibh@iem.uni-due.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAARczRsg= Subject: Re: [multipathtcp] multipath congestion control and RFC 2861 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 Jan 2011 07:37:10 -0000 Thanks! Yes - but - I am wondering=20 if there are any thoughts in respect to multipath tcp on this subject ? BR, Karen -----Original Message----- From: Thomas Dreibholz [mailto:dreibh@iem.uni-due.de]=20 Sent: 20. januar 2011 20:59 To: multipathtcp@ietf.org Cc: Nielsen Karen Subject: Re: [multipathtcp] multipath congestion control and RFC 2861 On Donnerstag 20 Januar 2011, Karen.Nielsen@tieto.com wrote: > Hi, >=20 > In the context of multipath TCP and coupled congestion control, I am=20 > wondering what the thoughts are in respect to the limitation put on=20 > growth of not fully utilized congestion windows by RFC 2861 - as=20 > exemplified by the following text from RFC 2861. >=20 > "For the separate issue of the increase of the congestion window in > response to an acknowledgement, we believe the correct behavior is > for the sender to increase the congestion window only if the window > was full when the acknowledgment arrived." >=20 > The question seems relevant in connection with multipath TCP as it=20 > impacts to willingness (and possibility) of TCP to "instantly"=20 > redistribute traffic from one failed path to other paths - or perhaps=20 > more strictly > speaking: to have n-1 paths absorb the traffic previously distributed=20 > on n paths. >=20 > Also the issue becomes very relevant when discussing the applicability=20 > of the multipath congestion control to SCTP (CMT-SCTP) as SCTP (RFC=20 > 4960) in text at least (not sure about all implementations)=20 > incorporates the RFC > 2861 constrains on growth of not utilized CWNDs. Dear Karen, on reception of an acknowledgement, CMT-SCTP (and CMT/RP-SCTP as well) only= increases the CWND of a path if its window had been fully utilised before. Best regards --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Thomas Dreibholz University of Duisburg-Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany ----------------------------------------------------------------------- E-Mail: dreibh@iem.uni-due.de Homepage: http://www.iem.uni-due.de/~dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From c.raiciu@cs.ucl.ac.uk Fri Jan 21 01:51:34 2011 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 1ACEF3A690C for ; Fri, 21 Jan 2011 01:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_39=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 ZxOYHkA1F4Ks for ; Fri, 21 Jan 2011 01:51:33 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 28D3C3A690A for ; Fri, 21 Jan 2011 01:51:33 -0800 (PST) Received: from [141.85.37.210] (helo=[192.168.1.66]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1PgDQg-0009S8-Gn; Fri, 21 Jan 2011 09:37:14 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Costin Raiciu In-Reply-To: Date: Fri, 21 Jan 2011 11:54:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201101202059.17652.dreibh@iem.uni-due.de> To: Karen.Nielsen X-Mailer: Apple Mail (2.1081) Cc: multipathtcp Subject: Re: [multipathtcp] multipath congestion control and RFC 2861 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 Jan 2011 09:51:34 -0000 Hi Karen, Our draft does not currently discuss the issues arising to app-limited = flows, where the cwnd is not always full. The answer, however, is = straightforward.=20 If MPTCP is app limited, some or all the subflows will be app-limited = (i.e. there will not be enough data to fill their cwnd). MPTCP should = apply RFC 2861 to the subflows in this situation. When app limited, MPTCP will probably use its best path (for instance = the lowest RTT one) as much as possible. This means that we will either = have a single subflow with data on it (here RFC 2861 should appliy = directly), or one subflow that is using all its cwnd and a few others that are app = limited (RFC 2861 will only apply to the latter). =20 One remaning question is: how should MPTCP update alpha when some = subflows are app limited? The current draft covers this by demanding = that min(flighsize,cwnd) should be used when computing alpha. When all flows are app limited, the formula still applies but the = resulting alpha does not really matter, as cwnds are not increased = anyways. Cheers, Costin On 21 Jan 2011, at 09:39, Karen.Nielsen wrote: > Thanks! Yes - but - I am wondering=20 > if there are any thoughts in respect to multipath tcp on this subject = ? >=20 > BR, Karen >=20 > -----Original Message----- > From: Thomas Dreibholz [mailto:dreibh@iem.uni-due.de]=20 > Sent: 20. januar 2011 20:59 > To: multipathtcp@ietf.org > Cc: Nielsen Karen > Subject: Re: [multipathtcp] multipath congestion control and RFC 2861 >=20 > On Donnerstag 20 Januar 2011, Karen.Nielsen@tieto.com wrote: >> Hi, >>=20 >> In the context of multipath TCP and coupled congestion control, I am=20= >> wondering what the thoughts are in respect to the limitation put on=20= >> growth of not fully utilized congestion windows by RFC 2861 - as=20 >> exemplified by the following text from RFC 2861. >>=20 >> "For the separate issue of the increase of the congestion window in >> response to an acknowledgement, we believe the correct behavior is >> for the sender to increase the congestion window only if the window >> was full when the acknowledgment arrived." >>=20 >> The question seems relevant in connection with multipath TCP as it=20 >> impacts to willingness (and possibility) of TCP to "instantly"=20 >> redistribute traffic from one failed path to other paths - or perhaps=20= >> more strictly >> speaking: to have n-1 paths absorb the traffic previously distributed=20= >> on n paths. >>=20 >> Also the issue becomes very relevant when discussing the = applicability=20 >> of the multipath congestion control to SCTP (CMT-SCTP) as SCTP (RFC=20= >> 4960) in text at least (not sure about all implementations)=20 >> incorporates the RFC >> 2861 constrains on growth of not utilized CWNDs. >=20 > Dear Karen, >=20 > on reception of an acknowledgement, CMT-SCTP (and CMT/RP-SCTP as well) = only increases the CWND of a path if its window had been fully utilised = before. >=20 >=20 > Best regards > --=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Thomas Dreibholz >=20 > University of Duisburg-Essen, Room ES210 > Inst. for Experimental Mathematics Ellernstra=DFe 29 > Computer Networking Technology Group D-45326 Essen/Germany > = ----------------------------------------------------------------------- > E-Mail: dreibh@iem.uni-due.de > Homepage: http://www.iem.uni-due.de/~dreibh > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From Karen.Nielsen@tieto.com Fri Jan 21 02:23:14 2011 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 3E3C93A6916 for ; Fri, 21 Jan 2011 02:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJJ2Yi1Qg12v for ; Fri, 21 Jan 2011 02:23:13 -0800 (PST) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by core3.amsl.com (Postfix) with ESMTP id 6ECA83A6902 for ; Fri, 21 Jan 2011 02:23:12 -0800 (PST) X-AuditID: 83cfa826-b7b8cae0000042cc-dd-4d395f34c0ef Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 80.7C.17100.43F593D4; Fri, 21 Jan 2011 12:25:57 +0200 (EET) Received: from EXMB03.eu.tieto.com ([131.207.136.30]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Fri, 21 Jan 2011 12:25:56 +0200 From: To: Date: Fri, 21 Jan 2011 12:25:55 +0200 Thread-Topic: [multipathtcp] multipath congestion control and RFC 2861 Thread-Index: Acu5UStSL5bY6iSFTaSXqvHH4ypHlwABB0wQ Message-ID: References: <201101202059.17652.dreibh@iem.uni-due.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAARczRsg= Cc: multipathtcp@ietf.org, Martin.Klausen@tieto.com, Michael.Larsen@tieto.com Subject: Re: [multipathtcp] multipath congestion control and RFC 2861 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 Jan 2011 10:23:14 -0000 Thanks a lot for the clear answer. Also agree with the technical approach. Thanks ! BR, Karen -----Original Message----- From: Costin Raiciu [mailto:c.raiciu@cs.ucl.ac.uk]=20 Sent: 21. januar 2011 10:54 To: Nielsen Karen Cc: dreibh; multipathtcp Subject: Re: [multipathtcp] multipath congestion control and RFC 2861 Hi Karen, Our draft does not currently discuss the issues arising to app-limited flow= s, where the cwnd is not always full. The answer, however, is straightforwa= rd.=20 If MPTCP is app limited, some or all the subflows will be app-limited (i.e.= there will not be enough data to fill their cwnd). MPTCP should apply RFC = 2861 to the subflows in this situation. When app limited, MPTCP will probably use its best path (for instance the l= owest RTT one) as much as possible. This means that we will either have a = single subflow with data on it (here RFC 2861 should appliy directly), or one subflow that is using all its cwnd and a few others that are app lim= ited (RFC 2861 will only apply to the latter). =20 One remaning question is: how should MPTCP update alpha when some subflows = are app limited? The current draft covers this by demanding that min(flighs= ize,cwnd) should be used when computing alpha. When all flows are app limited, the formula still applies but the resulting= alpha does not really matter, as cwnds are not increased anyways. Cheers, Costin On 21 Jan 2011, at 09:39, Karen.Nielsen wrote: > Thanks! Yes - but - I am wondering=20 > if there are any thoughts in respect to multipath tcp on this subject ? >=20 > BR, Karen >=20 > -----Original Message----- > From: Thomas Dreibholz [mailto:dreibh@iem.uni-due.de]=20 > Sent: 20. januar 2011 20:59 > To: multipathtcp@ietf.org > Cc: Nielsen Karen > Subject: Re: [multipathtcp] multipath congestion control and RFC 2861 >=20 > On Donnerstag 20 Januar 2011, Karen.Nielsen@tieto.com wrote: >> Hi, >>=20 >> In the context of multipath TCP and coupled congestion control, I am=20 >> wondering what the thoughts are in respect to the limitation put on=20 >> growth of not fully utilized congestion windows by RFC 2861 - as=20 >> exemplified by the following text from RFC 2861. >>=20 >> "For the separate issue of the increase of the congestion window in >> response to an acknowledgement, we believe the correct behavior is >> for the sender to increase the congestion window only if the window >> was full when the acknowledgment arrived." >>=20 >> The question seems relevant in connection with multipath TCP as it=20 >> impacts to willingness (and possibility) of TCP to "instantly"=20 >> redistribute traffic from one failed path to other paths - or perhaps=20 >> more strictly >> speaking: to have n-1 paths absorb the traffic previously distributed=20 >> on n paths. >>=20 >> Also the issue becomes very relevant when discussing the applicability=20 >> of the multipath congestion control to SCTP (CMT-SCTP) as SCTP (RFC=20 >> 4960) in text at least (not sure about all implementations)=20 >> incorporates the RFC >> 2861 constrains on growth of not utilized CWNDs. >=20 > Dear Karen, >=20 > on reception of an acknowledgement, CMT-SCTP (and CMT/RP-SCTP as well) on= ly increases the CWND of a path if its window had been fully utilised befor= e. >=20 >=20 > Best regards > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Thomas Dreibholz >=20 > University of Duisburg-Essen, Room ES210 > Inst. for Experimental Mathematics Ellernstra=DFe 29 > Computer Networking Technology Group D-45326 Essen/Germany > ----------------------------------------------------------------------- > E-Mail: dreibh@iem.uni-due.de > Homepage: http://www.iem.uni-due.de/~dreibh > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From Internet-Drafts@ietf.org Fri Jan 21 08:45:03 2011 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 439933A6A49; Fri, 21 Jan 2011 08:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWtr2j7s8KOA; Fri, 21 Jan 2011 08:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C60AF3A6A5B; Fri, 21 Jan 2011 08:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110121164501.29805.80620.idtracker@localhost> Date: Fri, 21 Jan 2011 08:45:01 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-architecture-05.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 16:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : Architectural Guidelines for Multipath TCP Development Author(s) : A. Ford, et al. Filename : draft-ietf-mptcp-architecture-05.txt Pages : 29 Date : 2011-01-21 Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput. This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP protocol. This document lists certain high level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-architecture-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mptcp-architecture-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-21084037.I-D@ietf.org> --NextPart-- From prvs=1002f11ad7=alan.ford@roke.co.uk Fri Jan 21 08:49:50 2011 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 EEA9E3A6A53 for ; Fri, 21 Jan 2011 08:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 mnA6ztQvbcUn for ; Fri, 21 Jan 2011 08:49:49 -0800 (PST) Received: from ixe-mta-29.emailfiltering.com (ixe-mta-29-tx.emailfiltering.com [194.116.199.160]) by core3.amsl.com (Postfix) with ESMTP id 0A4A73A6A2B for ; Fri, 21 Jan 2011 08:49:48 -0800 (PST) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by ixe-mta-29.emailfiltering.com with emfmta (version 4.8.0.410) vanilla id 264214102 for multipathtcp@ietf.org; 6a85a5d70d1ad5c7; Fri, 21 Jan 2011 16:52:34 +0000 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, 21 Jan 2011 16:52:26 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680C091016@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <20110121164501.29805.80620.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] I-D Action:draft-ietf-mptcp-architecture-05.txt Thread-Index: Acu5i0T8Utv54FfIRYi4FHX+LGLvmAAAATKw References: <20110121164501.29805.80620.idtracker@localhost> From: "Ford, Alan" To: Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-architecture-05.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 16:49:51 -0000 Hi all, This new version addresses comments/discusses received from the IESG: * Break-before-make now introduced in S2.2.1 (Russ/Joel) * Urgent pointer clarified and toned down (Jari/Cullen) * Connection ID text rearranged (Alexey) * MIB comments added (David/Dan) * ECMP introduced in introduction (Stewart) Also minor clarity and editorial issues raised by Joel and Juergen all corrected (notably in intro and S2.2.1). Many thanks for all the feedback. Regards, Alan > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: 21 January 2011 16:45 > To: i-d-announce@ietf.org > Cc: multipathtcp@ietf.org > Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-architecture-05.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multipath TCP Working Group of the IETF. >=20 >=20 > Title : Architectural Guidelines for Multipath TCP > Development > Author(s) : A. Ford, et al. > Filename : draft-ietf-mptcp-architecture-05.txt > Pages : 29 > Date : 2011-01-21 >=20 > Hosts are often connected by multiple paths, but TCP restricts > communications to a single path per transport connection. Resource > usage within the network would be more efficient were these multiple > paths able to be used concurrently. This should enhance user > experience through improved resilience to network failure and higher > throughput. >=20 > This document outlines architectural guidelines for the development > of a Multipath Transport Protocol, with references to how these > architectural components come together in the development of a > Multipath TCP protocol. This document lists certain high level > design decisions that provide foundations for the design of the MPTCP > protocol, based upon these architectural requirements. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mptcp-architecture-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From michawe@ifi.uio.no Sun Jan 23 21:21:13 2011 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 CD9F93A6A4B for ; Sun, 23 Jan 2011 21:21:13 -0800 (PST) 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 cxs6iQPQM-eT for ; Sun, 23 Jan 2011 21:21:12 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 42D603A6A47 for ; Sun, 23 Jan 2011 21:21:12 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1PhEuK-0001E9-QX; Mon, 24 Jan 2011 06:24:04 +0100 Received: from [136.186.229.244] by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1PhEuJ-0003el-71; Mon, 24 Jan 2011 06:24:04 +0100 Message-Id: <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> From: Michael Welzl To: "philip.eardley@bt.com>" In-Reply-To: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Jan 2011 16:23:58 +1100 References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 3 total rcpts 5871 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0B26ECE57A9D1FA5FA8BF75B0D8E8E830178624B X-UiO-SPAM-Test: remote_host: 136.186.229.244 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 115 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: multipathtcp@ietf.org, "iccrg@cs.ucl.ac.uk list" Subject: Re: [multipathtcp] Please review "Coupled Congestion Control for Multipath Transport Protocols" 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 Jan 2011 05:21:13 -0000 Hi, Here's my review: This is, on the whole, a very well written document - short and =20 concise, and clear and to the point. I noticed just a few issues: - On page 6, when you first introduce alpha, you call it "a =20 parameter .. that describes the aggressiveness of the multipath flow" (missing "s" in "aggressive" in that sentence BTW). ... so this gives the impression that this is a per-aggregate =20 parameter. Yet, later, on page 7, you state that "alpha must be =20 computed for each multipath flow". Indeed I have a hard time imagining =20= how alpha can ensure that you send at least as much as TCP would send =20= on the best path while just having a single constant across all sub-=20 flows. So I assume it's a per-subflow-variable - but then it should =20 get an index i. I would strongly suggest giving a simple example where MPTCP is used =20 across two very different paths, just to show how alpha indeed ensures =20= the throughput of TCP on the best path because that seems to be hard =20 to grasp with intuition. The formula presented on page 7 is hard to read. I have no problem =20 with the formula that's similar in style on page 9 - but in this =20 particular one, things just seem to get into the way of each other, =20 and presenting it in a different style would be better. e.g.: what is =20= max_i? Is this a function, traversing all i's, like sum_i below? But =20 then it looks as if that's a function covering the whole fraction on =20 the right, but the denominator (rtt_i^2) at the same time seems to be =20= connected the larger fraction... I don't get it. Or does max_i just =20 refer to the numerator perhaps? Also, upon reading this bit, I immediately began to wonder when and =20 how often this is calculated. You answer this later, but the reader =20 really expects an answer right here, where the formula appears - so =20 you could, for instance, provide a forward reference, saying that this =20= will be discussed in the next section. Which brings me to the "when is it calculated" text on page 8. The =20 paragraph starting with "It is possible to implement": here you say that it's costly to update tot_cwnd on each ack, but =20 later you say that "...implementation will update (missing 'the') =20 tot_cwnd value whenever the individual subflows' windows are =20 updated." Please explain how this is not the same as updating on each =20= ack? I would expect that these windows ARE updated on each ack... so =20 what's the difference? Next par.: "We propose alpha _to_ be a per-connection variable, ..." section 5 par 1: "...allocate _a_ zero window..." "resulting rate _will_ fluctuate unpredictably...." par 2: "algorithm will allocate _a_ window to the subflows..." "When the loss rates differ, _a_ progressively _larger_ window will be =20= allocated..." section 6: "_A_ detailed security analysis..." That's it! I hope it's helpful. Cheers, Michael On Jan 20, 2011, at 1:25 AM, = wrote: > The Multipath TCP WG has developed a congestion control algorithm =20 > that enables a TCP connection to use multiple paths. > http://tools.ietf.org/html/draft-ietf-mptcp-congestion > > We=92re hoping to WG Last Call this document in February, so it would =20= > be great if anyone from ICCRG could review it > > Thanks, > Phil & Yoshifumi > MPTCP WG Chairs > > Abstract > > Often endpoints are connected by multiple paths, but communications > are usually restricted to a single path per connection. Resource > usage within the network would be more efficient were it possible =20= > for > these multiple paths to be used concurrently. Multipath TCP is a > proposal to achieve multipath transport in TCP. > > New congestion control algorithms are needed for multipath =20 > transport > protocols such as Multipath TCP, as single path algorithms have a > series of issues in the multipath context. One of the prominent > problems is that running existing algorithms such as TCP New Reno > independently on each path would give the multipath flow more than > its fair share at a bottleneck link traversed by more than one of =20= > its > subflows. Further, it is desirable that a source with multiple =20 > paths > available will transfer more traffic using the least congested of =20= > the > paths, hence achieving resource pooling. This would increase the > overall utilization of the network and also its robustness to > failure. > > This document presents a congestion control algorithm which couples > the congestion control algorithms running on different subflows by > linking their increase functions, and dynamically controls the > overall aggresiveness of the multipath flow. The result is a > practical algorithm that is fair to TCP at bottlenecks while moving > traffic away from congested links. > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From mark.j.handley@gmail.com Mon Jan 24 01:47:34 2011 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 A8C063A6A8D for ; Mon, 24 Jan 2011 01:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2wGfeBMovFV for ; Mon, 24 Jan 2011 01:47:33 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7CAE33A6A59 for ; Mon, 24 Jan 2011 01:47:33 -0800 (PST) Received: by wyf23 with SMTP id 23so4046118wyf.31 for ; Mon, 24 Jan 2011 01:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=LxruAtGXM9pN0yHmsarfuANDJW9xORCL283BYeOL5qA=; b=FgXWxF69OXJmP5YukQhSegREOIaBusCMfHni5IHWHgEqJnWVLiu9676f9aFsR9myi9 KGT2tAk/9oEGx6B1RsUAeKDserVZmbQ45qnMCLQqqfUNs/bQwkPPLFMcmqEtJA25D3Zg BbACPxvHAAEQT6GaSknQ2P5m/T5Oq4bhn7YQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=qBCBEZpnQ1UmSJuVYAPlCEd7FFdU2iCs4zRX/jb6B2vQrBz5DAshQIAdHLDtAeOLlx x1C8EAZHFYO1QkrGQNisiluPRQCy1482KRxTdN6iEomuqsq4XWrovr86qhKX3I9/ln2s AVia8MASxJmHPRlv/hQuVgwuGaWHnTqtTOc3s= Received: by 10.216.177.72 with SMTP id c50mr3196756wem.72.1295862627122; Mon, 24 Jan 2011 01:50:27 -0800 (PST) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.216.241.201 with HTTP; Mon, 24 Jan 2011 01:50:07 -0800 (PST) In-Reply-To: <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> From: Mark Handley Date: Mon, 24 Jan 2011 09:50:07 +0000 X-Google-Sender-Auth: afkIydoiT5oZSszGouUsG6i0Du4 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org, "iccrg@cs.ucl.ac.uk list" Subject: Re: [multipathtcp] Please review "Coupled Congestion Control for Multipath Transport Protocols" 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 Jan 2011 09:47:34 -0000 On 24 January 2011 05:23, Michael Welzl wrote: > Hi, > > Here's my review: > > This is, on the whole, a very well written document - short and concise, and > clear and to the point. I noticed just a few issues: > > > - On page 6, when you first introduce alpha, you call it "a parameter .. > that describes the aggressiveness of the multipath flow" > (missing "s" in "aggressive" in that sentence BTW). > ... so this gives the impression that this is a per-aggregate parameter. > Yet, later, on page 7, you state that "alpha must be computed for each > multipath flow". Indeed I have a hard time imagining how alpha can ensure > that you send at least as much as TCP would send on the best path while just > having a single constant across all sub-flows. So I assume it's a > per-subflow-variable - but then it should get an index i. > I would strongly suggest giving a simple example where MPTCP is used across > two very different paths, just to show how alpha indeed ensures the > throughput of TCP on the best path because that seems to be hard to grasp > with intuition. Alpha is computed for each connection - the same alpha applies to all subflows, so as to control the overall aggressiveness. It is not a per-subflow variable. Obviously our text is unclear on this - is there somewhere in particular that made you think it was per-subflow? Or is it just the wording on page 7 ("alpha must be computed for each multipath flow") which could be rephased "for each multipath connection" if that helps. - Mark From michawe@ifi.uio.no Mon Jan 24 02:02:49 2011 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 A766E3A6A6C for ; Mon, 24 Jan 2011 02:02:49 -0800 (PST) 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 HirwCX-qgTHP for ; Mon, 24 Jan 2011 02:02:48 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 4B8E13A69D5 for ; Mon, 24 Jan 2011 02:02:48 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1PhJIr-0008Pi-W5; Mon, 24 Jan 2011 11:05:41 +0100 Received: from cpe-138-217-72-158.vic.bigpond.net.au ([138.217.72.158] helo=[192.168.2.6]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1PhJIq-0000wZ-3t; Mon, 24 Jan 2011 11:05:41 +0100 Message-Id: From: Michael Welzl To: Mark Handley 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: Mon, 24 Jan 2011 21:05:33 +1100 References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 11 sum msgs/h 4 total rcpts 5893 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 88909CD4B60CF98F5C602C85ECC98493550D3F6D X-UiO-SPAM-Test: remote_host: 138.217.72.158 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 64 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: multipathtcp@ietf.org, "iccrg@cs.ucl.ac.uk list" Subject: Re: [multipathtcp] Please review "Coupled Congestion Control for Multipath Transport Protocols" 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 Jan 2011 10:02:49 -0000 >> - On page 6, when you first introduce alpha, you call it "a >> parameter .. >> that describes the aggressiveness of the multipath flow" >> (missing "s" in "aggressive" in that sentence BTW). >> ... so this gives the impression that this is a per-aggregate >> parameter. >> Yet, later, on page 7, you state that "alpha must be computed for >> each >> multipath flow". Indeed I have a hard time imagining how alpha can >> ensure >> that you send at least as much as TCP would send on the best path >> while just >> having a single constant across all sub-flows. So I assume it's a >> per-subflow-variable - but then it should get an index i. >> I would strongly suggest giving a simple example where MPTCP is >> used across >> two very different paths, just to show how alpha indeed ensures the >> throughput of TCP on the best path because that seems to be hard to >> grasp >> with intuition. > > Alpha is computed for each connection - the same alpha applies to all > subflows, so as to control the overall aggressiveness. It is not a > per-subflow variable. > > Obviously our text is unclear on this - is there somewhere in > particular that made you think it was per-subflow? Or is it just the > wording on page 7 ("alpha must be computed for each multipath flow") > which could be rephased "for each multipath connection" if that helps. It's really only this wording. and yes, this simple change does the trick - i guess it was just me, the word "flow" made me think of sub- flows. About another sentence I wrote above: "Indeed I have a hard time imagining..." - now I wonder what gave me this hard time? It actually seems clear enough. Still, an example would be nice to have, but I take back the "strongly suggest". Sorry, I must have been tired. Cheers, Michael From bruno.mongazon-cazavet@alcatel-lucent.com Tue Jan 25 01:46:15 2011 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 DE4673A6B88 for ; Tue, 25 Jan 2011 01:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.693 X-Spam-Level: X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bL8ZQeBPdl8 for ; Tue, 25 Jan 2011 01:46:15 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 9ACEB3A6B87 for ; Tue, 25 Jan 2011 01:46:14 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0P9k251017477 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 25 Jan 2011 10:49:04 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Jan 2011 10:48:34 +0100 Message-ID: <4D3E9C6D.8080009@alcatel-lucent.com> Date: Tue, 25 Jan 2011 10:48:29 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 09:46:16 -0000 Dear all, Could you elaborate on the behaviour of MPTCP when the paths have significant bit rate differences, such as PPP on WCDMA and WiFi ? From my personal experimentation, i have in short: WCDMA path only => 700 Kbits/s WiFi path only => 21 Mbits/s WCMDA+WiFi paths => 15 Mbits/s The traffic kind is of Uplink nature. My feeling is that the balancing algorithm is not suited to such bit rates differences. Because the paths are unequal, passing data on the slowest path necessary slows the fastest path. Although difference in bit rates matter, the same would be expected with differences in RTT. Thanks for your answers. Bruno From bruno.mongazon-cazavet@alcatel-lucent.com Tue Jan 25 02:01:17 2011 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 2CE333A6B96 for ; Tue, 25 Jan 2011 02:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.260, 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 QPZ4RYDKc5AP for ; Tue, 25 Jan 2011 02:01:16 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id E79093A6990 for ; Tue, 25 Jan 2011 02:01:15 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0PA4C6h026562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 25 Jan 2011 11:04:12 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Jan 2011 11:04:11 +0100 Message-ID: <4D3EA01B.4010707@alcatel-lucent.com> Date: Tue, 25 Jan 2011 11:04:11 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [multipathtcp] Path addition time 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 Jan 2011 10:01:17 -0000 Dear All, Could you elaborate on the path addition time of MPTCP ? What i call "path addition time" is the elapsed time between arrival of TCP SYN-ACK on the main path and arrival of TCP SYN-ACK on the alternate path (understanding for the same MPTCP connection). What i see from my personal experimentation is that the TCP SYN on the alternate path fails and needs retransmission. This leads to an almost 3 seconds "path addition time". Why does the TCP SYN fails ? My current explanation is that there is already a high traffic load on the main path (upload kind). Although this might be "experimentation" specific, i guess there might be a design problem, in the sense that MPTCP relies on regular TCP SYN behavior to make an alternate path ready. This is critical if MPTCP is used for handoff purposes. Thanks for your answers. Bruno From c.raiciu@cs.ucl.ac.uk Tue Jan 25 02:01:34 2011 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 77AFB3A6B96 for ; Tue, 25 Jan 2011 02:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, GB_ABOUTYOU=0.5, J_CHICKENPOX_54=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 WyyTuMMx3n7k for ; Tue, 25 Jan 2011 02:01:33 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id AB8903A6990 for ; Tue, 25 Jan 2011 02:01:33 -0800 (PST) Received: from [141.85.37.210] (helo=[192.168.1.66]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1PhfSi-000AMU-0b; Tue, 25 Jan 2011 09:45:20 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: <4D3E9C6D.8080009@alcatel-lucent.com> Date: Tue, 25 Jan 2011 12:04:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3E9C6D.8080009@alcatel-lucent.com> To: Bruno Mongazon-Cazavet X-Mailer: Apple Mail (2.1081) Cc: multipathtcp Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 10:01:34 -0000 Hi Bruno, We've tested the algorithm across a wide range of differences in RTTs = and bandwidth between paths in simulation; there we found that MPTCP = throughput was what it should be, except when one or both paths were = experiencing frequent timeouts.=20 We've also tested it in practice with 3g/wifi and found MPTCP was within = 10-15% of what it should get. I am interested to find more details about your setup. Have you looked = at the number of timeouts in your test? What implementation are you = using?=20 Thanks, Costin On 25 Jan 2011, at 11:48, Bruno Mongazon-Cazavet wrote: > Dear all, >=20 > Could you elaborate on the behaviour of MPTCP when the paths have = significant bit rate differences, such as PPP on WCDMA and WiFi ? >=20 > =46rom my personal experimentation, i have in short: >=20 > WCDMA path only =3D> 700 Kbits/s > WiFi path only =3D> 21 Mbits/s > WCMDA+WiFi paths =3D> 15 Mbits/s >=20 > The traffic kind is of Uplink nature. >=20 > My feeling is that the balancing algorithm is not suited to such bit = rates differences. > Because the paths are unequal, passing data on the slowest path = necessary slows the fastest path. > Although difference in bit rates matter, the same would be expected = with differences in RTT. >=20 > Thanks for your answers. > Bruno >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From olivier.bonaventure@uclouvain.be Tue Jan 25 02:07:57 2011 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 608C03A6B8E for ; Tue, 25 Jan 2011 02:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbqKWW+77Um3 for ; Tue, 25 Jan 2011 02:07:56 -0800 (PST) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 59D5B3A6B8A for ; Tue, 25 Jan 2011 02:07:56 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id EFF2AE9944; Tue, 25 Jan 2011 11:10:17 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp1.sgsi.ucl.ac.be EFF2AE9944 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1295950218; bh=uenZofESxKAxKGxQN7fgMDzS3UDULaAWn4R2ET23r7o=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lXhHu14jmYUrXPE+NFT7e8PXA6LjI9DMKOMLzXgzSu5xvD+kJEIGlZ+FmYE0pwgMN 4okiW5nQWAO+MqEPNUosB2bRZUeF06aBudfriFTeVQA5gYbZnIv5VhyH1n+Fb8Dduk O5Y2MKrEEY34juK7r98nL6a+VCGheKgEwjp0LTXY= Message-ID: <4D3EA188.3020807@uclouvain.be> Date: Tue, 25 Jan 2011 11:10:16 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruno Mongazon-Cazavet References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3EA01B.4010707@alcatel-lucent.com> In-Reply-To: <4D3EA01B.4010707@alcatel-lucent.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5-exp at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: EFF2AE9944.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Path addition time X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 10:07:57 -0000 Bruno, > > Could you elaborate on the path addition time of MPTCP ? > > > What i call "path addition time" is the elapsed time between arrival of > TCP SYN-ACK on the main path and arrival of TCP SYN-ACK on the alternate > path (understanding for the same MPTCP connection). > > What i see from my personal experimentation is that the TCP SYN on the > alternate path fails and needs retransmission. This leads to an almost 3 > seconds "path addition time". Why does the TCP SYN fails ? My current > explanation is that there is already a high traffic load on the main > path (upload kind). Could you elaborate a bit on the experimental setup that you used ? Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From c.raiciu@cs.ucl.ac.uk Tue Jan 25 02:08:47 2011 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 6247B3A6B92 for ; Tue, 25 Jan 2011 02:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 YI+VqX1aqJXW for ; Tue, 25 Jan 2011 02:08:46 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 736A03A6B8A for ; Tue, 25 Jan 2011 02:08:46 -0800 (PST) Received: from [141.85.37.210] (helo=[192.168.1.66]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1PhfZh-000AMk-Ge; Tue, 25 Jan 2011 09:52:33 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: <4D3EA01B.4010707@alcatel-lucent.com> Date: Tue, 25 Jan 2011 12:11:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3EA01B.4010707@alcatel-lucent.com> To: Bruno Mongazon-Cazavet X-Mailer: Apple Mail (2.1081) Cc: multipathtcp Subject: Re: [multipathtcp] Path addition time 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 Jan 2011 10:08:47 -0000 Hi, =46rom your emails, it seems you are using the userland mptcp = implementation - that one used to lose the first packet on the = subsequent subflows. That is just an implementation quirk (some weird = interaction between libpcap and raw sockets), and has nothing to do with = MPTCP. By the way, people from UCL Belgium and Aalto university have been bug = fixing the Linux kernel implementation of MPTCP; as far as I know this = now runs the coupled congestion controller. Please use that for further = tests; the underlying stack is much more robust than the one used by the = userland stack, which is an old 2.3.xx stack. As for the path addition time, MPTCP waits for the first subflow to be = established before it opens the additional ones. After the initial flow = is setup, all additional subflows can be opened simultaneously, and will = be as fast to open as regular TCP connections. What would you like to = optimize exactly? Cheers, Costin On 25 Jan 2011, at 12:04, Bruno Mongazon-Cazavet wrote: > Dear All, >=20 > Could you elaborate on the path addition time of MPTCP ? >=20 >=20 > What i call "path addition time" is the elapsed time between arrival = of TCP SYN-ACK on the main path and arrival of TCP SYN-ACK on the = alternate path (understanding for the same MPTCP connection). >=20 > What i see from my personal experimentation is that the TCP SYN on the = alternate path fails and needs retransmission. This leads to an almost 3 = seconds "path addition time". Why does the TCP SYN fails ? My current = explanation is that there is already a high traffic load on the main = path (upload kind). >=20 > Although this might be "experimentation" specific, i guess there might = be a design problem, in the sense that MPTCP relies on regular TCP SYN = behavior to make an alternate path ready. This is critical if MPTCP is = used for handoff purposes. >=20 > Thanks for your answers. > Bruno >=20 >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From bruno.mongazon-cazavet@alcatel-lucent.com Tue Jan 25 02:11:53 2011 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 86E393A6B8D for ; Tue, 25 Jan 2011 02:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.236, 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 lJvFITcgpahS for ; Tue, 25 Jan 2011 02:11:52 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 7BE793A6A87 for ; Tue, 25 Jan 2011 02:11:52 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0PAEQk0007628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 25 Jan 2011 11:14:48 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Jan 2011 11:14:36 +0100 Message-ID: <4D3EA287.5060401@alcatel-lucent.com> Date: Tue, 25 Jan 2011 11:14:31 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3EA01B.4010707@alcatel-lucent.com> In-Reply-To: <4D3EA01B.4010707@alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [multipathtcp] Weight usage of source routing 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 Jan 2011 10:11:53 -0000 Dear All, Could you elaborate on the possible relationship between MPTCP paths and weights assigned to paths in IP source routing ? Giving the setup of your implementation, a weight needs to be given to each interface. From my WCDMA/WiFi experimentation, it looks like it requires a higher value for WCDMA than WiFi for WCDMA to be really used. More precisely, if the weight of wcdma is lower than Wifi, wcdma is never used by MPTCP as an alternate path. The question is: Is there a relationship ? Or does MPTCP requires a convenient setting of IP source routing regarding weight ? Thanks, Bruno From bruno.mongazon-cazavet@alcatel-lucent.com Tue Jan 25 02:16:18 2011 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 194B63A6A94 for ; Tue, 25 Jan 2011 02:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.482 X-Spam-Level: X-Spam-Status: No, score=-5.482 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMvioUr1emIP for ; Tue, 25 Jan 2011 02:16:17 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id F11D33A6990 for ; Tue, 25 Jan 2011 02:16:16 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0PAIl7u029797 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2011 11:19:07 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Jan 2011 11:18:59 +0100 Message-ID: <4D3EA393.5040500@alcatel-lucent.com> Date: Tue, 25 Jan 2011 11:18:59 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Costin Raiciu References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3E9C6D.8080009@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: multipathtcp Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 10:16:18 -0000 Le 25/01/2011 11:04, Costin Raiciu a écrit : > Hi Bruno, > > We've tested the algorithm across a wide range of differences in RTTs and bandwidth between paths in simulation; there we found that MPTCP throughput was what it should be, except when one or both paths were experiencing frequent timeouts. > We've also tested it in practice with 3g/wifi and found MPTCP was within 10-15% of what it should get. > > I am interested to find more details about your setup. Have you looked at the number of timeouts in your test? Which timeouts ? > What implementation are you using? Linux 2.6.28 vanilla + MPTCP 0.4 kernel. Thanks, Bruno > > Thanks, > Costin > > On 25 Jan 2011, at 11:48, Bruno Mongazon-Cazavet wrote: > >> Dear all, >> >> Could you elaborate on the behaviour of MPTCP when the paths have significant bit rate differences, such as PPP on WCDMA and WiFi ? >> >> From my personal experimentation, i have in short: >> >> WCDMA path only => 700 Kbits/s >> WiFi path only => 21 Mbits/s >> WCMDA+WiFi paths => 15 Mbits/s >> >> The traffic kind is of Uplink nature. >> >> My feeling is that the balancing algorithm is not suited to such bit rates differences. >> Because the paths are unequal, passing data on the slowest path necessary slows the fastest path. >> Although difference in bit rates matter, the same would be expected with differences in RTT. >> >> Thanks for your answers. >> Bruno >> >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > From mark.j.handley@gmail.com Tue Jan 25 02:17:19 2011 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 072CC3A6A87 for ; Tue, 25 Jan 2011 02:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_54=0.6, 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 ZFE1MPQEIiMq for ; Tue, 25 Jan 2011 02:17:18 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 15C693A6990 for ; Tue, 25 Jan 2011 02:17:17 -0800 (PST) Received: by ewy8 with SMTP id 8so2614777ewy.31 for ; Tue, 25 Jan 2011 02:20:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=jTYAuR+jr3Lor8oQXqtXLXFyaeYkGcZ3IkOxW0XdYuE=; b=LwQbqPLdJXICMJKjKuYvlen7Xes22zE+3JjFK2vtsnlCNYBxv17HlgYsPAxL1GNWqZ f2i9j/z+gCUZCXsKITlR5kfpsfZNlBpEt4jVbB8OE3hglHNEcConk0/0VQhRbCEm1DC4 3wVbojmz/ysUuUwiYN0wkqdReolSDfmwumbN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=GSeNMTRKmINzaVNdjMuAlbw9xfaZLElxkfaMrS8zqg6odWrPBY2DzsDDsOTbddoOPo 8z4RiKSFVzO8sLnrbkagBfxX+RPqHtOEG7xbFso28GGQiO2PY8MiypfQztobB2d4WR5J QM2tABlCYV123M4Xs3fpsH/M2M2sZniTZyhiE= Received: by 10.216.35.83 with SMTP id t61mr3542845wea.1.1295950814297; Tue, 25 Jan 2011 02:20:14 -0800 (PST) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.216.241.201 with HTTP; Tue, 25 Jan 2011 02:19:54 -0800 (PST) In-Reply-To: <4D3E9C6D.8080009@alcatel-lucent.com> References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3E9C6D.8080009@alcatel-lucent.com> From: Mark Handley Date: Tue, 25 Jan 2011 10:19:54 +0000 X-Google-Sender-Auth: 0BlkQJUdg8_BcaEKgUYoZpZ6vmY Message-ID: To: Bruno Mongazon-Cazavet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 10:17:19 -0000 On 25 January 2011 09:48, Bruno Mongazon-Cazavet wrote: > =A0Dear all, > > Could you elaborate on the behaviour of MPTCP when the paths have > significant bit rate differences, such as PPP on WCDMA and WiFi ? > > From my personal experimentation, i have in short: > > WCDMA path only =3D> 700 Kbits/s > WiFi path only =3D> 21 Mbits/s > WCMDA+WiFi paths =3D> 15 Mbits/s > > The traffic kind is of Uplink nature. Can you elaborate on your experiment setup? One possible cause would be too little socket buffer space, at either the sender or receiver. If the receive window fills because you're waiting for a packet on the long RTT WCDMA path, then you'd miss sending opportunities on the WiFi path. If this is the problem, there are two solutions: - add more buffering at the sender and/or receiver. - detect the condition, and switch to the WiFi-only path when it occurs. Cheers, Mark From bruno.mongazon-cazavet@alcatel-lucent.com Tue Jan 25 02:19:27 2011 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 E3EB83A6834 for ; Tue, 25 Jan 2011 02:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.007 X-Spam-Level: X-Spam-Status: No, score=-6.007 tagged_above=-999 required=5 tests=[AWL=0.242, 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 WifOb7UWE0o4 for ; Tue, 25 Jan 2011 02:19:27 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id D7C223A6827 for ; Tue, 25 Jan 2011 02:19:26 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0PALug4012524 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2011 11:22:21 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Jan 2011 11:22:10 +0100 Message-ID: <4D3EA452.7010602@alcatel-lucent.com> Date: Tue, 25 Jan 2011 11:22:10 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Olivier.Bonaventure@uclouvain.be" References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3EA01B.4010707@alcatel-lucent.com> <4D3EA188.3020807@uclouvain.be> In-Reply-To: <4D3EA188.3020807@uclouvain.be> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Path addition time 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 Jan 2011 10:19:28 -0000 Le 25/01/2011 11:10, Olivier Bonaventure a écrit : > Bruno, >> Could you elaborate on the path addition time of MPTCP ? >> >> >> What i call "path addition time" is the elapsed time between arrival of >> TCP SYN-ACK on the main path and arrival of TCP SYN-ACK on the alternate >> path (understanding for the same MPTCP connection). >> >> What i see from my personal experimentation is that the TCP SYN on the >> alternate path fails and needs retransmission. This leads to an almost 3 >> seconds "path addition time". Why does the TCP SYN fails ? My current >> explanation is that there is already a high traffic load on the main >> path (upload kind). > Could you elaborate a bit on the experimental setup that you used ? Linux 2.6.28 vanilla + MPTCP 0.4 kernel patch. The MPTCP system is using a HSPA dongle (up to 7 Mbits download) and a 54Mbits WiFi integrated. Both 3G and WiFi are connected to a common IP core. End systems are either internet or intranet. I use ttcp to test upload traffic. Bruno. > > > Olivier From mark.j.handley@gmail.com Tue Jan 25 02:20:13 2011 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 5D35D3A6A87 for ; Tue, 25 Jan 2011 02:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 E3GidQq0iduS for ; Tue, 25 Jan 2011 02:20:12 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id B7E133A6827 for ; Tue, 25 Jan 2011 02:20:11 -0800 (PST) Received: by eyd10 with SMTP id 10so2627016eyd.31 for ; Tue, 25 Jan 2011 02:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=LwBjhnkFI4dnBTabASctSoIApSmeRHZR1wuqO4D9Pcg=; b=PR7847qbCCPz60VfAylZey6ILQXpZH2HETt0ee9rmSyXtiX17LoR+YH4AXIs020f4Y a8jnsYSK0onKcj0obTJhwzmUaW2Q+fmq0vUWk+nczwcCikzZXVYGX9Eo6dDyX3r20oxk ms9Cj5v3XoRwH+ZapyamzXf6C9bP2/62wCXtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=B44SVO/qyP2Edw9tF/NqP3OTpImJBr8+D9xNjSwh3VZSVL226OetDkUhaqLpMPVjaV MCzVZaarl00GcnYopS+oUgT4EoiJbnpueAOb/EOI3yhnlkrK9f8p0mUotqFReYOa4ll4 vBp/unvvWGDme/S8jCSthhoxUuEpOXMmKFJUA= Received: by 10.216.28.19 with SMTP id f19mr4537965wea.88.1295950988314; Tue, 25 Jan 2011 02:23:08 -0800 (PST) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.216.241.201 with HTTP; Tue, 25 Jan 2011 02:22:48 -0800 (PST) In-Reply-To: <4D3EA393.5040500@alcatel-lucent.com> References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3E9C6D.8080009@alcatel-lucent.com> <4D3EA393.5040500@alcatel-lucent.com> From: Mark Handley Date: Tue, 25 Jan 2011 10:22:48 +0000 X-Google-Sender-Auth: ZQWpz7mnmL1H8a-hElT2FwjnftI Message-ID: To: Bruno Mongazon-Cazavet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 10:20:13 -0000 On 25 January 2011 10:18, Bruno Mongazon-Cazavet wrote: >> =A0What implementation are you using? > > Linux 2.6.28 vanilla + MPTCP 0.4 kernel. If I recall correctly, MPTCP 0.4 doesn't include the linked congestion control mechanism. So the results aren't really indicative of what you should be able to receive. - Mark From christoph.paasch@uclouvain.be Tue Jan 25 02:31:56 2011 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 DA9873A6A59 for ; Tue, 25 Jan 2011 02:31:56 -0800 (PST) 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 4BLGAwGvt-43 for ; Tue, 25 Jan 2011 02:31:56 -0800 (PST) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id A9CC83A6827 for ; Tue, 25 Jan 2011 02:31:55 -0800 (PST) Received: from cpaasch-mac.localnet (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B455AECA41; Tue, 25 Jan 2011 11:34:31 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp2.sgsi.ucl.ac.be B455AECA41 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1295951671; bh=A+PoMMrGW29pbEgBtJZRhXAxDDGZduteWbHP4oBaEEg=; h=From:Reply-To:To:Subject:Date:Cc:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id; b=CEkJBDwQaQPWdEIkG9zA45zsTFr52NiVjCmYEx1ZVhbAa0PHjHl1weNou0aRI0hgS Pslpyl++Ejl1SJHXQ7vnYL6osMM4obwPFB6WfitHy7j4JivmXJxe19SgifapOILnXO yNMmYcaD5rDUQwkF9EIqQjyWt00GrbhVWpOGcmDc= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: multipathtcp@ietf.org Date: Tue, 25 Jan 2011 11:34:30 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.5.5; x86_64; ; ) References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <4D3EA188.3020807@uclouvain.be> <4D3EA452.7010602@alcatel-lucent.com> In-Reply-To: <4D3EA452.7010602@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201101251134.30934.christoph.paasch@uclouvain.be> X-Virus-Scanned: clamav-milter 0.96.5-exp at smtp-2.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: B455AECA41.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "Olivier.Bonaventure@uclouvain.be" Subject: Re: [multipathtcp] Path addition time X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 10:31:57 -0000 Hello, On Tuesday, January 25, 2011 wrote Bruno Mongazon-Cazavet: > > Could you elaborate a bit on the experimental setup that you used ? >=20 > Linux 2.6.28 vanilla + MPTCP 0.4 kernel patch. > The MPTCP system is using a HSPA dongle (up to 7 Mbits download) and a > 54Mbits WiFi integrated. > Both 3G and WiFi are connected to a common IP core. End systems are > either internet or intranet. Could you try out the recent 0.5 kernel patch? I just did a quick check, and the SYNs that come in are processed directly. Is your first SYN really arriving at the box, or may it be dropped on it's= =20 path? If you believe it's a bug in the implementation, may you move the discussio= n=20 to the mptcp-developpers mailing-list?=20 (https://listes-2.sipr.ucl.ac.be/sympa/info/mptcp-dev) Cheers, Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From christoph.paasch@uclouvain.be Tue Jan 25 02:35:03 2011 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 8ACF83A6834 for ; Tue, 25 Jan 2011 02:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, GB_LOOKATOURSITE=2, 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 gv7MV4yFtCMq for ; Tue, 25 Jan 2011 02:35:02 -0800 (PST) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 67A4A3A6A74 for ; Tue, 25 Jan 2011 02:35:02 -0800 (PST) Received: from cpaasch-mac.localnet (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 0CDEE1C617D; Tue, 25 Jan 2011 11:37:30 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp3.sgsi.ucl.ac.be 0CDEE1C617D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1295951850; bh=zsn/P08RNavxcoAk7p3/wXvYVesPdQJnit3XkPVzA3k=; h=From:Reply-To:To:Subject:Date:Cc:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id; b=RumxxWAiJ31L2/hoOBnOJOjzhEmi81M3bUstmLRGs8a1OJsgaaFHw1IR4MBgK7oCR lk47yECEBpQAD5lQu+QeDdumis6sn3K0bdyUWVpofUasozmb6TotsQzAB4r0kd1xo3 M587jhuMs7T+fV859fGqG0C+qlfh2anGYR7PhoYU= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: multipathtcp@ietf.org Date: Tue, 25 Jan 2011 11:37:29 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.5.5; x86_64; ; ) References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <4D3EA01B.4010707@alcatel-lucent.com> <4D3EA287.5060401@alcatel-lucent.com> In-Reply-To: <4D3EA287.5060401@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201101251137.29255.christoph.paasch@uclouvain.be> X-Virus-Scanned: clamav-milter 0.96.5-exp at smtp-3.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 0CDEE1C617D.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [multipathtcp] Weight usage of source routing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 10:35:03 -0000 On Tuesday, January 25, 2011 wrote Bruno Mongazon-Cazavet: > Dear All, >=20 > Could you elaborate on the possible relationship between MPTCP paths and > weights assigned to paths in IP source routing ? We do not consider the weights associated to a path in the subflow-selectio= n. Due to the coupled congestion control (since version 0.5), we automatically= =20 switch traffic away from congestioned paths. > The question is: > Is there a relationship ? > Or does MPTCP requires a convenient setting of IP source routing > regarding weight ? You need to configure policy-routing. Have a look at our website: https://scm.info.ucl.ac.be/trac/mptcp/wiki/install - Configure routing rules Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From olivier.bonaventure@uclouvain.be Tue Jan 25 02:45:29 2011 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 A7CC03A6B8E for ; Tue, 25 Jan 2011 02:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 uqaM2nKCGJS2 for ; Tue, 25 Jan 2011 02:45:28 -0800 (PST) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 87F0F3A6A74 for ; Tue, 25 Jan 2011 02:45:28 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 68E09ECBB5; Tue, 25 Jan 2011 11:47:16 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp2.sgsi.ucl.ac.be 68E09ECBB5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1295952436; bh=h+r2pN6/T7CU23emjFQ7jyq/FdyKNghh1HTzNDbH5X8=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=jkAbwZTb9CE3pdA2CwzWbBuSboaer3wTk3Am3v0H2ckv/Sa4U2xfvl1KEBf3A4gwN tt1F6HZWTxcksLJ0MgUG8eRzXmdK2AKO0gpc9wAQtTraohPNNjCkvgn04qEYVYzCiT mDNup49CMhE2Q9xZY7XtG0zIFVoQrit+CqyxQ9HY= Message-ID: <4D3EAA33.8000602@uclouvain.be> Date: Tue, 25 Jan 2011 11:47:15 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Handley References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3E9C6D.8080009@alcatel-lucent.com> <4D3EA393.5040500@alcatel-lucent.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5-exp at smtp-2.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 68E09ECBB5.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 10:45:29 -0000 On 25/01/11 11:22, Mark Handley wrote: > On 25 January 2011 10:18, Bruno Mongazon-Cazavet > wrote: >>> What implementation are you using? >> >> Linux 2.6.28 vanilla + MPTCP 0.4 kernel. > > If I recall correctly, MPTCP 0.4 doesn't include the linked congestion > control mechanism. So the results aren't really indicative of what > you should be able to receive. Exact, you should upgrade to MTCP 0.5. MPTCP 0.4 uses Reno by default while 0.5 includes the coupled congestion control Olivier From christoph.paasch@uclouvain.be Tue Jan 25 02:47:20 2011 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 BA81A3A6A59 for ; Tue, 25 Jan 2011 02:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 8mtcmqZajj67 for ; Tue, 25 Jan 2011 02:47:19 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 7260E28B56A for ; Tue, 25 Jan 2011 02:47:19 -0800 (PST) Received: from cpaasch-mac.localnet (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 677F9F2949; Tue, 25 Jan 2011 11:48:48 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be 677F9F2949 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1295952528; bh=WTSLmLaQ/4QiKfsIOGb6qR/TkL42MxuAB82j8mSY+6k=; h=From:Reply-To:To:Subject:Date:Cc:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id; b=xH4G9PjYn1J5lIXiSqnXdXzm0Igv7arhngveSJ5MWQEfUe5sux9Zwn8KmR4vtNUdf y7aiEQv6KJGoRm7no8dbxN+WVi7gVE9oNiQT/gU6yWI3H2n+FvWHUTgFkVLoUZgZkA gBJxyODBH8SLSzjE4GCi7+f3pANimSsy10pa9CJI= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: multipathtcp@ietf.org Date: Tue, 25 Jan 2011 11:48:47 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.5.5; x86_64; ; ) References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <4D3EA393.5040500@alcatel-lucent.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201101251148.47628.christoph.paasch@uclouvain.be> X-Virus-Scanned: clamav-milter 0.96.5-exp at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 677F9F2949.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [multipathtcp] =?iso-8859-1?q?Multiple_paths_with_significant_bit?= =?iso-8859-1?q?_rate=09differences?= X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 10:47:20 -0000 Hello, On Tuesday, January 25, 2011 wrote Mark Handley: > If I recall correctly, MPTCP 0.4 doesn't include the linked congestion > control mechanism. So the results aren't really indicative of what > you should be able to receive. Right, the 0.4 release doesn't include the ccc. However, as it does not include it, the subflows have regular congestion=20 control installed (reno, cubic,... or whatever has been configured), and th= us=20 are generally more agressive than with ccc. What may slow down is the difference in the rtt of the different paths,=20 because we then have a huge reordering-overhead and thus the receive-buffer= =20 will fill up. Try to increase your maximum receive-buffer size to handle th= is=20 case (as Mark already mentioned). What are your rtt's of the different paths? Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From sebastien.barre@uclouvain.be Tue Jan 25 02:47:49 2011 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 720193A6830 for ; Tue, 25 Jan 2011 02:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, 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 ExSNStng1x+W for ; Tue, 25 Jan 2011 02:47:48 -0800 (PST) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 408683A6823 for ; Tue, 25 Jan 2011 02:47:48 -0800 (PST) Received: from [130.104.228.80] (marguerite.dhcp.info.ucl.ac.be [130.104.228.80]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sbarre@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id CFCDB1C6083; Tue, 25 Jan 2011 11:50:34 +0100 (CET) Message-ID: <4D3EAAFA.1030705@uclouvain.be> Date: Tue, 25 Jan 2011 11:50:34 +0100 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nl; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruno Mongazon-Cazavet References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3E9C6D.8080009@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5-exp at smtp-3.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=130.104.228.80; helo= Received-SPF: Pass (sender authenticated); receiver=; client-ip=130.104.228.80; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: CFCDB1C6083.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: sebastien.barre@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp , mptcp-dev Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 10:47:49 -0000 Hi Bruno, (cc'ing mptcp-dev) Just a small note: a simple test with MPTCP v0.4/5 to check if the receive buffer is responsible for this (which is what I would think as well) is to increase the linux max allowed receive buffer, that way: echo "4096 87380 8388608" > /proc/sys/net/ipv4/tcp_rmem then retry the experiment. In the above line, the important number is the third one, which I have set here to twice the default value. That third value is the max allowed received buffer. MPTCP will automatically tune its receive buffer, taking into account delay differences (bw differences should not change anything) *up to* the configured max receive buffer. Hope that will solve the problem, Sébastien. Op 25-01-11 11:19, Mark Handley schreef: > On 25 January 2011 09:48, Bruno Mongazon-Cazavet > wrote: >> Dear all, >> >> Could you elaborate on the behaviour of MPTCP when the paths have >> significant bit rate differences, such as PPP on WCDMA and WiFi ? >> >> From my personal experimentation, i have in short: >> >> WCDMA path only => 700 Kbits/s >> WiFi path only => 21 Mbits/s >> WCMDA+WiFi paths => 15 Mbits/s >> >> The traffic kind is of Uplink nature. > Can you elaborate on your experiment setup? One possible cause would > be too little socket buffer space, at either the sender or receiver. > If the receive window fills because you're waiting for a packet on the > long RTT WCDMA path, then you'd miss sending opportunities on the WiFi > path. > > If this is the problem, there are two solutions: > > - add more buffering at the sender and/or receiver. > - detect the condition, and switch to the WiFi-only path when it occurs. > > Cheers, > Mark > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium http://inl.info.ucl.ac.be/sbarre From bruno.mongazon-cazavet@alcatel-lucent.com Tue Jan 25 03:38:33 2011 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 19C723A6BA4 for ; Tue, 25 Jan 2011 03:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.225, 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 PQriZyd7jc+a for ; Tue, 25 Jan 2011 03:38:32 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id E31EE3A63C9 for ; Tue, 25 Jan 2011 03:38:30 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0PBfMN8019733 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2011 12:41:22 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Jan 2011 12:41:22 +0100 Message-ID: <4D3EB6DD.8040900@alcatel-lucent.com> Date: Tue, 25 Jan 2011 12:41:17 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Costin Raiciu References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3EA01B.4010707@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: multipathtcp Subject: Re: [multipathtcp] Path addition time 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 Jan 2011 11:38:33 -0000 Le 25/01/2011 11:11, Costin Raiciu a écrit : > Hi, > > > From your emails, it seems you are using the userland mptcp implementation - that one used to lose the first packet on the subsequent subflows. That is just an implementation quirk (some weird interaction between libpcap and raw sockets), and has nothing to do with MPTCP. > By the way, people from UCL Belgium and Aalto university have been bug fixing the Linux kernel implementation of MPTCP; as far as I know this now runs the coupled congestion controller. Please use that for further tests; the underlying stack is much more robust than the one used by the userland stack, which is an old 2.3.xx stack. No i use kernel patch MPTCP 0.4. Going to switch to 0.5 soon ;-) With Linux 2.6.28 vanilla. > As for the path addition time, MPTCP waits for the first subflow to be established before it opens the additional ones. After the initial flow is setup, all additional subflows can be opened simultaneously, and will be as fast to open as regular TCP connections. What would you like to optimize exactly? Just understanding, not optimizing ;-) Bruno. > Cheers, > Costin > > On 25 Jan 2011, at 12:04, Bruno Mongazon-Cazavet wrote: > >> Dear All, >> >> Could you elaborate on the path addition time of MPTCP ? >> >> >> What i call "path addition time" is the elapsed time between arrival of TCP SYN-ACK on the main path and arrival of TCP SYN-ACK on the alternate path (understanding for the same MPTCP connection). >> >> What i see from my personal experimentation is that the TCP SYN on the alternate path fails and needs retransmission. This leads to an almost 3 seconds "path addition time". Why does the TCP SYN fails ? My current explanation is that there is already a high traffic load on the main path (upload kind). >> >> Although this might be "experimentation" specific, i guess there might be a design problem, in the sense that MPTCP relies on regular TCP SYN behavior to make an alternate path ready. This is critical if MPTCP is used for handoff purposes. >> >> Thanks for your answers. >> Bruno >> >> >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > From bruno.mongazon-cazavet@alcatel-lucent.com Tue Jan 25 04:37:48 2011 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 5028F28C0E7 for ; Tue, 25 Jan 2011 04:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.039 X-Spam-Level: X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=0.210, 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 xQLW7vePeTNs for ; Tue, 25 Jan 2011 04:37:47 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id ECFE228C0E9 for ; Tue, 25 Jan 2011 04:37:46 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0PCecoR006419 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2011 13:40:38 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Jan 2011 13:40:38 +0100 Message-ID: <4D3EC4C6.1030102@alcatel-lucent.com> Date: Tue, 25 Jan 2011 13:40:38 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "christoph.paasch@uclouvain.be" References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <4D3EA393.5040500@alcatel-lucent.com> <201101251148.47628.christoph.paasch@uclouvain.be> In-Reply-To: <201101251148.47628.christoph.paasch@uclouvain.be> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 12:37:48 -0000 Le 25/01/2011 11:48, Christoph Paasch a écrit : > Hello, > > On Tuesday, January 25, 2011 wrote Mark Handley: >> If I recall correctly, MPTCP 0.4 doesn't include the linked congestion >> control mechanism. So the results aren't really indicative of what >> you should be able to receive. > Right, the 0.4 release doesn't include the ccc. > However, as it does not include it, the subflows have regular congestion > control installed (reno, cubic,... or whatever has been configured), and thus > are generally more agressive than with ccc. > > What may slow down is the difference in the rtt of the different paths, > because we then have a huge reordering-overhead and thus the receive-buffer > will fill up. Try to increase your maximum receive-buffer size to handle this > case (as Mark already mentioned). > > What are your rtt's of the different paths? Yes that's what i mentioned in my previous emails. Bit rates differ and RTT's also. wcdma => 40ms (best) wifi => 5ms (best) Agree with your explanation. So the question is how does MPTCP handles such differences (in 0.5) ? Thanks Bruno. > Christoph > > -- > Christoph Paasch > PhD Student > > IP Networking Lab --- http://inl.info.ucl.ac.be > MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp > Université Catholique de Louvain > > www.rollerbulls.be > -- > From bruno.mongazon-cazavet@alcatel-lucent.com Tue Jan 25 04:42:18 2011 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 EF9D828C0E7 for ; Tue, 25 Jan 2011 04:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.602 X-Spam-Level: X-Spam-Status: No, score=-5.602 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, 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 3lCdzRhgDw0u for ; Tue, 25 Jan 2011 04:42:16 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 85AB43A6858 for ; Tue, 25 Jan 2011 04:42:15 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0PCieas012605 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2011 13:45:07 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Jan 2011 13:45:02 +0100 Message-ID: <4D3EC5CE.4060407@alcatel-lucent.com> Date: Tue, 25 Jan 2011 13:45:02 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3E9C6D.8080009@alcatel-lucent.com> <4D3EAAFA.1030705@uclouvain.be> In-Reply-To: <4D3EAAFA.1030705@uclouvain.be> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: multipathtcp , mptcp-dev Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 12:42:18 -0000 Le 25/01/2011 11:50, Sébastien Barré a écrit : > Hi Bruno, > > (cc'ing mptcp-dev) > > Just a small note: a simple test with MPTCP v0.4/5 to check if the > receive buffer is responsible for this (which is what I would think as > well) is to increase the linux max allowed receive buffer, that way: > echo "4096 87380 8388608"> /proc/sys/net/ipv4/tcp_rmem > > then retry the experiment. In the above line, the important number is > the third one, which I have set here to twice the default value. That > third value is the max allowed received buffer. MPTCP will automatically > tune its receive buffer, taking into account delay differences (bw > differences should not change anything) *up to* the configured max > receive buffer. OK i will do that in the near future. One question related to this: Does this increase also increase the buffer loss in case of handoff with MPTCP (one the path is dropped) ? Bruno. > Hope that will solve the problem, > > Sébastien. > > Op 25-01-11 11:19, Mark Handley schreef: >> On 25 January 2011 09:48, Bruno Mongazon-Cazavet >> wrote: >>> Dear all, >>> >>> Could you elaborate on the behaviour of MPTCP when the paths have >>> significant bit rate differences, such as PPP on WCDMA and WiFi ? >>> >>> From my personal experimentation, i have in short: >>> >>> WCDMA path only => 700 Kbits/s >>> WiFi path only => 21 Mbits/s >>> WCMDA+WiFi paths => 15 Mbits/s >>> >>> The traffic kind is of Uplink nature. >> Can you elaborate on your experiment setup? One possible cause would >> be too little socket buffer space, at either the sender or receiver. >> If the receive window fills because you're waiting for a packet on the >> long RTT WCDMA path, then you'd miss sending opportunities on the WiFi >> path. >> >> If this is the problem, there are two solutions: >> >> - add more buffering at the sender and/or receiver. >> - detect the condition, and switch to the WiFi-only path when it occurs. >> >> Cheers, >> Mark >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp From christoph.paasch@uclouvain.be Tue Jan 25 04:56:31 2011 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 45C613A6872 for ; Tue, 25 Jan 2011 04:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 c8zQagfy9uBS for ; Tue, 25 Jan 2011 04:56:29 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id C147E3A6864 for ; Tue, 25 Jan 2011 04:56:27 -0800 (PST) Received: from cpaasch-mac.localnet (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 63392F293F; Tue, 25 Jan 2011 13:58:28 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be 63392F293F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1295960308; bh=9UfmhaRkki6b0Jy03MqZyq8gFG3pxOcFT/06JB+Qf8c=; h=From:Reply-To:To:Subject:Date:Cc:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id; b=fhhczH0ighmS4OZaqtzSLbpp1mFfeqNNh69Ru5dxcOaZJt5V9x3oPotqeWsmh78u3 CakMcFzozv1o7+VfWVKD3Xn0agUAKyiKmoGIR90YaxwFCmgyCFVIF4HEaCBe3pbMjv +cjr2pZDVkdBiD+9/k75Fz1SlDSxJpujWBIkN2qM= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: "Bruno Mongazon-Cazavet" Date: Tue, 25 Jan 2011 13:58:27 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.5.5; x86_64; ; ) References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <201101251148.47628.christoph.paasch@uclouvain.be> <4D3EC4C6.1030102@alcatel-lucent.com> In-Reply-To: <4D3EC4C6.1030102@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201101251358.27259.christoph.paasch@uclouvain.be> X-Virus-Scanned: clamav-milter 0.96.5-exp at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 63392F293F.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 12:56:31 -0000 On Tuesday, January 25, 2011 wrote Bruno Mongazon-Cazavet: > Yes that's what i mentioned in my previous emails. >=20 > Bit rates differ and RTT's also. > wcdma =3D> 40ms (best) > wifi =3D> 5ms (best) Oh... Well, this is really really fast for wcdma (and even for wifi). Are you sure that these are the rtt's experienced during your experimentati= on?=20 Congestion in routers increases the rtt due to buffers filling up. > Agree with your explanation. > So the question is how does MPTCP handles such differences (in 0.5) ? In 0.5 the reordering-issue is still present. But increasing your receive- buffer should improve the performance (as s=E9bastien said). The new feature of 0.5 is the Coupled Congestion Control, which handles the= =20 increase of the congestion windows of the individual subflows. It tries to= =20 slower increase the congestion windows of those paths that experience=20 congestion. Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From bruno.mongazon-cazavet@alcatel-lucent.com Tue Jan 25 05:10:36 2011 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 E23A83A6BBA for ; Tue, 25 Jan 2011 05:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=0.212, 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 fLMsqn1aXMch for ; Tue, 25 Jan 2011 05:10:35 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 8A5CA3A69E2 for ; Tue, 25 Jan 2011 05:10:34 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0PDAW8h028614 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2011 14:13:26 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Jan 2011 14:12:36 +0100 Message-ID: <4D3ECC44.1010603@alcatel-lucent.com> Date: Tue, 25 Jan 2011 14:12:36 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "christoph.paasch@uclouvain.be" References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <201101251148.47628.christoph.paasch@uclouvain.be> <4D3EC4C6.1030102@alcatel-lucent.com> <201101251358.27259.christoph.paasch@uclouvain.be> In-Reply-To: <201101251358.27259.christoph.paasch@uclouvain.be> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 13:10:37 -0000 Le 25/01/2011 13:58, Christoph Paasch a écrit : > On Tuesday, January 25, 2011 wrote Bruno Mongazon-Cazavet: >> Yes that's what i mentioned in my previous emails. >> >> Bit rates differ and RTT's also. >> wcdma => 40ms (best) >> wifi => 5ms (best) > Oh... Well, this is really really fast for wcdma (and even for wifi). > Are you sure that these are the rtt's experienced during your experimentation? > Congestion in routers increases the rtt due to buffers filling up. Yes good numbers, ranges are: wcdma => 40ms to 200ms wifi => 5ms to 10ms Yes i am almost confident with the numbers. The networks (3G+WiFi) are ours and there are few routers in between. There is no congestion in routing. End-systems are not on the Internet. >> Agree with your explanation. >> So the question is how does MPTCP handles such differences (in 0.5) ? > In 0.5 the reordering-issue is still present. But increasing your receive- > buffer should improve the performance (as sébastien said). So does this also increase the data loss in case of abrupt handoff (one path dropped) ? > The new feature of 0.5 is the Coupled Congestion Control, which handles the > increase of the congestion windows of the individual subflows. It tries to > slower increase the congestion windows of those paths that experience > congestion. I need to try it then. Thanks, Bruno > Christoph > > -- > Christoph Paasch > PhD Student > > IP Networking Lab --- http://inl.info.ucl.ac.be > MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp > Université Catholique de Louvain > > www.rollerbulls.be > -- > From c.raiciu@cs.ucl.ac.uk Tue Jan 25 05:15:00 2011 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 197423A69E2 for ; Tue, 25 Jan 2011 05:15:00 -0800 (PST) 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 bPETik7n+wAj for ; Tue, 25 Jan 2011 05:14:59 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 41CA13A686D for ; Tue, 25 Jan 2011 05:14:59 -0800 (PST) Received: from [141.85.37.210] (helo=[192.168.1.66]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1PhiTn-000AR7-Bu; Tue, 25 Jan 2011 12:58:39 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: <4D3ECC44.1010603@alcatel-lucent.com> Date: Tue, 25 Jan 2011 15:17:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <201101251148.47628.christoph.paasch@uclouvain.be> <4D3EC4C6.1030102@alcatel-lucent.com> <201101251358.27259.christoph.paasch@uclouvain.be> <4D3ECC44.1010603@alcatel-lucent.com> To: Bruno Mongazon-Cazavet X-Mailer: Apple Mail (2.1081) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 13:15:00 -0000 >=20 > So does this also increase the data loss in case of abrupt handoff = (one path dropped) ? >=20 No. This only allows the receiver to buffer more data, waiting for out = of order segments. When a path is dropped, there is an undelivered window (cwnd) of data. = On the first timeout, this window will be moved to the connection level = retransmit queue, and will be sent as soon as the other subflows have = space for it. Costin From mark.j.handley@gmail.com Tue Jan 25 05:52:57 2011 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 D59B028C0D7 for ; Tue, 25 Jan 2011 05:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, 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 hzBlh3aHHRwI for ; Tue, 25 Jan 2011 05:52:56 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 8D5793A6BBF for ; Tue, 25 Jan 2011 05:52:56 -0800 (PST) Received: by wyf23 with SMTP id 23so5743530wyf.31 for ; Tue, 25 Jan 2011 05:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=LhMOgCKzJk5jDwLjBCeW0cX3BK9KKSJN5Ia0ggjLI/g=; b=Sfvqb2x9A91NDg3Qtgk2YX8PPz719MQCgqMhbDiGabFrJAKPjedfKlSYaHgFlGmtGj dndjRz6MHQ0z413bvlJkzTLLFSssvPlzrtbG4IHr7SWMHecznWMJizfEWGhBucXYoZdE VnQUNwnF5UUbMV0DJbNg3ZFMxeYdXrUdwO5QM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=THi8f2hq/BlWAQWv5MxbwGYchlZFi6PwDxzAmG0T/BUrg7U2eds4dY6Lh5qgBS7FBe a27Iz3Wt0X9x7dUY13tLg8yqmlQ2Wfe6rSXyTiztKImaDVkhZgVsm0Z3dEaZ+UkJiyZx NRKEReoOKlELhFOrVCRpWCQQs1vHxzYbNU584= Received: by 10.216.160.129 with SMTP id u1mr3700425wek.88.1295963751903; Tue, 25 Jan 2011 05:55:51 -0800 (PST) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.216.241.201 with HTTP; Tue, 25 Jan 2011 05:55:21 -0800 (PST) In-Reply-To: <4D3EAAFA.1030705@uclouvain.be> References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3E9C6D.8080009@alcatel-lucent.com> <4D3EAAFA.1030705@uclouvain.be> From: Mark Handley Date: Tue, 25 Jan 2011 13:55:21 +0000 X-Google-Sender-Auth: Ah4gi91obpVSDjLiIUkh-WyMo7k Message-ID: To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp , mptcp-dev Subject: Re: [multipathtcp] Multiple paths with significant bit rate differences 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 Jan 2011 13:52:57 -0000 Seb, With your MPTCP code, do you also need to increase the sender-side buffering? With regular TCP, you can't use a large receive buffer unless you'd got the same size send buffer (because you need to buffer all unacked data at the sender). I'd imagine this is the same with your MPTCP implementation. - Mark 2011/1/25 S=E9bastien Barr=E9 : > Hi Bruno, > > (cc'ing mptcp-dev) > > Just a small note: a simple test with MPTCP v0.4/5 to check if the receiv= e > buffer is responsible for this (which is what I would think as well) is t= o > increase the linux max allowed receive buffer, that way: > echo "4096 87380 8388608" > /proc/sys/net/ipv4/tcp_rmem > > then retry the experiment. In the above line, the important number is the > third one, which I have set here to twice the default value. That third > value is the max allowed received buffer. MPTCP will automatically tune i= ts > receive buffer, taking into account delay differences (bw differences sho= uld > not change anything) *up to* the configured max receive buffer. > > Hope that will solve the problem, > > S=E9bastien. > > Op 25-01-11 11:19, Mark Handley schreef: >> >> On 25 January 2011 09:48, Bruno Mongazon-Cazavet >> =A0wrote: >>> >>> =A0Dear all, >>> >>> Could you elaborate on the behaviour of MPTCP when the paths have >>> significant bit rate differences, such as PPP on WCDMA and WiFi ? >>> >>> =A0From my personal experimentation, i have in short: >>> >>> WCDMA path only =3D> =A0700 Kbits/s >>> WiFi path only =3D> =A021 Mbits/s >>> WCMDA+WiFi paths =3D> =A015 Mbits/s >>> >>> The traffic kind is of Uplink nature. >> >> Can you elaborate on your experiment setup? =A0One possible cause would >> be too little socket buffer space, at either the sender or receiver. >> If the receive window fills because you're waiting for a packet on the >> long RTT WCDMA path, then you'd miss sending opportunities on the WiFi >> path. >> >> If this is the problem, there are two solutions: >> >> =A0- add more buffering at the sender and/or receiver. >> =A0- detect the condition, and switch to the WiFi-only path when it occu= rs. >> >> Cheers, >> Mark >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > > -- > S=E9bastien Barr=E9 > Researcher, > CSE department, UCLouvain, Belgium > http://inl.info.ucl.ac.be/sbarre > > From mark.j.handley@gmail.com Tue Jan 25 05:57:36 2011 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 8F7163A6872 for ; Tue, 25 Jan 2011 05:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 oMw3mhDApIEb for ; Tue, 25 Jan 2011 05:57:35 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 90C0C3A6858 for ; Tue, 25 Jan 2011 05:57:35 -0800 (PST) Received: by wyf23 with SMTP id 23so5748085wyf.31 for ; Tue, 25 Jan 2011 06:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Fcdw29cZ705wCVKzzFIIobN6sC58Eqz55FA3/eHJ++g=; b=jLMeF9iEDthOie1ck9hsloBtrulUBiHhKupnuWHhB0VFjFWIOmkgrPVcrrDcTFBiZq 11Z7cxe/FwbLisbVCj0IPK4udHy2UJ90kRAQoKdG8TB+E/lMafCdwtOhjqCMsXHLu4wr Fr7INDy82K0EHLbNcTsbmOkP+rh1eInD+kZho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=jrR3Hl9WWny7JZ8ws3x6LMNtStSljlCGmdIDqXdKZiqYONreUOn4ODi1Bqqlu5/r3A iFeGrJtVErjoEfUnU4lN50HNozS0MmcrnUq6EyaAifwvsm+an0MHGtKEq4/8MPaWcFIW mkDSQUvTfY0gzuIrR1QMfMBJqBM3sEO+EWiGU= Received: by 10.216.35.74 with SMTP id t52mr4694536wea.103.1295964032575; Tue, 25 Jan 2011 06:00:32 -0800 (PST) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.216.241.201 with HTTP; Tue, 25 Jan 2011 06:00:12 -0800 (PST) In-Reply-To: <4D3EB6DD.8040900@alcatel-lucent.com> References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3EA01B.4010707@alcatel-lucent.com> <4D3EB6DD.8040900@alcatel-lucent.com> From: Mark Handley Date: Tue, 25 Jan 2011 14:00:12 +0000 X-Google-Sender-Auth: u7Xb1IPMdHveAg_rNl5IOlT0Bpg Message-ID: To: Bruno Mongazon-Cazavet Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp Subject: Re: [multipathtcp] Path addition time 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 Jan 2011 13:57:36 -0000 On 25 January 2011 11:41, Bruno Mongazon-Cazavet wrote: >> As for the path addition time, MPTCP waits for the first subflow to be >> established before it opens the additional ones. After the initial flow is >> setup, all additional subflows can be opened simultaneously, and will be as >> fast to open as regular TCP connections. What would you like to optimize >> exactly? > > Just understanding, not optimizing ;-) :-) I don't think anything in the existing implementations has been optimized (just achieving stability isn't trivial). I'm sure there's a lot of tuning that can be done to improve performance in the WiFi/3G case, but no-one's attempted that yet. When you find something that performs strangely, please do mail the implementers list to let them know. - Mark From sebastien.barre@uclouvain.be Tue Jan 25 06:14:56 2011 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 B04A63A68D9 for ; Tue, 25 Jan 2011 06:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, 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 twwr1vw1tE3c for ; Tue, 25 Jan 2011 06:14:55 -0800 (PST) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 462A93A6858 for ; Tue, 25 Jan 2011 06:14:55 -0800 (PST) Received: from [130.104.228.80] (marguerite.dhcp.info.ucl.ac.be [130.104.228.80]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sbarre@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 9F7E6ECBC5; Tue, 25 Jan 2011 15:17:31 +0100 (CET) Message-ID: <4D3EDB7A.2050409@uclouvain.be> Date: Tue, 25 Jan 2011 15:17:30 +0100 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nl; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Handley References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <252DF15E-AC92-45F6-A750-4418ADE64E99@ifi.uio.no> <4D3E9C6D.8080009@alcatel-lucent.com> <4D3EAAFA.1030705@uclouvain.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5-exp at smtp-2.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=130.104.228.80; helo= Received-SPF: Pass (sender authenticated); receiver=; client-ip=130.104.228.80; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 9F7E6ECBC5.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: sebastien.barre@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp , mptcp-dev Subject: Re: [multipathtcp] [mptcp-dev] Re: Multiple paths with significant bit rate differences 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 Jan 2011 14:14:56 -0000 Hi Mark, Right. Indeed there is the sending side equivalent: echo "4096 16384 8388608"> /proc/sys/net/ipv4/tcp_wmem This is normally not needed, however, because for what I remember (I have not done this yesterday, so I should recheck :-)) : *The max receive buffer is understood as a max value for the whole connection. *The max send buffer is understood as a max contribution of each subflow to the whole connection. Hence the real limit is max_sndbuf*nb_subflows They should be aligned of course in the future to have the same semantic. thanks for the remark ! regards, Sébastien. Op 25-01-11 14:55, Mark Handley schreef: > Seb, > > With your MPTCP code, do you also need to increase the sender-side > buffering? With regular TCP, you can't use a large receive buffer > unless you'd got the same size send buffer (because you need to buffer > all unacked data at the sender). I'd imagine this is the same with > your MPTCP implementation. > > - Mark > > 2011/1/25 Sébastien Barré: >> Hi Bruno, >> >> (cc'ing mptcp-dev) >> >> Just a small note: a simple test with MPTCP v0.4/5 to check if the receive >> buffer is responsible for this (which is what I would think as well) is to >> increase the linux max allowed receive buffer, that way: >> echo "4096 87380 8388608"> /proc/sys/net/ipv4/tcp_rmem >> >> then retry the experiment. In the above line, the important number is the >> third one, which I have set here to twice the default value. That third >> value is the max allowed received buffer. MPTCP will automatically tune its >> receive buffer, taking into account delay differences (bw differences should >> not change anything) *up to* the configured max receive buffer. >> >> Hope that will solve the problem, >> >> Sébastien. >> >> Op 25-01-11 11:19, Mark Handley schreef: >>> On 25 January 2011 09:48, Bruno Mongazon-Cazavet >>> wrote: >>>> Dear all, >>>> >>>> Could you elaborate on the behaviour of MPTCP when the paths have >>>> significant bit rate differences, such as PPP on WCDMA and WiFi ? >>>> >>>> From my personal experimentation, i have in short: >>>> >>>> WCDMA path only => 700 Kbits/s >>>> WiFi path only => 21 Mbits/s >>>> WCMDA+WiFi paths => 15 Mbits/s >>>> >>>> The traffic kind is of Uplink nature. >>> Can you elaborate on your experiment setup? One possible cause would >>> be too little socket buffer space, at either the sender or receiver. >>> If the receive window fills because you're waiting for a packet on the >>> long RTT WCDMA path, then you'd miss sending opportunities on the WiFi >>> path. >>> >>> If this is the problem, there are two solutions: >>> >>> - add more buffering at the sender and/or receiver. >>> - detect the condition, and switch to the WiFi-only path when it occurs. >>> >>> Cheers, >>> Mark >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >> -- >> Sébastien Barré >> Researcher, >> CSE department, UCLouvain, Belgium >> http://inl.info.ucl.ac.be/sbarre >> >> -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium http://inl.info.ucl.ac.be/sbarre From Internet-Drafts@ietf.org Wed Jan 26 07:15:02 2011 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 C36873A67FB; Wed, 26 Jan 2011 07:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBzuCyR4lbQh; Wed, 26 Jan 2011 07:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9893A67E5; Wed, 26 Jan 2011 07:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110126151502.20408.11373.idtracker@localhost> Date: Wed, 26 Jan 2011 07:15:02 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-threat-08.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 15:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses Author(s) : M. Bagnulo Filename : draft-ietf-mptcp-threat-08.txt Pages : 17 Date : 2011-01-26 Multi-path TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP protocol. This note includes a threat analysis for MPTCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-threat-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mptcp-threat-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-26071051.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Wed Jan 26 08:41:57 2011 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 5142D3A67EF; Wed, 26 Jan 2011 08:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cicQPDeT4DF; Wed, 26 Jan 2011 08:41:56 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A08F03A6889; Wed, 26 Jan 2011 08:41:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110126164155.24095.36228.idtracker@localhost> Date: Wed, 26 Jan 2011 08:41:55 -0800 Cc: mptcp mailing list , mptcp chair , Internet Architecture Board , RFC Editor Subject: [multipathtcp] Document Action: 'Architectural Guidelines for Multipath TCP Development' to Informational RFC (draft-ietf-mptcp-architecture-05.txt) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:41:57 -0000 The IESG has approved the following document: - 'Architectural Guidelines for Multipath TCP Development' (draft-ietf-mptcp-architecture-05.txt) as an Informational RFC This document is the product of the Multipath TCP Working Group. The IESG contact person is Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-architecture/ Technical Summary Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput. This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP protocol. This document lists certain high level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. Working Group Summary This is a product of the MPTCP WG. There is a consensus in the WG for publication as an informational RFC. There is a very solid WG consensus behind the document. It captures the key high-level design decisions about the MPTCP protocol, which have been reached after extensive discussion and agreement at the IETF meetings and on the list. Document Quality There is already an implementation of the protocol (draft-ietf- mptcp-multiaddressed) that implements the architecture and high-level design decisions in this document, https://scm.info.ucl.ac.be/trac/mptcp/wiki. There were five detailed reviews of versions of the document. No substantial issues were raised. Expert reviews (MIB doctor etc) were not applicable. Personnel Philip Eardley (philip.eardley@bt.com) is the Document Shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. From iesg-secretary@ietf.org Wed Jan 26 08:43:30 2011 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 C486B3A697C; Wed, 26 Jan 2011 08:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2vof5Yc9903; Wed, 26 Jan 2011 08:43:30 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E783A693B; Wed, 26 Jan 2011 08:43:29 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110126164329.25640.40206.idtracker@localhost> Date: Wed, 26 Jan 2011 08:43:29 -0800 Cc: mptcp mailing list , mptcp chair , Internet Architecture Board , RFC Editor Subject: [multipathtcp] Document Action: 'Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses' to Informational RFC (draft-ietf-mptcp-threat-08.txt) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:43:30 -0000 The IESG has approved the following document: - 'Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses' (draft-ietf-mptcp-threat-08.txt) as an Informational RFC This document is the product of the Multipath TCP Working Group. The IESG contact person is Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-threat/ Technical Summary This document describes the threat analysis for Multi-path TCP which allows an endpoint to use multiple IP addresses to exchange data. The goal of this document is to provide the information of possible threats in Multi-path TCP and recommendable solutions to make MPTCP as secure as the current TCP. The information on this document is important for the basic design of MPTCP protocol. Additional strong secure mechanisms are out-of-scope of this document and will be addressed by other documents. Working Group Summary This draft has been discussed in all IETF meetings since the creation of the WG. There is a strong consensus in the WG for publication as an informational RFC. Document Quality This document was reviewed by various people and has been through WGLC successfully. The MPTCP protocol has been designed based on the recommendations in this document. Personnel Yoshifumi Nishida (nishida@sfc.wide.ad.jp) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. From Michael.Tuexen@lurchi.franken.de Wed Jan 26 15:22:23 2011 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 7F3353A69F5 for ; Wed, 26 Jan 2011 15:22:23 -0800 (PST) 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 NaW3MoXHBIro for ; Wed, 26 Jan 2011 15:22:22 -0800 (PST) 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 313A63A68E1 for ; Wed, 26 Jan 2011 15:22:22 -0800 (PST) Received: from [192.168.1.113] (p508FD0C0.dip.t-dialin.net [80.143.208.192]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6C5581C0B4612; Thu, 27 Jan 2011 00:25:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> Date: Thu, 27 Jan 2011 00:25:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1082) Cc: multipathtcp@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [multipathtcp] Please review "Coupled Congestion Control for Multipath Transport Protocols" 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, 26 Jan 2011 23:22:23 -0000 Hi Philip, I have some questions regarding section 3: (1) It is stated: "Since we require that the total throughput is no worse than the throughput a single TCP would get on the best path..." and later: "The formula is derived by equalizing the rate of the multipath flow with the rate of a TCP running on the best path, and solving for alpha." So what is considered here: * throughput in bytes/sec * rate in packets/sec * rate in bytes/sec (2) I don't understand the formula for alpha completely. I understand = how the corresponding formula in "Practical Congestion Control for = Multipath Transport Protocol" is derived. However, there the congestion = windows are measured in MTUs (or MSS or packets). So it is more packet rate based. I could understand the formula in the ID if cwnd_i / mss_i = would be used instead of cwnd_i * mss_i. So is it a typo or could someone = provide a hint why cwnd_i * mss_i is used. Best regards Michael On Jan 19, 2011, at 3:25 PM, = wrote: > The Multipath TCP WG has developed a congestion control algorithm that = enables a TCP connection to use multiple paths. =20 > http://tools.ietf.org/html/draft-ietf-mptcp-congestion > =20 > We=92re hoping to WG Last Call this document in February, so it would = be great if anyone from ICCRG could review it > =20 > Thanks, > Phil & Yoshifumi > MPTCP WG Chairs > =20 > Abstract > =20 > Often endpoints are connected by multiple paths, but communications > are usually restricted to a single path per connection. Resource > usage within the network would be more efficient were it possible = for > these multiple paths to be used concurrently. Multipath TCP is a > proposal to achieve multipath transport in TCP. > =20 > New congestion control algorithms are needed for multipath = transport > protocols such as Multipath TCP, as single path algorithms have a > series of issues in the multipath context. One of the prominent > problems is that running existing algorithms such as TCP New Reno > independently on each path would give the multipath flow more than > its fair share at a bottleneck link traversed by more than one of = its > subflows. Further, it is desirable that a source with multiple = paths > available will transfer more traffic using the least congested of = the > paths, hence achieving resource pooling. This would increase the > overall utilization of the network and also its robustness to > failure. > =20 > This document presents a congestion control algorithm which couples > the congestion control algorithms running on different subflows by > linking their increase functions, and dynamically controls the > overall aggresiveness of the multipath flow. The result is a > practical algorithm that is fair to TCP at bottlenecks while moving > traffic away from congested links. > =20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From bob.briscoe@bt.com Mon Jan 31 09:12:03 2011 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 369213A6915 for ; Mon, 31 Jan 2011 09:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EdSMZqzbNcS for ; Mon, 31 Jan 2011 09:12:01 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 676003A67B7 for ; Mon, 31 Jan 2011 09:12:01 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 17:15:15 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 17:15:14 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1296494113724; Mon, 31 Jan 2011 17:15:13 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p0VHFCcA001378; Mon, 31 Jan 2011 17:15:12 GMT Message-Id: <201101311715.p0VHFCcA001378@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 31 Jan 2011 17:15:16 +0000 To: draft-ietf-mptcp-multiaddressed@tools.ietf.org From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 31 Jan 2011 17:15:14.0748 (UTC) FILETIME=[6CDF9FC0:01CBC16A] X-Mailman-Approved-At: Mon, 31 Jan 2011 09:13:18 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] mptcp-multiaddressed: How long before multipath starts? 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, 31 Jan 2011 17:12:03 -0000 Alan Costin, Mark, or ANOther, The large majority of TCP flows are very short. If there will only be one or two packets to send, there will be no point sending off loads of requests to open sub-flows straight after the first 3-way handshake. So I imagined there would be some advice in one of the MPTCP I-Ds on how long a MPTCP should wait until it attempts to open sub-flows. I can't find this from a quick scan. I would have expected it to be in the heuristics section of draft-ietf-mptcp-multiaddressed: In general, a TCP stack doesn't know how much data the application might eventually want to send. So I guess the basic advice might be to wait n_1 RTTs before opening a second subflow, then n_2 RTTs before opening a third and so on. Has anyone done any research on this to find the best tradeoff (ie best values of n_1, n_2, etc) between improved performance/resilience and wasting signalling packets? I imagine this heuristic would be clocked by RTTs, not real-time or bytes, because that would likely be the relevant parameter for the signalling tradeoff. Then, in the API draft, there might be some discussion on whether the application can tell the transport how much data it intends to send, so the heuristics can be less blind. Thoughts? Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From Michael.Scharf@alcatel-lucent.com Mon Jan 31 09:43:00 2011 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 C16E93A6A6F for ; Mon, 31 Jan 2011 09:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 tNiMsB42LbFR for ; Mon, 31 Jan 2011 09:43:00 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id AC50C3A6807 for ; Mon, 31 Jan 2011 09:42:59 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p0VHkBO7022308; Mon, 31 Jan 2011 18:46:11 +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: Mon, 31 Jan 2011 18:46:10 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C04E79D3E@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <201101311715.p0VHFCcA001378@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] mptcp-multiaddressed: How long before multipathstarts? Thread-Index: AcvBap6cEdgA0WIWSlCQ0wtRux8JzgAAN7BQ References: <201101311715.p0VHFCcA001378@bagheera.jungle.bt.co.uk> From: "SCHARF, Michael" To: "Bob Briscoe" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] mptcp-multiaddressed: How long before multipathstarts? 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, 31 Jan 2011 17:43:00 -0000 Bob, > Then, in the API draft, there might be some discussion on=20 > whether the application can tell the transport how much data=20 > it intends to send, so the heuristics can be less blind. >=20 > Thoughts? this information would be quite useful for the TCP stack even if it does not support Multipath TCP. For instance, I thought about exactly such an API call during my work on fast startup congestion control (Quick-Start TCP, etc.). I agree very much that this information would be highly useful, but it is not necessarily an API issue specific to Multipath TCP. The key question is whether app developers would ever be able to use such an API. The simpler alternative is to just observe in the TCP stack how much data the app actually writes and then to use this information as input to the heuristics. Concerning the API spec: draft-ietf-mptcp-api only specifies a minimum set of API functions. IMHO we could mention this possibility in the appendix as a potential feature of an advanced API. Also, note that draft-ietf-mptcp-api already recommends to app developers to avoid many small write socket calls. The reason for this statement is exactly to avoid confusing stack-internal heuristics. Michael From bob.briscoe@bt.com Mon Jan 31 10:11:59 2011 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 765113A6C36 for ; Mon, 31 Jan 2011 10:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd4kaOGfkcJW for ; Mon, 31 Jan 2011 10:11:58 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 4C5923A6C3A for ; Mon, 31 Jan 2011 10:11:58 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 18:15:11 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 18:15:11 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1296497709882; Mon, 31 Jan 2011 18:15:09 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p0VIF9NT001647; Mon, 31 Jan 2011 18:15:09 GMT Message-Id: <201101311815.p0VIF9NT001647@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 31 Jan 2011 18:15:12 +0000 To: "SCHARF, Michael" From: Bob Briscoe In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C04E79D3E@SLFSNX.rcs.alcate l-research.de> References: <201101311715.p0VHFCcA001378@bagheera.jungle.bt.co.uk> <133D9897FB9C5E4E9DF2779DC91E947C04E79D3E@SLFSNX.rcs.alcatel-research.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 31 Jan 2011 18:15:11.0362 (UTC) FILETIME=[CC9F5E20:01CBC172] Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] mptcp-multiaddressed: How long before multipathstarts? 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, 31 Jan 2011 18:11:59 -0000 Michael, At 17:46 31/01/2011, SCHARF, Michael wrote: >Bob, > > > Then, in the API draft, there might be some discussion on > > whether the application can tell the transport how much data > > it intends to send, so the heuristics can be less blind. > > > > Thoughts? > >this information would be quite useful for the TCP stack even if it does >not support Multipath TCP. For instance, I thought about exactly such an >API call during my work on fast startup congestion control (Quick-Start >TCP, etc.). I agree very much that this information would be highly >useful, but it is not necessarily an API issue specific to Multipath >TCP. > >The key question is whether app developers would ever be able to use >such an API. The obvious case would be an HTTP server that sends the size of the object in the HTTP protocol before it starts sending it. So it would not be rocket-science to tell its own stack the same information as it already tells the remote end (and the remote end could tell its stack). >The simpler alternative is to just observe in the TCP stack >how much data the app actually writes and then to use this information >as input to the heuristics. Yes. In many cases this would work well (including the Web server case above in most regular cases). However, in some cases, the app might know that it has more data than it is currently writing to the socket. >Concerning the API spec: draft-ietf-mptcp-api only specifies a minimum >set of API functions. IMHO we could mention this possibility in the >appendix as a potential feature of an advanced API. As you say, perhaps mention that transfer size might be added more generally to the API, and be useful for MPTCP as well as other purposes. >Also, note that >draft-ietf-mptcp-api already recommends to app developers to avoid many >small write socket calls. The reason for this statement is exactly to >avoid confusing stack-internal heuristics. I noticed that while searching. I think the advice might need to be written the other way round - the heuristics would need to take account of the possibility of an app developer doing many small write socket calls. My reasoning: MPTCP developers might read an MPTCP spec. But app developers won't - at least we cannot rely on it. Cheers Bob >Michael ________________________________________________________________ Bob Briscoe, BT Innovate & Design From Michael.Scharf@alcatel-lucent.com Mon Jan 31 10:45:49 2011 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 374AF3A6C37 for ; Mon, 31 Jan 2011 10:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 wVY+XEL0AQAt for ; Mon, 31 Jan 2011 10:45:48 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 0F41A3A6C21 for ; Mon, 31 Jan 2011 10:45:47 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p0VIn0ow027262; Mon, 31 Jan 2011 19:49:00 +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: Mon, 31 Jan 2011 19:48:59 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C04E79D41@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <201101311815.p0VIF9NT001647@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] mptcp-multiaddressed: How long before multipathstarts? Thread-Index: AcvBctMqDV7jPEQ2SJ+p6XZiqLga0wAAd9zA References: <201101311715.p0VHFCcA001378@bagheera.jungle.bt.co.uk> <133D9897FB9C5E4E9DF2779DC91E947C04E79D3E@SLFSNX.rcs.alcatel-research.de> <201101311815.p0VIF9NT001647@bagheera.jungle.bt.co.uk> From: "SCHARF, Michael" To: "Bob Briscoe" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] mptcp-multiaddressed: How long before multipathstarts? 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, 31 Jan 2011 18:45:49 -0000 Bob,=20 > -----Original Message----- > >The key question is whether app developers would ever be able to use=20 > >such an API. >=20 > The obvious case would be an HTTP server that sends the size=20 > of the object in the HTTP protocol before it starts sending=20 > it. So it would not be rocket-science to tell its own stack=20 > the same information as it already tells the remote end (and=20 > the remote end could tell its stack). of course, it is simple for someone familiar with TCP. I actually implemented exactly this function as proof-of-concept in the lighttpd HTTP server quite some time ago. In that case, it required less than 20 lines of code in the lighttpd Web server (I don't think that it would be much more complex in apache). Obviously, in my case the Web server operated on top of a fast startup Linux stack offering such an API by means of a new socket option. But, there are quite a bunch of other apps out there... > >Also, note that > >draft-ietf-mptcp-api already recommends to app developers to=20 > avoid many=20 > >small write socket calls. The reason for this statement is=20 > exactly to=20 > >avoid confusing stack-internal heuristics. >=20 > I noticed that while searching. I think the advice might need=20 > to be written the other way round - the heuristics would need=20 > to take account of the possibility of an app developer doing=20 > many small write socket calls. True, but this advice may not necessarily be in scope of the API draft, given that it does not address the algorithms at all. Michael From Michael.Tuexen@lurchi.franken.de Mon Jan 31 23:23:52 2011 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 04B833A6B64 for ; Mon, 31 Jan 2011 23:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.082, 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 t04rmGt0gVdw for ; Mon, 31 Jan 2011 23:23:50 -0800 (PST) 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 0E39E3A6A79 for ; Mon, 31 Jan 2011 23:23:49 -0800 (PST) Received: from [192.168.1.113] (p508FC9D6.dip.t-dialin.net [80.143.201.214]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 16A651C0C0BD8; Tue, 1 Feb 2011 08:27:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <613383.57734.qm@web39323.mail.mud.yahoo.com> Date: Tue, 1 Feb 2011 08:27:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7A7B916F-128B-42C4-B535-99ED507882D1@lurchi.franken.de> References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <613383.57734.qm@web39323.mail.mud.yahoo.com> To: Dirceu Cavendish X-Mailer: Apple Mail (2.1082) Cc: multipathtcp@ietf.org, iccrg Subject: Re: [multipathtcp] [Iccrg] Re: Please review "Coupled Congestion Control for Multipath Transport Protocols" 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, 01 Feb 2011 07:23:52 -0000 Dirceu, no, I have not received any feedback. I pinged the authors of the ID directly yesterday. Best regards Michael On Feb 1, 2011, at 3:31 AM, Dirceu Cavendish wrote: > Michael, >=20 > Did you get off (iccrg) list response to your point (2) below? I have = similar concerns to yours... >=20 > Dirceu >=20 > From: Michael T=FCxen > Cc: multipathtcp@ietf.org; iccrg > Sent: Wed, January 26, 2011 3:25:20 PM > Subject: [Iccrg] Re: [multipathtcp] Please review "Coupled Congestion = Control for Multipath Transport Protocols" >=20 > Hi Philip, >=20 > I have some questions regarding section 3: >=20 > (1) It is stated: > "Since we require that the total throughput is no worse > than the throughput a single TCP would get on the best path..." > and later: > "The formula is derived by equalizing the rate of the multipath = flow > with the rate of a TCP running on the best path, and solving for > alpha." > So what is considered here: > * throughput in bytes/sec > * rate in packets/sec > * rate in bytes/sec >=20 > (2) I don't understand the formula for alpha completely. I understand = how > the corresponding formula in "Practical Congestion Control for = Multipath > Transport Protocol" is derived. However, there the congestion = windows > are measured in MTUs (or MSS or packets). So it is more packet = rate > based. I could understand the formula in the ID if cwnd_i / mss_i = would > be used instead of cwnd_i * mss_i. So is it a typo or could = someone provide > a hint why cwnd_i * mss_i is used. >=20 > Best regards > Michael >=20 > On Jan 19, 2011, at 3:25 PM, = wrote: >=20 > > The Multipath TCP WG has developed a congestion control algorithm = that enables a TCP connection to use multiple paths. =20 > > http://tools.ietf.org/html/draft-ietf-mptcp-congestion > > =20 > > We=92re hoping to WG Last Call this document in February, so it = would be great if anyone from ICCRG could review it > > =20 > > Thanks, > > Phil & Yoshifumi > > MPTCP WG Chairs > > =20 > > Abstract > > =20 > > Often endpoints are connected by multiple paths, but = communications > > are usually restricted to a single path per connection. Resource > > usage within the network would be more efficient were it possible = for > > these multiple paths to be used concurrently. Multipath TCP is a > > proposal to achieve multipath transport in TCP. > > =20 > > New congestion control algorithms are needed for multipath = transport > > protocols such as Multipath TCP, as single path algorithms have a > > series of issues in the multipath context. One of the prominent > > problems is that running existing algorithms such as TCP New Reno > > independently on each path would give the multipath flow more = than > > its fair share at a bottleneck link traversed by more than one of = its > > subflows. Further, it is desirable that a source with multiple = paths > > available will transfer more traffic using the least congested of = the > > paths, hence achieving resource pooling. This would increase the > > overall utilization of the network and also its robustness to > > failure. > > =20 > > This document presents a congestion control algorithm which = couples > > the congestion control algorithms running on different subflows = by > > linking their increase functions, and dynamically controls the > > overall aggresiveness of the multipath flow. The result is a > > practical algorithm that is fair to TCP at bottlenecks while = moving > > traffic away from congested links. > > =20 > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 >=20 > _______________________________________________ > Iccrg mailing list > Iccrg@cs.ucl.ac.uk > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg >=20 >=20