Hi folks,
We're preparing for our WG meeting at Pra= gue.
If you're planning to present something, please provide us the = following info. Also, we will consider other ideas such as discussion for a= specific topic if you have one.

=C2=A0 =C2=A01: presenter's na= me
=C2=A0 =C2=A02: title
=C2=A0 =C2=A03: length of the presentation
If we don't have much requests, we might need to think reducing o= ur meeting time. So, even if you don't have a concrete plan yet, please= let us know it beforehand.

Thanks,
--
Yoshi & Phil

<= /div> --089e0117627def908a05189df5b5-- From nobody Tue Jun 16 14:18:06 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCEA1B3561 for ; Tue, 16 Jun 2015 14:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7uKT0gb0zkE for ; Tue, 16 Jun 2015 14:18:02 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A621A8FD3 for ; Tue, 16 Jun 2015 14:18:02 -0700 (PDT) Received: from lupo.localnet (cm-84.215.27.160.getinternet.no [84.215.27.160]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id t5GLHwn3032048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jun 2015 23:17:59 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Tue, 16 Jun 2015 23:17:57 +0200 Message-ID: <4260471.2hSYCvKC1b@lupo> User-Agent: KMail/4.14.2 (Linux/3.16.0-38-generic; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3581106.apDpGVCqyY"; micalg="pgp-sha1"; protocol="application/pgp-signature" 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 Archived-At: Subject: Re: [multipathtcp] Agenda for Prague meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 21:18:05 -0000 --nextPart3581106.apDpGVCqyY Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi Yoshifumi, as mentioned, I would like to present the results of our MPTCP experien= ces within the NorNet Testbed. It will show some interesting results fr= om recent research publications on measurements in the wired NorNet Cor= e testbed part (wired connections, in Norway and other countries) and t= he wireless NorNet Edge testbed part (mobile broadband ISPs in Norway).= 1: presenter's name: Thomas Dreibholz 2: title: MPTCP Experiences in the NorNet Testbed (draft-dreibholz-mptc= p-nornet-experience-01) 3: length of the presentation: 25-30 min. Tirsdag 16. juni 2015 00.59.58 skrev Yoshifumi Nishida: > Hi folks, > We're preparing for our WG meeting at Prague. > If you're planning to present something, please provide us the follow= ing > info. Also, we will consider other ideas such as discussion for a spe= cific > topic if you have one. >=20 > 1: presenter's name > 2: title > 3: length of the presentation >=20 > If we don't have much requests, we might need to think reducing our m= eeting > time. So, even if you don't have a concrete plan yet, please let us k= now it > beforehand. =2D-=20 Best regards / Mit freundlichen Gr=FC=DFen / Med vennlig hilsen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thomas Dreibholz Simula Research Laboratory Simula Innovation AS, Network Systems Group Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway Mailing address: P.O.Box 134, 1325 Lysaker, Norway =2D----------------------------------------------------------------------= E-Mail: dreibh@simula.no Homepage: http://simula.no/people/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 --nextPart3581106.apDpGVCqyY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlWAkoUACgkQ32BbsHYPLWWhNgCg0chyBEn72b9rR6KGhyU+lSW5 hZsAoNzRsi2fDQOUGXCRbz7N/uICkOkE =LZNZ -----END PGP SIGNATURE----- --nextPart3581106.apDpGVCqyY-- From nobody Wed Jun 17 01:00:29 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05841A1C02 for ; Wed, 17 Jun 2015 01:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiWrOiCpE-nG for ; Wed, 17 Jun 2015 01:00:24 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id A89361A1BEF for ; Wed, 17 Jun 2015 01:00:21 -0700 (PDT) Received: from wifi-secure1-387.sri.ucl.ac.be (wifi-secure1-387.sri.ucl.ac.be [130.104.93.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 5573218355D for ; Wed, 17 Jun 2015 10:00:11 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 5573218355D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1434528011; bh=eRfp+ERcf6m842C3WL+/8OIXbWBmlVUbZVtQlqoKSDE=; h=Reply-To:To:From:Subject:Message-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; b=O5FIE4+nQ8igG1fxa+N+ffQibLQYj4kZ65BC1+a3wFKHIABg/OWoc7PM6wBoen9Wv XK7KzN2YQkocjF8+47hp/XmutAc1cisIhb/HHIb4KDYH6zQ7ta2jQwV/e/YqjkkP4H DhO2hyUiQQG/3btVjXmqbJzqXLn6qK5Rk1U8R7Ks= To: multipathtcp From: Olivier Bonaventure Message-ID: <55812911.20204@uclouvain.be> Date: Wed, 17 Jun 2015 10:00:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 5573218355D.ADC2B X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: [multipathtcp] New draft : experimental options for Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 17 Jun 2015 08:00:27 -0000 Hello, There is growing number of proposals for new Multipath TCP experimental options. Given that the Multipath TCP option space is very restricted, we propose experimental options for Multipath TCP similar to RFC6994 for regular TCP. It would be useful to spend 5 minutes in Prague to discuss this draft. Comments are of course welcome Name: draft-bonaventure-mptcp-exp-option Revision: 00 Title: Experimental Multipath TCP option Document date: 2015-06-16 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt Status: https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-exp-option/ Htmlized: https://tools.ietf.org/html/draft-bonaventure-mptcp-exp-option-00 Abstract: This document proposes a generic format for an experimental Multipath TCP option. This experimental option is expected to replace the option type that was reserved for private use in [RFC6824]. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Wed Jun 17 03:41:26 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500B61A1BE7 for ; Wed, 17 Jun 2015 03:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YDrpcS33n6N for ; Wed, 17 Jun 2015 03:41:22 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560451A1BDC for ; Wed, 17 Jun 2015 03:41:22 -0700 (PDT) Received: from E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Jun 2015 11:41:19 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 17 Jun 2015 11:41:08 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 17 Jun 2015 11:41:07 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Wed, 17 Jun 2015 11:41:07 +0100 From: To: Thread-Topic: Arranging MPTCP hackathon Thread-Index: AdCo49gJMjnOQlOkSka9ypjQlN1P6g== Date: Wed, 17 Jun 2015 10:41:07 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Arranging MPTCP hackathon X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 10:41:25 -0000 Hi, So we had some nice interest for MPTCP joining the hackathon. It would be g= ood to work out a bit better what we should try to do. Let me summarise what I think people have suggested so far (sorry if I forg= ot any):=20 - Costin proposed an experiment with their code for a client connecting to = all the Wifi Access Points they see and spreading traffic over them with Mu= ltipath TCP. Work at the hackathon would write monitoring software & script= ing of experiments (which I guess could continue to run through the week). = Personally I think this would be interesting - as a contrast to the "usual"= operating mode of using mptcp for a back-up link ("usual" =3D my impressio= n of how most people have been using mptcp so far). I also know that Juan A= ntonio (UCLouvain) has a tool for monitoring the MPTCP bandwidth and delay = benefit (or penalty) and has experiments vs the bandwidth ratio of the diff= erent paths. Maybe these could be brought together somehow?? - Olivier B has offered to come to Prague (with colleagues?) if there other= s in Prague who want to work together on the MPTCP implementation in the Li= nux kernel or related tools like mptcptrace or tracebox.=20 - Thomas D offered access to the NorNet testbed (~100 nodes with Linux MPTC= P on ~20 sites most with multiple ISPs), plus possibility of VMs with modif= ied mptcp kernel. This is nice - what experiments would be done? Thomas has= also suggested (on the hackathon page) improving MPTCP support in their Ne= tPerfMeter tool. - Sowmini, from the Oracle Mainline Linux Kernel group, and Olivier discuss= ed some ideas for RDS-over-mptcp. I'm not sure if it's too early for an exp= eriment at the hackathon or if this is a possible topic? Also, (outside the= hackathon) how to expedite pushing changes upstream into the mainline kern= el.=20 - Ed L is also interest in joining - I remember that Nigel (FreeBSD implementation) also said he was in Prague= . Are there are other ideas or people who want to join a hackathon? Do we need to firm up on what people would like to try and do? - I guess so= mething around Costin's suggestion looks the most concrete idea so far? We should also decide what day(s) (Sat /Sun before the IETF) people want to= meet, and people need to register. There are currently 31 places left on S= unday and a few more on Sat, so we should firm things up fairly soon so peo= ple can register and make other travel arrangements etc. http://ietf.org/hackathon/93-hackathon.html=20 thanks phil > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 17 May 2015 11:13 > To: multipathtcp@ietf.org > Subject: [multipathtcp] FW: IETF hackathon >=20 > Anyone want to join the IETF Prague hackathon with some MPTCP related > work? > ________________________________________ > From: WGChairs on behalf of Jari Arkko > > Sent: 17 May 2015 10:17 > To: IETF WG Chairs > Subject: IETF hackathon >=20 > Chairs, >=20 > I wanted to highlight that in Prague we will have a hackathon event: >=20 > http://www.ietf.org/blog/2015/05/ietf-hackathon/ >=20 > Some of your working groups might have participants working actively on > software who might benefit from some time together. Or could implement > a small enhancement during the weekend. An opportunity for your > consideration. >=20 > Jari >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Wed Jun 17 04:33:02 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295E41A894B for ; Wed, 17 Jun 2015 04:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE23NXqWGx8H for ; Wed, 17 Jun 2015 04:33:00 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5301A0123 for ; Wed, 17 Jun 2015 04:32:59 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so34447057wgb.2 for ; Wed, 17 Jun 2015 04:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Wvoic9uxrc8pbbp52Ag1Bf9pzZ3ufwmUj2Dos4pQHJE=; b=g/5A14jIfk+/WGI+5zqcFDCEy6yc7n3/5IAEO0+XLj3nOLoBmRGXPcypXI5nQ4aOfl 8ux4DiFHto+rDCY/LEa5bey7AOstp1kOIcoz1PDKtaxoQBEDdbvYEe3TNOHEyK6cauwv h167GxnYGs04HMvziIUu9f1SWJNJZTbGp8VspZzzMdMgY4deHuo1IzdC+SUSAsQxMmta OOA6W919AZg2aQKCV80m/acqmHIPzwI8N5DXhtRoiy/yKNzoes4WPffoDErIcXwLfGuH MQWzV5oBwRr8YT1044yEbphj0ZLu8v1Icg5HqxUzY/xkCvHGshbY00aT6v4V9DcX6roT KQgA== MIME-Version: 1.0 X-Received: by 10.194.184.174 with SMTP id ev14mr4925887wjc.95.1434540778534; Wed, 17 Jun 2015 04:32:58 -0700 (PDT) Received: by 10.27.20.66 with HTTP; Wed, 17 Jun 2015 04:32:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jun 2015 07:32:58 -0400 Message-ID: From: Sowmini Varadhan To: philip.eardley@bt.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Arranging MPTCP hackathon X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 11:33:01 -0000 On Wed, Jun 17, 2015 at 6:41 AM, wrote: > - Sowmini, from the Oracle Mainline Linux Kernel group, and Olivier discu= ssed some ideas for RDS-over-mptcp. I'm not sure if it's too early for an e= xperiment at the hackathon or if this is a possible topic? Also, (outside t= he hackathon) how to expedite pushing changes upstream into the mainline ke= rnel. This might actually be an interesting experiment to try out, and I could help set this up (though I only arrive sunday) I did have a chance to poke around the kernel data-structures and paths, so I will probably need some clarifications about the code. BTW, the 3.14.33 kernel (even without mptcp) does not come up on sparc (networking is broken.. arp works but not much else), so moving forward to a more recent kernel would make this much more interesting for us.. --Sowmini From nobody Thu Jun 18 08:16:28 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D261B30A4 for ; Thu, 18 Jun 2015 08:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGoVhm_CEHoH for ; Thu, 18 Jun 2015 08:16:25 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 15C6B1ACE19 for ; Thu, 18 Jun 2015 08:16:25 -0700 (PDT) Received: from vpn0230.sri.ucl.ac.be (vpn0230.sri.ucl.ac.be [130.104.240.230]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 2AAB1198272; Thu, 18 Jun 2015 17:16:19 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 2AAB1198272 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1434640579; bh=t1dkqJ4L2o++4EMA2VeSE1adZhkDDsPQ+wSw0XfZYNQ=; h=Reply-To:Subject:References:To:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding:Date:From: MIME-Version:To:Subject:References:In-Reply-To:Content-Type:; b=G21yU4968jVjmrHomdaN2hYgOXF780oEV/ixC/BfnbWspiIjtVJqsUZfeGyL9GcC+ 4FuITGLPrZS/0SlQt26mcZfnkbL2d6v1FgO0GtvWxMTQGOrEk2/yMsdUiv1FeU8m7k 4/EUg8efL2LEcFVbPbiGFVjHTqJepIo2OQsbZico= References: To: philip.eardley@bt.com, multipathtcp@ietf.org From: Olivier Bonaventure Message-ID: <5582E0CA.6050207@uclouvain.be> Date: Thu, 18 Jun 2015 17:16:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 2AAB1198272.A1CE4 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Arranging MPTCP hackathon X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 15:16:27 -0000 Phil, > > So we had some nice interest for MPTCP joining the hackathon. It would be good to work out a bit better what we should try to do. > > Let me summarise what I think people have suggested so far (sorry if I forgot any): > > - Costin proposed an experiment with their code for a client connecting to all the Wifi Access Points they see and spreading traffic over them with Multipath TCP. Work at the hackathon would write monitoring software & scripting of experiments (which I guess could continue to run through the week). Personally I think this would be interesting - as a contrast to the "usual" operating mode of using mptcp for a back-up link ("usual" = my impression of how most people have been using mptcp so far). I also know that Juan Antonio (UCLouvain) has a tool for monitoring the MPTCP bandwidth and delay benefit (or penalty) and has experiments vs the bandwidth ratio of the different paths. Maybe these could be brought together somehow?? > - Olivier B has offered to come to Prague (with colleagues?) if there others in Prague who want to work together on the MPTCP implementation in the Linux kernel or related tools like mptcptrace or tracebox. We discussed a bit internally and here are two projects that look feasible within a weekend and involve code : - extend the MPTCP Linux kernel to collect and expose more statistics (e.g. through netstat) about the established MPTCP connections and their performance. This would require some knowledge of MPTCP to identify the statistics that are useful and kernel knowledge to add them. - develop test scripts to validate the operation of MPTCP through various types of middleboxes with tracebox (see http://www.tracebox.org) If some people are interested by these projects several members of the group in Louvain-la-neuve can come to Prague for the weekend. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Thu Jun 18 08:26:55 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066E01A8A92 for ; Thu, 18 Jun 2015 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMnWwWyyXODc for ; Thu, 18 Jun 2015 08:26:51 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 744EF1ACDCF for ; Thu, 18 Jun 2015 08:26:51 -0700 (PDT) Received: from vpn0230.sri.ucl.ac.be (vpn0230.sri.ucl.ac.be [130.104.240.230]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id C790E183445; Thu, 18 Jun 2015 17:26:45 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be C790E183445 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1434641205; bh=RGU/rtD6l71YepMQH/ooZ27p1rEH2at0iIXLbf0U2II=; h=Reply-To:Subject:References:To:Cc:From:Message-ID:Date: MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=iQt2gYIyyrjfjqabm4Ww7kRhpfVXnmdafhC9CIU2DJxmd25iEXpgeGcsRb++xmeVX Ga8ItzO9PAdvYB2U8aeg+AaTaxh60WnclGZ0G+p5hw51Pi0h+O49CNo8dKq6zmfVQx st5HTbDYUjWiO+iZCQ89YhBvR34qyrkPfvH1rrwI= References: To: Sowmini Varadhan , philip.eardley@bt.com From: Olivier Bonaventure Message-ID: <5582E33B.3010804@uclouvain.be> Date: Thu, 18 Jun 2015 17:26:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: C790E183445.A001C X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Arranging MPTCP hackathon X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 15:26:53 -0000 Sowmini, > >> - Sowmini, from the Oracle Mainline Linux Kernel group, and Olivier discussed some ideas for RDS-over-mptcp. I'm not sure if it's too early for an experiment at the hackathon or if this is a possible topic? Also, (outside the hackathon) how to expedite pushing changes upstream into the mainline kernel. > > This might actually be an interesting experiment to try out, > and I could help set this up (though I only arrive sunday) > > I did have a chance to poke around the kernel data-structures > and paths, so I will probably need some clarifications about the code. > > BTW, the 3.14.33 kernel (even without mptcp) does not come up on > sparc (networking is broken.. arp works but not much else), so moving > forward to a more recent kernel would make this > much more interesting for us.. The trunk branch is already using kernel 3.18, but we never tried anything on sparcs. https://github.com/multipath-tcp/mptcp/tree/mptcp_trunk Olivier From nobody Thu Jun 18 08:50:26 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A081B32AB for ; Thu, 18 Jun 2015 08:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlmdbIwZH14C for ; Thu, 18 Jun 2015 08:50:23 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908741B32C1 for ; Thu, 18 Jun 2015 08:50:13 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so67493207wgb.2 for ; Thu, 18 Jun 2015 08:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rwNyKvlXBF7q7ryWnnkmnk4+iY9MWwv9k4WQn14L+hQ=; b=Z9y9i92+S2CJ1h9NB5m9WGzq7RcpPeZGnomcmC3NoWonuu2Q/3QN+mV5ghHAI8Y4ZU jRZCHtoEJL3T3pXS/n3MzWcttX2DsGf57k48NCIQAx+d57s+a07wGiupr5WGRbkPujtW atp2UgVBOpsev1P87b6jTYzLOfTZ8POgA0XKDQbHfzj9s40kiGZxRNrpKPt4a+6R9k8m K3yYF/wAxW6rAf03vz0AyqjCKTYbxE1HbsN7Uod6t8PCQVbTzEDY+4Wox1MHHRzbmt0n UyRFSIWXMnGJ4/pUeGujybv3d3xoH4ndLP2NY672ryyRhXtLHlnvvCnu+C1spSQ86mjP Vi0Q== MIME-Version: 1.0 X-Received: by 10.194.89.36 with SMTP id bl4mr5370560wjb.95.1434642612229; Thu, 18 Jun 2015 08:50:12 -0700 (PDT) Received: by 10.27.20.66 with HTTP; Thu, 18 Jun 2015 08:50:12 -0700 (PDT) In-Reply-To: <5582E33B.3010804@uclouvain.be> References: <5582E33B.3010804@uclouvain.be> Date: Thu, 18 Jun 2015 11:50:12 -0400 Message-ID: From: Sowmini Varadhan To: Olivier Bonaventure Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Arranging MPTCP hackathon X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 15:50:24 -0000 On Thu, Jun 18, 2015 at 11:26 AM, Olivier Bonaventure wrote: > > The trunk branch is already using kernel 3.18, but we never tried anything > on sparcs. > > https://github.com/multipath-tcp/mptcp/tree/mptcp_trunk > ah, ok, I know that the base 3.18 kernel is fine on sparc, so let me give this a try.. --Sowmini From nobody Fri Jun 19 09:28:11 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440D71AC3F0 for ; Fri, 19 Jun 2015 09:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77gi1rPD7N65 for ; Fri, 19 Jun 2015 09:28:06 -0700 (PDT) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AA21A1A1E for ; Fri, 19 Jun 2015 09:28:05 -0700 (PDT) Received: from Nigels-Air.attlocal.net (vpn242-192.cc.swin.edu.au [136.186.242.192]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t5JGRt7l014908; Sat, 20 Jun 2015 02:27:56 +1000 Message-ID: <5584430A.90104@swin.edu.au> Date: Sat, 20 Jun 2015 02:27:54 +1000 From: Nigel Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: philip.eardley@bt.com, multipathtcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [multipathtcp] Arranging MPTCP hackathon X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 16:28:09 -0000 Hi Philip, On 17/06/2015 8:41 pm, philip.eardley@bt.com wrote: > Hi, > > So we had some nice interest for MPTCP joining the hackathon. It would be good to work out a bit better what we should try to do. > > Let me summarise what I think people have suggested so far (sorry if I forgot any): > > - Costin proposed an experiment with their code for a client connecting to all the Wifi Access Points they see and spreading traffic over them with Multipath TCP. Work at the hackathon would write monitoring software & scripting of experiments (which I guess could continue to run through the week). Personally I think this would be interesting - as a contrast to the "usual" operating mode of using mptcp for a back-up link ("usual" = my impression of how most people have been using mptcp so far). I also know that Juan Antonio (UCLouvain) has a tool for monitoring the MPTCP bandwidth and delay benefit (or penalty) and has experiments vs the bandwidth ratio of the different paths. Maybe these could be brought together somehow?? > - Olivier B has offered to come to Prague (with colleagues?) if there others in Prague who want to work together on the MPTCP implementation in the Linux kernel or related tools like mptcptrace or tracebox. > - Thomas D offered access to the NorNet testbed (~100 nodes with Linux MPTCP on ~20 sites most with multiple ISPs), plus possibility of VMs with modified mptcp kernel. This is nice - what experiments would be done? Thomas has also suggested (on the hackathon page) improving MPTCP support in their NetPerfMeter tool. > - Sowmini, from the Oracle Mainline Linux Kernel group, and Olivier discussed some ideas for RDS-over-mptcp. I'm not sure if it's too early for an experiment at the hackathon or if this is a possible topic? Also, (outside the hackathon) how to expedite pushing changes upstream into the mainline kernel. > - Ed L is also interest in joining > - I remember that Nigel (FreeBSD implementation) also said he was in Prague. > I won't be arriving until Sunday afternoon, but some interop testing would be of interest, or even some discussion relating to that. cheers, nigel > Are there are other ideas or people who want to join a hackathon? > Do we need to firm up on what people would like to try and do? - I guess something around Costin's suggestion looks the most concrete idea so far? > > We should also decide what day(s) (Sat /Sun before the IETF) people want to meet, and people need to register. There are currently 31 places left on Sunday and a few more on Sat, so we should firm things up fairly soon so people can register and make other travel arrangements etc. > http://ietf.org/hackathon/93-hackathon.html > > thanks > phil > >> -----Original Message----- >> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of >> philip.eardley@bt.com >> Sent: 17 May 2015 11:13 >> To: multipathtcp@ietf.org >> Subject: [multipathtcp] FW: IETF hackathon >> >> Anyone want to join the IETF Prague hackathon with some MPTCP related >> work? >> ________________________________________ >> From: WGChairs on behalf of Jari Arkko >> >> Sent: 17 May 2015 10:17 >> To: IETF WG Chairs >> Subject: IETF hackathon >> >> Chairs, >> >> I wanted to highlight that in Prague we will have a hackathon event: >> >> http://www.ietf.org/blog/2015/05/ietf-hackathon/ >> >> Some of your working groups might have participants working actively on >> software who might benefit from some time together. Or could implement >> a small enhancement during the weekend. An opportunity for your >> consideration. >> >> Jari >> >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From nobody Fri Jun 19 09:32:39 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153BF1AC3F4 for ; Fri, 19 Jun 2015 09:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAyEmlISwqR1 for ; Fri, 19 Jun 2015 09:32:34 -0700 (PDT) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A4A1AC40D for ; Fri, 19 Jun 2015 09:32:27 -0700 (PDT) Received: from Nigels-Air.attlocal.net (vpn242-192.cc.swin.edu.au [136.186.242.192]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t5JGWMRJ030441; Sat, 20 Jun 2015 02:32:23 +1000 Message-ID: <55844416.2060103@swin.edu.au> Date: Sat, 20 Jun 2015 02:32:22 +1000 From: Nigel Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yoshifumi Nishida , multipathtcp References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [multipathtcp] Agenda for Prague meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 16:32:36 -0000 Hi Yoshifumi, I'd like to present a status update on the FreeBSD implementation I've been working on. 1: Nigel Williams 2: Status update - MPTCP for FreeBSD 3: 10-15 mins cheers, nigel On 16/06/2015 5:59 pm, Yoshifumi Nishida wrote: > Hi folks, > We're preparing for our WG meeting at Prague. > If you're planning to present something, please provide us the following > info. Also, we will consider other ideas such as discussion for a > specific topic if you have one. > > 1: presenter's name > 2: title > 3: length of the presentation > > If we don't have much requests, we might need to think reducing our > meeting time. So, even if you don't have a concrete plan yet, please let > us know it beforehand. > > Thanks, > -- > Yoshi & Phil > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From nobody Fri Jun 19 11:35:10 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7381ACE48 for ; Fri, 19 Jun 2015 11:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlBQzFlm7Nm2 for ; Fri, 19 Jun 2015 11:35:07 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id BA7D11ACE46 for ; Fri, 19 Jun 2015 11:35:07 -0700 (PDT) Received: from ndjsppt105.ndc.nasa.gov (ndjsppt105.ndc.nasa.gov [198.117.1.199]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 7FEBE180C2A; Fri, 19 Jun 2015 13:32:08 -0500 (CDT) Received: from NDJSCHT116.ndc.nasa.gov (ndjscht116-pub.ndc.nasa.gov [198.117.1.216]) by ndjsppt105.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id t5JIZ63f002272; Fri, 19 Jun 2015 13:35:06 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.138]) by NDJSCHT116.ndc.nasa.gov ([198.117.1.216]) with mapi id 14.03.0224.002; Fri, 19 Jun 2015 13:35:06 -0500 From: "Ivancic, William D. (GRC-LCA0)" To: Nigel Williams , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Arranging MPTCP hackathon Thread-Index: AdCo49gJMjnOQlOkSka9ypjQlN1P6gB8vVkA///gfYA= Date: Fri, 19 Jun 2015 18:35:05 +0000 Message-ID: References: <5584430A.90104@swin.edu.au> In-Reply-To: <5584430A.90104@swin.edu.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [139.88.7.182] Content-Type: text/plain; charset="us-ascii" Content-ID: <5911B7DB140F1D4D974E66124457C36D@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-06-19_06:, , signatures=0 Archived-At: Cc: "Ishac, Joseph A. \(GRC-LCA0\)" Subject: Re: [multipathtcp] Arranging MPTCP hackathon X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 18:35:09 -0000 On 6/19/15 12:27 PM, "Nigel Williams" wrote: >Hi Philip, > >On 17/06/2015 8:41 pm, philip.eardley@bt.com wrote: >> Hi, >> >> So we had some nice interest for MPTCP joining the hackathon. It would >>be good to work out a bit better what we should try to do. >> >> Let me summarise what I think people have suggested so far (sorry if I >>forgot any): >> >> - Costin proposed an experiment with their code for a client connecting >>to all the Wifi Access Points they see and spreading traffic over them >>with Multipath TCP. Work at the hackathon would write monitoring >>software & scripting of experiments (which I guess could continue to run >>through the week). Personally I think this would be interesting - as a >>contrast to the "usual" operating mode of using mptcp for a back-up link >>("usual" =3D my impression of how most people have been using mptcp so >>far). I also know that Juan Antonio (UCLouvain) has a tool for >>monitoring the MPTCP bandwidth and delay benefit (or penalty) and has >>experiments vs the bandwidth ratio of the different paths. Maybe these >>could be brought together somehow?? >> - Olivier B has offered to come to Prague (with colleagues?) if there >>others in Prague who want to work together on the MPTCP implementation >>in the Linux kernel or related tools like mptcptrace or tracebox. My contract to work MPTCP for channel combining should start this July. One of my tasks is developing test tools such as mptcptrace as well real-time PPP captures (Comparing PPP-MP to MPTCP). I think the community will find both tools useful. Feel free to contact me via email. I will be meeting my sponsor next week. Unfortunately, I cannot physically make the Prague meeting. Will From nobody Tue Jun 23 22:36:01 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E14D1ACE92 for ; Tue, 23 Jun 2015 22:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUPOkOqOga7B for ; Tue, 23 Jun 2015 22:35:59 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1141A0084 for ; Tue, 23 Jun 2015 22:35:59 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t5O5Zu0T010171 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Jun 2015 05:35:57 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t5O5ZuxX013144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Jun 2015 05:35:56 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t5O5Zuil021297; Wed, 24 Jun 2015 05:35:56 GMT Received: from [10.159.253.16] (/10.159.253.16) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jun 2015 22:35:56 -0700 Message-ID: <558A41B4.20101@oracle.com> Date: Tue, 23 Jun 2015 22:35:48 -0700 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: multipathtcp@ietf.org, Olivier Bonaventure Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [multipathtcp] Some comments on RFC 6824 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 05:36:00 -0000 Hi All, I am implementing MPTCP in Solaris and have a few comments below based on my implementation experience so far. 1) Currently the RFC says that checksum in DSS option 'SHOULD' be present. Requiring checksum is a performance killer because it has to be calculated in the software and needs to be calculated over the ENTIRE mapping. This also means that the receiver has to wait to receive the complete mapping worth of data before it can be processed. More importantly these days most NIC's support HW checksum offload and that feature is commonly used, this requirement makes this important HW feature useless. I am hoping that the requirement of requiring checksum in the DSS option be relaxed and may even not be required in a data center. 2) The RFC does not say what the initial subflow sequence number should be. Can this be made clear. Why not use the TCP sequence number of the subflow. 3) When calculating the HMAC, token, key's sequence number etc it is not at all clear which values have to be in network byte order and which not. Can this be explicitly specified in the RFC. 4) Can we not allow dropping a segment after it has been acked at the subflow level. It is very unlikely that a network element would drop a TCP segment after it has been processed and acked. Making this change would make buffer management much easier. If an element can drop a packet than it should not ack, but other implementation should not be burdened by this requirement. Thanks, Shoaib From nobody Wed Jun 24 01:29:41 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E42D1B3221 for ; Wed, 24 Jun 2015 01:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyV3iYgjOOYC for ; Wed, 24 Jun 2015 01:29:38 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B72E1B3220 for ; Wed, 24 Jun 2015 01:29:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0693D20F2B for ; Wed, 24 Jun 2015 04:29:38 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 24 Jun 2015 04:29:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=GpEk7uYFJxX2oO1 RUdM9+tudVJY=; b=MPbfYuCkKYba34760ZU94S7YRfC9pclcCJLKrZVFslMld42 fWCd8OEoWCwgGRqXsTmZfqsJDHXj0xgrT73CVy9wf3gtGem5b4mto4KhbfMyDMWj ce3XqCt7nVhs701dgA/JLHHQZYkM71ghFRjcEkVigDBcYOqnsB5VLBp+U+FE= Received: by web3.nyi.internal (Postfix, from userid 99) id D61F410C504; Wed, 24 Jun 2015 04:29:37 -0400 (EDT) Message-Id: <1435134577.220191.306301545.4F7DBC25@webmail.messagingengine.com> X-Sasl-Enc: BgXp/f/vCkerxZl3nulQxcLBelMja60xoZZWN2WQnERA 1435134577 From: Mark Handley To: multipathtcp@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-eecef38c In-Reply-To: <558A41B4.20101@oracle.com> References: <558A41B4.20101@oracle.com> Date: Wed, 24 Jun 2015 09:29:37 +0100 Archived-At: Subject: Re: [multipathtcp] Some comments on RFC 6824 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 08:29:40 -0000 On Wed, Jun 24, 2015, at 06:35 AM, Rao Shoaib wrote: > Hi All, > > I am implementing MPTCP in Solaris and have a few comments below based > on my implementation experience so far. > > 1) Currently the RFC says that checksum in DSS option 'SHOULD' be > present. Requiring checksum is a performance killer because it has to > be calculated in the software and needs to be calculated over the ENTIRE > mapping. This also means that the receiver has to wait to receive the > complete mapping worth of data before it can be processed. More > importantly these days most NIC's support HW checksum offload and that > feature is commonly used, this requirement makes this important HW > feature useless. > > I am hoping that the requirement of requiring checksum in the DSS option > be relaxed and may even not be required in a data center. The DSS checksum is to catch MPTCP-unaware middleboxes that modify content, and permit graceful fallback to regular TCP, so the content stream does not end up corrupted. If you know for sure there is no such middlebox on the path (as in some datacenters) then disabling the checksum should be fine. That's why it's a SHOULD, not a MUST. When MPTCP is eventually commonplace, NICs will no doubt do DSS checksum offload too, and integrate it into TSO. > 4) Can we not allow dropping a segment after it has been acked at the > subflow level. It is very unlikely that a network element would drop a > TCP segment after it has been processed and acked. Making this change > would make buffer management much easier. If an element can drop a > packet than it should not ack, but other implementation should not be > burdened by this requirement. The problem is that in the presence of middleboxes, you can't be sure that a subflow ack means the data got there. This usually isn't a huge issue with TCP because you share fate with the middlebox. For MPTCP though, you don't share fate with the middlebox. Consider the following scenario: You've a mobile host, downloading over 3G and WiFi. There's a middlebox on the 3G path that's proactively acking data - we do see such things in the wild. At some point the client moves into a place where 3G reception is blocked but WiFi is provided - this scenario is common in the London Underground system for example. At the point the 3G drops, some data had been acked by the middlebox, but not received by the mobile host. If the server had freed the data from its socket buffer, the connection is now deadlocked. The current MPTCP spec says the sender can't free this data - it hasn't received a data ack yet - so there's no problem; the data will be resent over WiFi and everything is fine. Hope that helps with the rationale. Cheers, Mark From nobody Wed Jun 24 10:32:55 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F191A1B66 for ; Wed, 24 Jun 2015 10:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sqPIcDy8N0W for ; Wed, 24 Jun 2015 10:32:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9EA1A1B3D for ; Wed, 24 Jun 2015 10:32:33 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t5OHWWng022100 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 24 Jun 2015 17:32:32 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t5OHWV75005484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Jun 2015 17:32:31 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t5OHWVUj029422 for ; Wed, 24 Jun 2015 17:32:31 GMT Received: from [10.159.252.99] (/10.159.252.99) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Jun 2015 10:32:31 -0700 Message-ID: <558AE9A4.8020609@oracle.com> Date: Wed, 24 Jun 2015 10:32:20 -0700 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: multipathtcp@ietf.org, Leonid Grossman , Sharon Liu References: <558A41B4.20101@oracle.com> <1435134577.220191.306301545.4F7DBC25@webmail.messagingengine.com> In-Reply-To: <1435134577.220191.306301545.4F7DBC25@webmail.messagingengine.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [multipathtcp] Some comments on RFC 6824 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 17:32:54 -0000 Hi Mark, Please see inline On 06/24/2015 01:29 AM, Mark Handley wrote: > > On Wed, Jun 24, 2015, at 06:35 AM, Rao Shoaib wrote: >> Hi All, >> >> I am implementing MPTCP in Solaris and have a few comments below based >> on my implementation experience so far. >> >> 1) Currently the RFC says that checksum in DSS option 'SHOULD' be >> present. Requiring checksum is a performance killer because it has to >> be calculated in the software and needs to be calculated over the ENTIRE >> mapping. This also means that the receiver has to wait to receive the >> complete mapping worth of data before it can be processed. More >> importantly these days most NIC's support HW checksum offload and that >> feature is commonly used, this requirement makes this important HW >> feature useless. >> >> I am hoping that the requirement of requiring checksum in the DSS option >> be relaxed and may even not be required in a data center. > The DSS checksum is to catch MPTCP-unaware middleboxes that modify > content, and permit graceful fallback to regular TCP, so the content > stream does not end up corrupted. If you know for sure there is no such > middlebox on the path (as in some datacenters) then disabling the > checksum should be fine. That's why it's a SHOULD, not a MUST. > > When MPTCP is eventually commonplace, NICs will no doubt do DSS checksum > offload too, and integrate it into TSO. Can we make this clear in the RFC as convincing customers to turn off checksum is not easy even when they complain about performance. > >> 4) Can we not allow dropping a segment after it has been acked at the >> subflow level. It is very unlikely that a network element would drop a >> TCP segment after it has been processed and acked. Making this change >> would make buffer management much easier. If an element can drop a >> packet than it should not ack, but other implementation should not be >> burdened by this requirement. > The problem is that in the presence of middleboxes, you can't be sure > that a subflow ack means the data got there. This usually isn't a huge > issue with TCP because you share fate with the middlebox. For MPTCP > though, you don't share fate with the middlebox. Consider the following > scenario: > > You've a mobile host, downloading over 3G and WiFi. There's a middlebox > on the 3G path that's proactively acking data - we do see such things in > the wild. At some point the client moves into a place where 3G > reception is blocked but WiFi is provided - this scenario is common in > the London Underground system for example. At the point the 3G drops, > some data had been acked by the middlebox, but not received by the > mobile host. If the server had freed the data from its socket buffer, > the connection is now deadlocked. The current MPTCP spec says the > sender can't free this data - it hasn't received a data ack yet - so > there's no problem; the data will be resent over WiFi and everything is > fine. > > Hope that helps with the rationale. The example helps out a lot and now I understand the issue. This requirement requires holding onto the TCP buffer after it has been acked and that requires some not so clean changes to existing TCP code. Let me think a little more on how to implement this efficiently. Thanks a lot for your prompt reply. Shoaib. > > Cheers, > Mark > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Wed Jun 24 22:48:16 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F20B1B2F9F for ; Wed, 24 Jun 2015 22:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNqdo8J8eKDX for ; Wed, 24 Jun 2015 22:48:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33A91B2F9D for ; Wed, 24 Jun 2015 22:48:12 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t5P5mApY026985 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 25 Jun 2015 05:48:12 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t5P5mAME018789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 25 Jun 2015 05:48:10 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t5P5mA6f021001 for ; Thu, 25 Jun 2015 05:48:10 GMT Received: from [10.159.252.99] (/10.159.252.99) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Jun 2015 22:48:10 -0700 Message-ID: <558B960F.5080309@oracle.com> Date: Wed, 24 Jun 2015 22:47:59 -0700 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: multipathtcp@ietf.org References: <558A41B4.20101@oracle.com> <1435134577.220191.306301545.4F7DBC25@webmail.messagingengine.com> <558AE9A4.8020609@oracle.com> In-Reply-To: <558AE9A4.8020609@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [multipathtcp] Some comments on RFC 6824 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 05:48:14 -0000 On 06/24/2015 10:32 AM, Rao Shoaib wrote: > Hi Mark, > > Please see inline > > On 06/24/2015 01:29 AM, Mark Handley wrote: >> >> On Wed, Jun 24, 2015, at 06:35 AM, Rao Shoaib wrote: >>> Hi All, >>> >>> I am implementing MPTCP in Solaris and have a few comments below based >>> on my implementation experience so far. >>> >>> 1) Currently the RFC says that checksum in DSS option 'SHOULD' be >>> present. Requiring checksum is a performance killer because it has to >>> be calculated in the software and needs to be calculated over the >>> ENTIRE >>> mapping. This also means that the receiver has to wait to receive the >>> complete mapping worth of data before it can be processed. More >>> importantly these days most NIC's support HW checksum offload and that >>> feature is commonly used, this requirement makes this important HW >>> feature useless. >>> >>> I am hoping that the requirement of requiring checksum in the DSS >>> option >>> be relaxed and may even not be required in a data center. >> The DSS checksum is to catch MPTCP-unaware middleboxes that modify >> content, and permit graceful fallback to regular TCP, so the content >> stream does not end up corrupted. If you know for sure there is no such >> middlebox on the path (as in some datacenters) then disabling the >> checksum should be fine. That's why it's a SHOULD, not a MUST. >> >> When MPTCP is eventually commonplace, NICs will no doubt do DSS checksum >> offload too, and integrate it into TSO. > Can we make this clear in the RFC as convincing customers to turn off > checksum is not easy even when they complain about performance. I went back and looked at RFC 6824. I find that the text on page 16 is quite clear. So there is no need to take any action. Shoaib >> >>> 4) Can we not allow dropping a segment after it has been acked at the >>> subflow level. It is very unlikely that a network element would drop a >>> TCP segment after it has been processed and acked. Making this change >>> would make buffer management much easier. If an element can drop a >>> packet than it should not ack, but other implementation should not be >>> burdened by this requirement. >> The problem is that in the presence of middleboxes, you can't be sure >> that a subflow ack means the data got there. This usually isn't a huge >> issue with TCP because you share fate with the middlebox. For MPTCP >> though, you don't share fate with the middlebox. Consider the following >> scenario: >> >> You've a mobile host, downloading over 3G and WiFi. There's a middlebox >> on the 3G path that's proactively acking data - we do see such things in >> the wild. At some point the client moves into a place where 3G >> reception is blocked but WiFi is provided - this scenario is common in >> the London Underground system for example. At the point the 3G drops, >> some data had been acked by the middlebox, but not received by the >> mobile host. If the server had freed the data from its socket buffer, >> the connection is now deadlocked. The current MPTCP spec says the >> sender can't free this data - it hasn't received a data ack yet - so >> there's no problem; the data will be resent over WiFi and everything is >> fine. >> >> Hope that helps with the rationale. > The example helps out a lot and now I understand the issue. This > requirement requires holding onto the TCP buffer after it has been > acked and that requires some not so clean changes to existing TCP > code. Let me think a little more on how to implement this efficiently. > > Thanks a lot for your prompt reply. > > Shoaib. > >> >> Cheers, >> Mark >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > From nobody Thu Jun 25 10:06:39 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1D1A92F3 for ; Thu, 25 Jun 2015 10:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.921 X-Spam-Level: *** X-Spam-Status: No, score=3.921 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L64dwM3q110V for ; Thu, 25 Jun 2015 10:06:36 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F331A92EC for ; Thu, 25 Jun 2015 10:06:35 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A59682780EC for ; Fri, 26 Jun 2015 02:06:33 +0900 (JST) Received: by oigb199 with SMTP id b199so57267757oig.3 for ; Thu, 25 Jun 2015 10:06:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.108.142 with SMTP id h136mr5392953oic.5.1435251992443; Thu, 25 Jun 2015 10:06:32 -0700 (PDT) Received: by 10.202.177.193 with HTTP; Thu, 25 Jun 2015 10:06:32 -0700 (PDT) Date: Thu, 25 Jun 2015 10:06:32 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a1142da9c2c43b905195aa5d3 Archived-At: Subject: [multipathtcp] mptcp in galaxy phones X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 17:06:37 -0000 --001a1142da9c2c43b905195aa5d3 Content-Type: text/plain; charset=UTF-8 During a great dinner last night, Christoph provided me this interesting news. Thanks! http://www.sammobile.com/2015/06/12/samsung-to-flip-the-switch-on-lte-x-for-galaxy-s6-and-galaxy-s6-edge-soon/ -- Yoshi --001a1142da9c2c43b905195aa5d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

During a great dinner last night, Christoph provided me th= is interesting news. Thanks!

http://www.sammobile.com/2015/06/12/samsung-to-flip-th= e-switch-on-lte-x-for-galaxy-s6-and-galaxy-s6-edge-soon/

Yoshi

--001a1142da9c2c43b905195aa5d3-- From nobody Fri Jun 26 10:21:39 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BEB1A87DB for ; Fri, 26 Jun 2015 10:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0A3aKXHyqT7 for ; Fri, 26 Jun 2015 10:21:34 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CB51A0373 for ; Fri, 26 Jun 2015 10:21:34 -0700 (PDT) Received: from E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 26 Jun 2015 18:21:29 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) with Microsoft SMTP Server (TLS) id 8.3.342.0; Fri, 26 Jun 2015 18:21:32 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 26 Jun 2015 18:21:32 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Fri, 26 Jun 2015 18:21:32 +0100 From: To: Thread-Topic: MPTCP draft agenda for Prague Thread-Index: AdCv/w6oaw+ZSPMmQIOp60un9O6p5g== Date: Fri, 26 Jun 2015 17:21:31 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_e305b36a82b64850ae157a45c3df2bc6rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] MPTCP draft agenda for Prague X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 17:21:37 -0000 --_000_e305b36a82b64850ae157a45c3df2bc6rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We uploaded an initial version of the agenda https://www.ietf.org/proceedings/93/agenda/agenda-93-mptcp Please let us know if we forgot any requests (or added some that are not ne= eded), or if there are any further requests. There are quite a lot of requests for agenda time - it is great that there'= s a lot of activity - I know there are several new drafts since the last ie= tf, with likely more before the cut-off deadline. Unfortunately this means that probably not everyone can get all the time th= ey asked for. We'll prioritise the WG Experiences draft, discussion on how = to progress the protocol bis, and other topics which would most usefully be= discussed face to face. One option is that we see if we can get a second timeslot. Don't know if th= is would be possible (the IETF agenda is very full), but most likely it wou= ld be Friday afternoon (if it's possible). If you'd like us to try, please = say (the default is that we stick with 1 slot). I want to keep our current = slot, Tuesday 1-3pm (on the preliminary IETF agenda) - since some extra peo= ple may come for the hackathon and be able to stay for this. Thanks Phil & Yoshi. --_000_e305b36a82b64850ae157a45c3df2bc6rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We uploaded an initial version of the age= nda

https://www.ietf.org/proceedings/93/agenda/ag= enda-93-mptcp

Please let us know if we forgot any reque= sts (or added some that are not needed), or if there are any further reques= ts.

There are quite a lot of requests for age= nda time – it is great that there’s a lot of activity – I= know there are several new drafts since the last ietf, with likely more be= fore the cut-off deadline.

Unfortunately this means that probably no= t everyone can get all the time they asked for. We’ll prioritise the = WG Experiences draft, discussion on how to progress the protocol bis, and other topics which would most usefully be discussed face to face.=

One option is that we see if we can get a= second timeslot. Don’t know if this would be possible (the IETF agen= da is very full), but most likely it would be Friday afternoon (if it’s possible). If you’d like us to try, please say (the d= efault is that we stick with 1 slot). I want to keep our current slot, Tues= day 1-3pm (on the preliminary IETF agenda) – since some extra people = may come for the hackathon and be able to stay for this.

Thanks

Phil & Yoshi.

--_000_e305b36a82b64850ae157a45c3df2bc6rew09926dag03bdomain1sy_--