From nobody Wed Oct 1 08:59:32 2014 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 375271ACE4A for ; Wed, 1 Oct 2014 08:59:31 -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 u5DaN0uuG75Z for ; Wed, 1 Oct 2014 08:59:28 -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 79BFC1ACE49 for ; Wed, 1 Oct 2014 08:59:28 -0700 (PDT) Received: from mbpobo-2.dhcp.info.ucl.ac.be (mbpobo-2.dhcp.info.ucl.ac.be [130.104.228.16]) (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 3C54C19815B; Wed, 1 Oct 2014 17:59:23 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 3C54C19815B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1412179163; bh=5zCil80zmjRrDiQnMTHJweHQ4OlPC7HHnLEG73OhmsM=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=E6ZkF2T7VnP8BWZh0QDEClPQ3g6LO7ZoMmUadewGRJXGEGsOeO+Z4qZlr76LdK5WS wtg5YB5JGe81rHoGamvSMbSOrfMfGfsVit9jEIrgdaszoZP8PUIrlwP4dQbrlsd3LO DRi9s4f5MC1CYnAQ5iu0/jYVBhaq+1RX+KqidD2c= Message-ID: <542C24DC.8000101@uclouvain.be> Date: Wed, 01 Oct 2014 17:59:24 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , multipathtcp References: <542313F4.40003@uclouvain.be> <5423151C.1020103@isi.edu> In-Reply-To: <5423151C.1020103@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; 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: 3C54C19815B.A1841 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/NMFcZyIStXd2KEpk9p5TnqTdEP8 Subject: [multipathtcp] Multipath TCP options 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, 01 Oct 2014 15:59:31 -0000 Joe, > FWIW, I don't think it's a good idea for MPTCP to use TCP options in a > nonstandard manner. That would severely complicate option implementation. > > IMO, either use the option as it's defined - which may be overkill for > MPTCP - or define a new MPTCP extension for its own optional use of > timestamps. Your suggestion triggers a more fundamental question that we have not yet discussed on this mailing list. Currently, all Multipath TCP options are defined in RFC6824. In the future, it can be expected that new types of options will be proposed. For the sake of discussion, let us consider that we define a new MPTCP timestamp option. Since it was not defined in RFC6824, we could have hosts that support the new timestamp option and hosts that do not support it. How do we "negotiate" the utilisation of this new option on an MPTCP connection. I see three possible ways : - we change the version number of MPTCP so that the new version is RFC6824+timestamp. If this version is negotiated during the initial handshake (note that since we have only defined version 0 of MPTCP, we have not yet fully specified how the negotiation of a version would be done), then timestamp can be used. Otherwise we use only RFC6824 and thus no timestamps on this connection - we keep version 0 of MPTCP, but define a new TCP option that enables the negotiation of the MPTCP timestamp option during the three-way handshake. This would consumme more space in the initial handshake - we keep version 0 of MPTCP and specify that the options that are not defined in RFC6824 could be used in the future, but if a host receives an MPTCP option that it does not understand, it should silently ignore the MPTCP option. The last solution could work for a timestamp option which does not change the semantics of the other MPTCP options. It could provide some extensibility in the protocol without using space in the initial handshake. For example, we could specify that a host should not send more than three MPTCP packets containing the new option if it does not receive the same option from the other host. This would provide a form of late negotiation of the MPTCP options on an MPTCP connection. While updating RFC6824, you should probably spend some time to discuss the extensibility of the base MPTCP specification. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Wed Oct 1 15:26:40 2014 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 923F91A87CC for ; Wed, 1 Oct 2014 15:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 bLA52_43DMTt for ; Wed, 1 Oct 2014 15:26:36 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D045F1A87C2 for ; Wed, 1 Oct 2014 15:26:36 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s91MQN5s011041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Oct 2014 15:26:23 -0700 (PDT) Message-ID: <542C7F91.3030204@isi.edu> Date: Wed, 01 Oct 2014 15:26:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be, multipathtcp References: <542313F4.40003@uclouvain.be> <5423151C.1020103@isi.edu> <542C24DC.8000101@uclouvain.be> In-Reply-To: <542C24DC.8000101@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/Ra8R7jyAzy2Wkv6ht4nDa6FNxR4 Subject: Re: [multipathtcp] Multipath TCP options 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, 01 Oct 2014 22:26:38 -0000 Hi, Oliver, On 10/1/2014 8:59 AM, Olivier Bonaventure wrote: > Joe, > >> FWIW, I don't think it's a good idea for MPTCP to use TCP options in a >> nonstandard manner. That would severely complicate option implementation. >> >> IMO, either use the option as it's defined - which may be overkill for >> MPTCP - or define a new MPTCP extension for its own optional use of >> timestamps. > > Your suggestion triggers a more fundamental question that we have not > yet discussed on this mailing list. Currently, all Multipath TCP options > are defined in RFC6824. Are you referring to options within Multipath TCP? It might be useful to distinguish them more clearly from TCP options - of which Multipath TCP is one. > In the future, it can be expected that new types > of options will be proposed. Of both TCP options and options within the Multipath TCP options, sure. > For the sake of discussion, let us consider that we define a new MPTCP > timestamp option. Since it was not defined in RFC6824, we could have > hosts that support the new timestamp option and hosts that do not > support it. How do we "negotiate" the utilisation of this new option on > an MPTCP connection. I see three possible ways : > > - we change the version number of MPTCP so that the new version is > RFC6824+timestamp. If this version is negotiated during the initial > handshake (note that since we have only defined version 0 of MPTCP, we > have not yet fully specified how the negotiation of a version would be > done), then timestamp can be used. Otherwise we use only RFC6824 and > thus no timestamps on this connection > > - we keep version 0 of MPTCP, but define a new TCP option that enables > the negotiation of the MPTCP timestamp option during the three-way > handshake. This would consumme more space in the initial handshake If you're talking about an option within MPTCP that is negotiated during the MPTCP handshake, sure. If you're proposing a new TCP option KIND value, I disagree (I don't think that's what you meant, but the text reads that way). > - we keep version 0 of MPTCP and specify that the options that are not > defined in RFC6824 could be used in the future, but if a host receives > an MPTCP option that it does not understand, it should silently ignore > the MPTCP option. > > > The last solution could work for a timestamp option which does not > change the semantics of the other MPTCP options. It could provide some > extensibility in the protocol without using space in the initial > handshake. For example, we could specify that a host should not send > more than three MPTCP packets containing the new option if it does not > receive the same option from the other host. This would provide a form > of late negotiation of the MPTCP options on an MPTCP connection. > > While updating RFC6824, you should probably spend some time to discuss > the extensibility of the base MPTCP specification. > > > Olivier > > > From nobody Wed Oct 1 22:27:41 2014 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 1388E1A00AF for ; Wed, 1 Oct 2014 22:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.439 X-Spam-Level: * X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.786, 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 nZTPEnd9QwJe for ; Wed, 1 Oct 2014 22:27:38 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA0C1A00B6 for ; Wed, 1 Oct 2014 22:27:37 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DCA2E2781D6 for ; Thu, 2 Oct 2014 14:27:34 +0900 (JST) Received: by mail-la0-f48.google.com with SMTP id gi9so1667198lab.7 for ; Wed, 01 Oct 2014 22:27:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.45.1 with SMTP id i1mr10414778lam.56.1412227652109; Wed, 01 Oct 2014 22:27:32 -0700 (PDT) Received: by 10.114.98.39 with HTTP; Wed, 1 Oct 2014 22:27:32 -0700 (PDT) In-Reply-To: <542C24DC.8000101@uclouvain.be> References: <542313F4.40003@uclouvain.be> <5423151C.1020103@isi.edu> <542C24DC.8000101@uclouvain.be> Date: Wed, 1 Oct 2014 22:27:32 -0700 Message-ID: From: Yoshifumi Nishida To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=001a11c27c848bcc16050469df26 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/gU6IzutLyUqQBfg7DBw5nJ87FJ0 Cc: multipathtcp Subject: Re: [multipathtcp] Multipath TCP options 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, 02 Oct 2014 05:27:40 -0000 --001a11c27c848bcc16050469df26 Content-Type: text/plain; charset=UTF-8 Hi Olivier, On Wed, Oct 1, 2014 at 8:59 AM, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > Joe, > > FWIW, I don't think it's a good idea for MPTCP to use TCP options in a >> nonstandard manner. That would severely complicate option implementation. >> >> IMO, either use the option as it's defined - which may be overkill for >> MPTCP - or define a new MPTCP extension for its own optional use of >> timestamps. >> > > Your suggestion triggers a more fundamental question that we have not yet > discussed on this mailing list. Currently, all Multipath TCP options are > defined in RFC6824. In the future, it can be expected that new types of > options will be proposed. > > For the sake of discussion, let us consider that we define a new MPTCP > timestamp option. Since it was not defined in RFC6824, we could have hosts > that support the new timestamp option and hosts that do not support it. How > do we "negotiate" the utilisation of this new option on an MPTCP > connection. I see three possible ways : > > - we change the version number of MPTCP so that the new version is > RFC6824+timestamp. If this version is negotiated during the initial > handshake (note that since we have only defined version 0 of MPTCP, we have > not yet fully specified how the negotiation of a version would be done), > then timestamp can be used. Otherwise we use only RFC6824 and thus no > timestamps on this connection > > - we keep version 0 of MPTCP, but define a new TCP option that enables > the negotiation of the MPTCP timestamp option during the three-way > handshake. This would consumme more space in the initial handshake > > - we keep version 0 of MPTCP and specify that the options that are not > defined in RFC6824 could be used in the future, but if a host receives an > MPTCP option that it does not understand, it should silently ignore the > MPTCP option. If we can presume this is similar to the current timestamp options, I personally think the last one is enough. This is because you'll put the timestamp options in some data packets and results will be returned in the options in the ack packets. No new transmission logic will be required for this option exchange as we can utilize normal data and ack exchanges. (I believe there is no need to put timestamp if you don't have data to send or don't receive data) If we don't see the option in the ACK at all, we can presume the option cannot be used for some reason. So, I don't see the needs to change the current semantics for this. In case of other options, we might want to think about other ways such as late negotiation as you mentioned. Thanks, -- Yoshi --001a11c27c848bcc16050469df26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

On Wed, Oct 1, 2014 at 8:59 AM, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:
Joe,

FWIW, I don't think it's a good idea for MPTCP to use TCP options i= n a
nonstandard manner. That would severely complicate option implementation.
IMO, either use the option as it's defined - which may be overkill for<= br> MPTCP - or define a new MPTCP extension for its own optional use of
timestamps.

Your suggestion triggers a more fundamental question that we have not yet d= iscussed on this mailing list. Currently, all Multipath TCP options are def= ined in RFC6824. In the future, it can be expected that new types of option= s will be proposed.

For the sake of discussion, let us consider that we define a new MPTCP time= stamp option. Since it was not defined in RFC6824, we could have hosts that= support the new timestamp option and hosts that do not support it. How do = we "negotiate" the utilisation of this new option on an MPTCP con= nection. I see three possible ways :

=C2=A0- we change the version number of MPTCP so that the new version is RF= C6824+timestamp. If this version is negotiated during the initial handshake= (note that since we have only defined version 0 of MPTCP, we have not yet = fully specified how the negotiation of a version would be done), then times= tamp can be used. Otherwise we use only RFC6824 and thus no timestamps on t= his connection

=C2=A0- we keep version 0 of MPTCP, but define a new TCP option that enable= s the negotiation of the MPTCP timestamp option during the three-way handsh= ake. This would consumme more space in the initial handshake

=C2=A0- we keep version 0 of MPTCP and specify that the options that are no= t defined in RFC6824 could be used in the future, but if a host receives an= MPTCP option that it does not understand, it should silently ignore the MP= TCP option.=C2=A0

If we can presume th= is is similar to the current timestamp options, =C2=A0I personally think th= e last one is enough.=C2=A0
This is because you'll put = the timestamp options in some data packets and results will be returned in = the options in the ack packets.
No new transmission logic will be= required for this option exchange as we can utilize normal data and ack ex= changes.=C2=A0
(I believe there is no need to put timestamp if yo= u don't have data to send or don't receive data)
If we do= n't see the option in the ACK at all, we can presume the option cannot = be used for some reason.=C2=A0
So, I don't see the needs to c= hange the current semantics for this. In case of other options, we might wa= nt to think about other ways such as late negotiation as you mentioned.

Thanks,
--
Yoshi
--001a11c27c848bcc16050469df26-- From nobody Thu Oct 2 00:02:47 2014 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 F40F21A0113 for ; Thu, 2 Oct 2014 00:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 b3VbpFgSHfVv for ; Thu, 2 Oct 2014 00:02:44 -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 3BDD91A010C for ; Thu, 2 Oct 2014 00:02:44 -0700 (PDT) Received: from mbpobo-2.dhcp.info.ucl.ac.be (mbpobo-2.dhcp.info.ucl.ac.be [130.104.228.16]) (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 81C4F1980EA; Thu, 2 Oct 2014 09:02:33 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 81C4F1980EA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1412233353; bh=gbtrUXF5QFWFy3pZOExEZq15ymQChhYV7Ka5d88CM4c=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=U5I5c2+A9bs6qsV9ufnlkYbkxBLlH3hZIWijiZEG8/1hUH5XCcqjco1Rc3Z91j2Pb L6QJd/k6mKGaJWnq//rTRL+FkTbsnopx9O9oFk0xJMugVgBj88mkNyhETuTif7TLEl pj4KeayET6TJH78/z/BiGBJOPt/Uj81f3RWScwSU= Message-ID: <542CF88D.4050200@uclouvain.be> Date: Thu, 02 Oct 2014 09:02:37 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , multipathtcp References: <542313F4.40003@uclouvain.be> <5423151C.1020103@isi.edu> <542C24DC.8000101@uclouvain.be> <542C7F91.3030204@isi.edu> In-Reply-To: <542C7F91.3030204@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; 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: 81C4F1980EA.A1526 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/egDm_xVR65sIGrw3XUeUb0ZXRS4 Subject: Re: [multipathtcp] Multipath TCP options 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, 02 Oct 2014 07:02:46 -0000 Joe, >> >>> FWIW, I don't think it's a good idea for MPTCP to use TCP options in a >>> nonstandard manner. That would severely complicate option implementation. >>> >>> IMO, either use the option as it's defined - which may be overkill for >>> MPTCP - or define a new MPTCP extension for its own optional use of >>> timestamps. >> >> Your suggestion triggers a more fundamental question that we have not >> yet discussed on this mailing list. Currently, all Multipath TCP options >> are defined in RFC6824. > > Are you referring to options within Multipath TCP? It might be useful to > distinguish them more clearly from TCP options - of which Multipath TCP > is one. I'm only referring to MPTCP specific options, i.e. suboptions of TCP option type 30 >> In the future, it can be expected that new types >> of options will be proposed. > > Of both TCP options and options within the Multipath TCP options, sure. > >> For the sake of discussion, let us consider that we define a new MPTCP >> timestamp option. Since it was not defined in RFC6824, we could have >> hosts that support the new timestamp option and hosts that do not >> support it. How do we "negotiate" the utilisation of this new option on >> an MPTCP connection. I see three possible ways : >> >> - we change the version number of MPTCP so that the new version is >> RFC6824+timestamp. If this version is negotiated during the initial >> handshake (note that since we have only defined version 0 of MPTCP, we >> have not yet fully specified how the negotiation of a version would be >> done), then timestamp can be used. Otherwise we use only RFC6824 and >> thus no timestamps on this connection >> >> - we keep version 0 of MPTCP, but define a new TCP option that enables >> the negotiation of the MPTCP timestamp option during the three-way >> handshake. This would consumme more space in the initial handshake > > If you're talking about an option within MPTCP that is negotiated during > the MPTCP handshake, sure. Yes Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Thu Oct 2 00:16:26 2014 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 1D50F1A012D for ; Thu, 2 Oct 2014 00:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9vvpLv5U_PCB for ; Thu, 2 Oct 2014 00:15:42 -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 8F77B1A0107 for ; Thu, 2 Oct 2014 00:15:42 -0700 (PDT) Received: from mbpobo-2.dhcp.info.ucl.ac.be (mbpobo-2.dhcp.info.ucl.ac.be [130.104.228.16]) (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 075651980E4; Thu, 2 Oct 2014 09:15:31 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 075651980E4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1412234131; bh=PpiAsiO6gpfdB/yxUWcTuAGr14EVkTKLGlw4RbF66gI=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ApwtGL23J9p6c8gTnboR/Rlr0vP5echSVmYw95sKqK506ep0sAf2/5oMEDKQlko/S cpHx6aAtvxqawXLwO+InFkCk8joPnkg+7Nsxp9+j35FOlQ2bqXu5flth4jn8x+CFWX Amlrtpk81kVSv4j1ZIqNzcc1e6jP1I8XesA+QJdU= Message-ID: <542CFB96.4080401@uclouvain.be> Date: Thu, 02 Oct 2014 09:15:34 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <542313F4.40003@uclouvain.be> <5423151C.1020103@isi.edu> <542C24DC.8000101@uclouvain.be> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: 075651980E4.A34A6 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/1DNxr5N5cp_LZBso2Dleu0uRvCs Cc: multipathtcp Subject: Re: [multipathtcp] Multipath TCP options 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, 02 Oct 2014 07:15:54 -0000 X-List-Received-Date: Thu, 02 Oct 2014 07:15:54 -0000 Yoshifumi, > > Your suggestion triggers a more fundamental question that we have > not yet discussed on this mailing list. Currently, all Multipath TCP > options are defined in RFC6824. In the future, it can be expected > that new types of options will be proposed. > > For the sake of discussion, let us consider that we define a new > MPTCP timestamp option. Since it was not defined in RFC6824, we > could have hosts that support the new timestamp option and hosts > that do not support it. How do we "negotiate" the utilisation of > this new option on an MPTCP connection. I see three possible ways : > > - we change the version number of MPTCP so that the new version is > RFC6824+timestamp. If this version is negotiated during the initial > handshake (note that since we have only defined version 0 of MPTCP, > we have not yet fully specified how the negotiation of a version > would be done), then timestamp can be used. Otherwise we use only > RFC6824 and thus no timestamps on this connection > > - we keep version 0 of MPTCP, but define a new TCP option that > enables the negotiation of the MPTCP timestamp option during the > three-way handshake. This would consumme more space in the initial > handshake > > - we keep version 0 of MPTCP and specify that the options that are > not defined in RFC6824 could be used in the future, but if a host > receives an MPTCP option that it does not understand, it should > silently ignore the MPTCP option. > > > If we can presume this is similar to the current timestamp options, I > personally think the last one is enough. > This is because you'll put the timestamp options in some data packets > and results will be returned in the options in the ack packets. > No new transmission logic will be required for this option exchange as > we can utilize normal data and ack exchanges. > (I believe there is no need to put timestamp if you don't have data to > send or don't receive data) > If we don't see the option in the ACK at all, we can presume the option > cannot be used for some reason. > So, I don't see the needs to change the current semantics for this. In > case of other options, we might want to think about other ways such as > late negotiation as you mentioned. A timestamp MPTCP option would be purely informational. If it does not get through, the data transfer is not affected. If we invent something like window scale, then the data transfer could be affected and we would need to take care. I would suggest to at least plan for future MPTCP options in RFC6824bis with a note to developers which could read : This document defines the semantics and the processing of the following Multipath TCP options : +-------+--------------+----------------------------+---------------+ | Value | Symbol | Name | Reference | +-------+--------------+----------------------------+---------------+ | 0x0 | MP_CAPABLE | Multipath Capable | Section 3.1 | | 0x1 | MP_JOIN | Join Connection | Section 3.2 | | 0x2 | DSS | Data Sequence Signal (Data | Section 3.3 | | | | ACK and data sequence | | | | | mapping) | | | 0x3 | ADD_ADDR | Add Address | Section 3.4.1 | | 0x4 | REMOVE_ADDR | Remove Address | Section 3.4.2 | | 0x5 | MP_PRIO | Change Subflow Priority | Section 3.3.8 | | 0x6 | MP_FAIL | Fallback | Section 3.6 | | 0x7 | MP_FASTCLOSE | Fast Close | Section 3.5 | +-------+--------------+----------------------------+---------------+ Table 2: MPTCP Option Subtypes Values 0x8 through 0xe are currently unassigned. The value 0xf is reserved for Private Use within controlled testbeds. Extensions to this specification might define new MPTCP option subtypes. An implementation that receives an unknown MPTCP option in any segment SHOULD silently ignore this MPTCP option and continue to process the segment. If we do not clarify the handling of these unknown MPTCP options, we might end up in a situation where some MPTCP implementations (or worse MPTCP aware middlebxes) drop segments that contain an unknown MPTCP option, or worse close MPTCP connections where an unknown MPTCP option has been received. We probably also need to think whether we need to change the version of MPTCP if we change the semantics of one of the defined options. There is already an interesting use case with the ADD_ADDR option. In RFC6824, this MPTCP option is defined as 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 | Length |Subtype| IPVer | Address ID | +---------------+---------------+-------+-------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+-------------------------------+ | Port (2 octets, optional) | +-------------------------------+ Figure 12: Add Address (ADD_ADDR) Option while RFC6824bis adds a HMAC : 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 | Length |Subtype| IPVer | Address ID | +---------------+---------------+-------+-------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+-------------------------------+ | Port (2 octets, optional) | | +-------------------------------+ | | Truncated HMAC (8 octets) | | +-------------------------------+ | | +-------------------------------+ The two can be easily distinguished by looking at the length field. However, consider a host that implements exactly RFC6824. How should it react to the reception of an ADD_ADDR option in the RFC6824bis format ? Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Thu Oct 2 21:26:51 2014 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 98F031ACFDB for ; Thu, 2 Oct 2014 21:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.439 X-Spam-Level: * X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.786, 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 EFN7HgMSDpR2 for ; Thu, 2 Oct 2014 21:26:47 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE30F1A0067 for ; Thu, 2 Oct 2014 21:26:46 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 68C5529C004 for ; Fri, 3 Oct 2014 13:26:44 +0900 (JST) Received: by mail-lb0-f180.google.com with SMTP id f15so353879lbj.25 for ; Thu, 02 Oct 2014 21:26:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.148.170 with SMTP id tt10mr2686193lbb.61.1412310401608; Thu, 02 Oct 2014 21:26:41 -0700 (PDT) Received: by 10.114.98.39 with HTTP; Thu, 2 Oct 2014 21:26:41 -0700 (PDT) In-Reply-To: <542CFB96.4080401@uclouvain.be> References: <542313F4.40003@uclouvain.be> <5423151C.1020103@isi.edu> <542C24DC.8000101@uclouvain.be> <542CFB96.4080401@uclouvain.be> Date: Thu, 2 Oct 2014 21:26:41 -0700 Message-ID: From: Yoshifumi Nishida To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=047d7b3a7d8eccf26c05047d2373 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/3EC75p4FpbHZ91-vVhG2dvWmYzQ Cc: multipathtcp Subject: Re: [multipathtcp] Multipath TCP options 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, 03 Oct 2014 04:26:49 -0000 --047d7b3a7d8eccf26c05047d2373 Content-Type: text/plain; charset=UTF-8 Hi Olivier, On Thu, Oct 2, 2014 at 12:15 AM, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > Yoshifumi, > > >> Your suggestion triggers a more fundamental question that we have >> not yet discussed on this mailing list. Currently, all Multipath TCP >> options are defined in RFC6824. In the future, it can be expected >> that new types of options will be proposed. >> >> For the sake of discussion, let us consider that we define a new >> MPTCP timestamp option. Since it was not defined in RFC6824, we >> could have hosts that support the new timestamp option and hosts >> that do not support it. How do we "negotiate" the utilisation of >> this new option on an MPTCP connection. I see three possible ways : >> >> - we change the version number of MPTCP so that the new version is >> RFC6824+timestamp. If this version is negotiated during the initial >> handshake (note that since we have only defined version 0 of MPTCP, >> we have not yet fully specified how the negotiation of a version >> would be done), then timestamp can be used. Otherwise we use only >> RFC6824 and thus no timestamps on this connection >> >> - we keep version 0 of MPTCP, but define a new TCP option that >> enables the negotiation of the MPTCP timestamp option during the >> three-way handshake. This would consumme more space in the initial >> handshake >> >> - we keep version 0 of MPTCP and specify that the options that are >> not defined in RFC6824 could be used in the future, but if a host >> receives an MPTCP option that it does not understand, it should >> silently ignore the MPTCP option. >> >> >> If we can presume this is similar to the current timestamp options, I >> personally think the last one is enough. >> This is because you'll put the timestamp options in some data packets >> and results will be returned in the options in the ack packets. >> No new transmission logic will be required for this option exchange as >> we can utilize normal data and ack exchanges. >> (I believe there is no need to put timestamp if you don't have data to >> send or don't receive data) >> If we don't see the option in the ACK at all, we can presume the option >> cannot be used for some reason. >> So, I don't see the needs to change the current semantics for this. In >> case of other options, we might want to think about other ways such as >> late negotiation as you mentioned. >> > > A timestamp MPTCP option would be purely informational. If it does not get > through, the data transfer is not affected. If we invent something like > window scale, then the data transfer could be affected and we would need to > take care. > > I would suggest to at least plan for future MPTCP options in RFC6824bis > with a note to developers which could read : > > This document defines the semantics and the processing of the following > Multipath TCP options : > > +-------+--------------+----------------------------+---------------+ > | Value | Symbol | Name | Reference | > +-------+--------------+----------------------------+---------------+ > | 0x0 | MP_CAPABLE | Multipath Capable | Section 3.1 | > | 0x1 | MP_JOIN | Join Connection | Section 3.2 | > | 0x2 | DSS | Data Sequence Signal (Data | Section 3.3 | > | | | ACK and data sequence | | > | | | mapping) | | > | 0x3 | ADD_ADDR | Add Address | Section 3.4.1 | > | 0x4 | REMOVE_ADDR | Remove Address | Section 3.4.2 | > | 0x5 | MP_PRIO | Change Subflow Priority | Section 3.3.8 | > | 0x6 | MP_FAIL | Fallback | Section 3.6 | > | 0x7 | MP_FASTCLOSE | Fast Close | Section 3.5 | > +-------+--------------+----------------------------+---------------+ > > Table 2: MPTCP Option Subtypes > > Values 0x8 through 0xe are currently unassigned. The value 0xf is > reserved for Private Use within controlled testbeds. Extensions to this > specification might define new MPTCP option subtypes. An implementation > that receives an unknown MPTCP option in any segment SHOULD silently ignore > this MPTCP option and continue to process the segment. > > > If we do not clarify the handling of these unknown MPTCP options, we might > end up in a situation where some MPTCP implementations (or worse MPTCP > aware middlebxes) drop segments that contain an unknown MPTCP option, or > worse close MPTCP connections where an unknown MPTCP option has been > received. > > We probably also need to think whether we need to change the version of > MPTCP if we change the semantics of one of the defined options. There is > already an interesting use case with the ADD_ADDR option. > > In RFC6824, this MPTCP option is defined as > > 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 | Length |Subtype| IPVer | Address ID | > +---------------+---------------+-------+-------+---------------+ > | Address (IPv4 - 4 octets / IPv6 - 16 octets) | > +-------------------------------+-------------------------------+ > | Port (2 octets, optional) | > +-------------------------------+ > > Figure 12: Add Address (ADD_ADDR) Option > > > while RFC6824bis adds a HMAC : > > 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 | Length |Subtype| IPVer | Address ID | > +---------------+---------------+-------+-------+---------------+ > | Address (IPv4 - 4 octets / IPv6 - 16 octets) | > +-------------------------------+-------------------------------+ > | Port (2 octets, optional) | | > +-------------------------------+ | > | Truncated HMAC (8 octets) | > | +-------------------------------+ > | | > +-------------------------------+ > > > The two can be easily distinguished by looking at the length field. > However, consider a host that implements exactly RFC6824. How should it > react to the reception of an ADD_ADDR option in the RFC6824bis format ? I think the new add addr message will be ADD_ADDR2, so I believe that strict 6824 implementations will discard the options when they see them. But, as far as I've checked, I couldn't find the sentence in RFC6824 that states unknown subtype option must be ignored. Maybe we'd better add this kind of sentences in the bis draft. Also, the bis draft should mention the behavior when they receives old ADD_ADDR messages. Like ADD_ADDR case, I think changing subtype can be an option to change the semantics, while we might need to worry about available subtypes. OTOH, I'm thinking that if we will have options like window-scale which requires tight synchronizations between both ends, we might need to think about something which leads to changing version number. Thanks, -- Yoshi --047d7b3a7d8eccf26c05047d2373 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

On Thu, Oct 2, 2014 at 12:15 AM, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:
Yoshifumi,


=C2=A0 =C2=A0 Your suggestion triggers a more fundamental question that we = have
=C2=A0 =C2=A0 not yet discussed on this mailing list. Currently, all Multip= ath TCP
=C2=A0 =C2=A0 options are defined in RFC6824. In the future, it can be expe= cted
=C2=A0 =C2=A0 that new types of options will be proposed.

=C2=A0 =C2=A0 For the sake of discussion, let us consider that we define a = new
=C2=A0 =C2=A0 MPTCP timestamp option. Since it was not defined in RFC6824, = we
=C2=A0 =C2=A0 could have hosts that support the new timestamp option and ho= sts
=C2=A0 =C2=A0 that do not support it. How do we "negotiate" the u= tilisation of
=C2=A0 =C2=A0 this new option on an MPTCP connection. I see three possible = ways :

=C2=A0 =C2=A0 =C2=A0 - we change the version number of MPTCP so that the ne= w version is
=C2=A0 =C2=A0 RFC6824+timestamp. If this version is negotiated during the i= nitial
=C2=A0 =C2=A0 handshake (note that since we have only defined version 0 of = MPTCP,
=C2=A0 =C2=A0 we have not yet fully specified how the negotiation of a vers= ion
=C2=A0 =C2=A0 would be done), then timestamp can be used. Otherwise we use = only
=C2=A0 =C2=A0 RFC6824 and thus no timestamps on this connection

=C2=A0 =C2=A0 =C2=A0 - we keep version 0 of MPTCP, but define a new TCP opt= ion that
=C2=A0 =C2=A0 enables the negotiation of the MPTCP timestamp option during = the
=C2=A0 =C2=A0 three-way handshake. This would consumme more space in the in= itial
=C2=A0 =C2=A0 handshake

=C2=A0 =C2=A0 =C2=A0 - we keep version 0 of MPTCP and specify that the opti= ons that are
=C2=A0 =C2=A0 not defined in RFC6824 could be used in the future, but if a = host
=C2=A0 =C2=A0 receives an MPTCP option that it does not understand, it shou= ld
=C2=A0 =C2=A0 silently ignore the MPTCP option.


If we can presume this is similar to the current timestamp options,=C2=A0 I=
personally think the last one is enough.
This is because you'll put the timestamp options in some data packets and results will be returned in the options in the ack packets.
No new transmission logic will be required for this option exchange as
we can utilize normal data and ack exchanges.
(I believe there is no need to put timestamp if you don't have data to<= br> send or don't receive data)
If we don't see the option in the ACK at all, we can presume the option=
cannot be used for some reason.
So, I don't see the needs to change the current semantics for this. In<= br> case of other options, we might want to think about other ways such as
late negotiation as you mentioned.

A timestamp MPTCP option would be purely informational. If it does not get = through, the data transfer is not affected. If we invent something like win= dow scale, then the data transfer could be affected and we would need to ta= ke care.

I would suggest to at least plan for future MPTCP options in RFC6824bis wit= h a note to developers which could read :

This document defines the semantics and the processing of the following Mul= tipath TCP options :

=C2=A0 =C2=A0+-------+--------------+----------------------------+--= -------------+
=C2=A0 =C2=A0| Value |=C2=A0 =C2=A0 Symbol=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0Reference=C2=A0 =C2=A0|
=C2=A0 =C2=A0+-------+--------------+----------------------------+--= -------------+
=C2=A0 =C2=A0|=C2=A0 0x0=C2=A0 |=C2=A0 MP_CAPABLE=C2=A0 |=C2=A0 =C2=A0 =C2= =A0 Multipath Capable=C2=A0 =C2=A0 =C2=A0|=C2=A0 Section 3.1=C2=A0 |
=C2=A0 =C2=A0|=C2=A0 0x1=C2=A0 |=C2=A0 =C2=A0 MP_JOIN=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0Join Connection=C2=A0 =C2=A0 =C2=A0 |=C2=A0 Section 3.2= =C2=A0 |
=C2=A0 =C2=A0|=C2=A0 0x2=C2=A0 |=C2=A0 =C2=A0 =C2=A0 DSS=C2=A0 =C2=A0 =C2= =A0| Data Sequence Signal (Data |=C2=A0 Section 3.3=C2=A0 |
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 ACK and data sequence=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping)=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0|=C2=A0 0x3=C2=A0 |=C2=A0 =C2=A0ADD_ADDR=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Add Address=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Section= 3.4.1 |
=C2=A0 =C2=A0|=C2=A0 0x4=C2=A0 |=C2=A0 REMOVE_ADDR |=C2=A0 =C2=A0 =C2=A0 = =C2=A0Remove Address=C2=A0 =C2=A0 =C2=A0 =C2=A0| Section 3.4.2 |
=C2=A0 =C2=A0|=C2=A0 0x5=C2=A0 |=C2=A0 =C2=A0 MP_PRIO=C2=A0 =C2=A0|=C2=A0 = =C2=A0Change Subflow Priority=C2=A0 | Section 3.3.8 |
=C2=A0 =C2=A0|=C2=A0 0x6=C2=A0 |=C2=A0 =C2=A0 MP_FAIL=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fallback=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 Section 3.6=C2=A0 |
=C2=A0 =C2=A0|=C2=A0 0x7=C2=A0 | MP_FASTCLOSE |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Fast Close=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 Section 3.5=C2=A0= |
=C2=A0 =C2=A0+-------+--------------+----------------------------+--= -------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Table 2: MPTCP Option Subtypes

=C2=A0 =C2=A0Values 0x8 through 0xe are currently unassigned.=C2=A0 The val= ue 0xf is
=C2=A0 =C2=A0reserved for Private Use within controlled testbeds. Extension= s to this specification might define new MPTCP option subtypes. An implemen= tation that receives an unknown MPTCP option in any segment SHOULD silently= ignore this MPTCP option and continue to process the segment.


If we do not clarify the handling of these unknown MPTCP options, we might = end up in a situation where some MPTCP implementations (or worse MPTCP awar= e middlebxes) drop segments that contain an unknown MPTCP option, or worse = close MPTCP connections where an unknown MPTCP option has been received.
We probably also need to think whether we need to change the version of MPT= CP if we change the semantics of one of the defined options. There is alrea= dy an interesting use case with the ADD_ADDR option.

In RFC6824, this MPTCP option is defined as

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 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
=C2=A0 =C2=A0 =C2=A0 +---------------+---------------+-------+------= -+---------------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0Kind=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0Length=C2=A0 =C2=A0 |Subtype| IPVer |=C2=A0 Address ID=C2=A0 = =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +---------------+---------------+-------+------= -+---------------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address (IPv4 - 4 = octets / IPv6 - 16 octets)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-------------------------------+--------------= -----------------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Port (2 octets, optional)=C2=A0 =C2=A0|<= br> =C2=A0 =C2=A0 =C2=A0 +-------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 12: Ad= d Address (ADD_ADDR) Option


while RFC6824bis adds a HMAC :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 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
=C2=A0 =C2=A0 =C2=A0 +---------------+---------------+-------+------= -+---------------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0Kind=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0Length=C2=A0 =C2=A0 |Subtype| IPVer |=C2=A0 Address ID=C2=A0 = =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +---------------+---------------+-------+------= -+---------------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address (IPv4 - 4 = octets / IPv6 - 16 octets)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-------------------------------+--------------= -----------------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Port (2 octets, optional)=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-------------------------------+=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Truncated HMAC (8 octets)=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------= ----------------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-------------------------------+


The two can be easily distinguished by looking at the length field. However= , consider a host that implements exactly RFC6824. How should it react to t= he reception of an ADD_ADDR option in the RFC6824bis format ?<= div>
I think the new add addr message will be ADD_ADDR2, so I= believe that strict 6824 implementations will discard the options when the= y see them. But, as far as I've checked, I couldn't find the senten= ce in RFC6824 that states unknown subtype option must be ignored. Maybe we&= #39;d better add this kind of sentences in the bis draft. Also, the bis dra= ft should mention the behavior when they receives old ADD_ADDR messages.

Like ADD_ADDR case, I think changing subtype can be = an option to change the semantics, while we might need to worry about avail= able subtypes.
OTOH, I'm thinking that if we will have option= s like window-scale which requires tight synchronizations between both ends= , we might need to think about something which leads to changing version nu= mber.

Thanks,
--
Yoshi



--047d7b3a7d8eccf26c05047d2373-- From nobody Tue Oct 7 10:57:14 2014 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 611301A8713 for ; Tue, 7 Oct 2014 10:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.338 X-Spam-Level: *** X-Spam-Status: No, score=3.338 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.786, 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 tqHlNb3m7CtM for ; Tue, 7 Oct 2014 10:57:09 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BD51A8711 for ; Tue, 7 Oct 2014 10:57:09 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1D6B42781CD for ; Wed, 8 Oct 2014 02:57:06 +0900 (JST) Received: by mail-lb0-f181.google.com with SMTP id l4so6691475lbv.12 for ; Tue, 07 Oct 2014 10:57:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.4.98 with SMTP id j2mr5793183laj.77.1412704623786; Tue, 07 Oct 2014 10:57:03 -0700 (PDT) Received: by 10.114.98.39 with HTTP; Tue, 7 Oct 2014 10:57:03 -0700 (PDT) Date: Tue, 7 Oct 2014 10:57:03 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=089e0141ab444605c50504d8edb3 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/Ph3-x5l4Gl5AsWDOP66wb6xG3i0 Subject: [multipathtcp] FW: [tcpinc] Protect or not the TCP header fields 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, 07 Oct 2014 17:57:11 -0000 --089e0141ab444605c50504d8edb3 Content-Type: text/plain; charset=UTF-8 I guess many folks in the WG already know this, but just in case.. In tcpinc WG, they start making a design choice on which parts of tcp segment should be protected. http://www.ietf.org/mail-archive/web/tcpinc/current/msg00359.html I'm personally wondering if this design decision can have some impacts on securing mptcp. According to the previous discussions, it seems to me that we might want to utilize outcomes from the tcpinc WG for this. If tcpinc focuses on only protecting payload, I'm wondering if we can still utilize their outcomes for mptcp. It would be great if someone could provide some thoughts on this. Thanks, -- Yoshi --089e0141ab444605c50504d8edb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess many folks in the WG already know this, but just i= n case..

In tcpinc WG, they start making a design choice= on which parts of tcp segment should be protected.

http://www.ietf.org/mail-archive/web/tcpinc/current/msg00359.html<= br>

I'm personally wondering if this design de= cision can have some impacts on securing mptcp.
According to the = previous discussions, it seems to me that we might want to utilize outcomes= from the tcpinc WG for this.=C2=A0
If tcpinc focuses on only pro= tecting payload, I'm wondering if we can still utilize their outcomes f= or mptcp.
It would be great if someone could provide some thought= s on this.

Thanks,
--
Yoshi


--089e0141ab444605c50504d8edb3-- From nobody Tue Oct 7 11:20:52 2014 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 4C0D81A86F6 for ; Tue, 7 Oct 2014 11:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 WGH3b13iMJKx for ; Tue, 7 Oct 2014 11:20:45 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 924A81A8549 for ; Tue, 7 Oct 2014 11:20:26 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id BF3AFFA9342EA; Tue, 7 Oct 2014 18:20:20 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s97IKMfX012516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Oct 2014 20:20:23 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 20:20:22 +0200 From: "Scharf, Michael (Michael)" To: Yoshifumi Nishida , multipathtcp Thread-Topic: [multipathtcp] FW: [tcpinc] Protect or not the TCP header fields Thread-Index: AQHP4lgjGsHfDTw+rkyD5aaC3yLBTJwk8Cow Date: Tue, 7 Oct 2014 18:20:21 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1665E9F0@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D1665E9F0FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/L7PLXGjyegDmwzBj7X08BUt1jkQ Subject: Re: [multipathtcp] FW: [tcpinc] Protect or not the TCP header fields 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, 07 Oct 2014 18:20:49 -0000 --_000_655C07320163294895BBADA28372AF5D1665E9F0FR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBtb3JlIHNwZWNpZmljIHF1ZXN0aW9uIHJlbGF0ZWQgdG8gdGhpcyAtIHNvcnJ5LCBJ4oCZdmUg bm90IGZvbGxvd2VkIHRoZSBwYXN0IE1QVENQIGRpc2N1c3Npb24gaW4gZGV0YWlsOiAgV291bGQg TVBUQ1Agd2FudCB0byB1c2UgYSB0Y3BpbmMgVENQIGhlYWRlciBwcm90ZWN0aW9uIChpZiB0aGF0 IHdhcyBwYXJ0IG9mIHRjcGluYyksIGJ1dCBhdm9pZCBhIHRjcGluYyBwYXlsb2FkIGVuY3J5cHRp b24/DQoNCldvdWxkIHRoZXJlIGJlIGEgdXNlIGNhc2UgZm9yIHRoaXM/DQoNCk1pY2hhZWwNCg0K DQpGcm9tOiBtdWx0aXBhdGh0Y3AgW21haWx0bzptdWx0aXBhdGh0Y3AtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFlvc2hpZnVtaSBOaXNoaWRhDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVy IDA3LCAyMDE0IDc6NTcgUE0NClRvOiBtdWx0aXBhdGh0Y3ANClN1YmplY3Q6IFttdWx0aXBhdGh0 Y3BdIEZXOiBbdGNwaW5jXSBQcm90ZWN0IG9yIG5vdCB0aGUgVENQIGhlYWRlciBmaWVsZHMNCg0K SSBndWVzcyBtYW55IGZvbGtzIGluIHRoZSBXRyBhbHJlYWR5IGtub3cgdGhpcywgYnV0IGp1c3Qg aW4gY2FzZS4uDQoNCkluIHRjcGluYyBXRywgdGhleSBzdGFydCBtYWtpbmcgYSBkZXNpZ24gY2hv aWNlIG9uIHdoaWNoIHBhcnRzIG9mIHRjcCBzZWdtZW50IHNob3VsZCBiZSBwcm90ZWN0ZWQuDQoN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90Y3BpbmMvY3VycmVudC9tc2cw MDM1OS5odG1sDQoNCkknbSBwZXJzb25hbGx5IHdvbmRlcmluZyBpZiB0aGlzIGRlc2lnbiBkZWNp c2lvbiBjYW4gaGF2ZSBzb21lIGltcGFjdHMgb24gc2VjdXJpbmcgbXB0Y3AuDQpBY2NvcmRpbmcg dG8gdGhlIHByZXZpb3VzIGRpc2N1c3Npb25zLCBpdCBzZWVtcyB0byBtZSB0aGF0IHdlIG1pZ2h0 IHdhbnQgdG8gdXRpbGl6ZSBvdXRjb21lcyBmcm9tIHRoZSB0Y3BpbmMgV0cgZm9yIHRoaXMuDQpJ ZiB0Y3BpbmMgZm9jdXNlcyBvbiBvbmx5IHByb3RlY3RpbmcgcGF5bG9hZCwgSSdtIHdvbmRlcmlu ZyBpZiB3ZSBjYW4gc3RpbGwgdXRpbGl6ZSB0aGVpciBvdXRjb21lcyBmb3IgbXB0Y3AuDQpJdCB3 b3VsZCBiZSBncmVhdCBpZiBzb21lb25lIGNvdWxkIHByb3ZpZGUgc29tZSB0aG91Z2h0cyBvbiB0 aGlzLg0KDQpUaGFua3MsDQotLQ0KWW9zaGkNCg0KDQo= --_000_655C07320163294895BBADA28372AF5D1665E9F0FR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RS1NYWlsRm9ybWF0dm9ybGFnZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgbW9yZSBz cGVjaWZpYyBxdWVzdGlvbiByZWxhdGVkIHRvIHRoaXMgLSBzb3JyeSwgSeKAmXZlIG5vdCBmb2xs b3dlZCB0aGUgcGFzdCBNUFRDUCBkaXNjdXNzaW9uIGluIGRldGFpbDombmJzcDsgV291bGQgTVBU Q1Agd2FudCB0byB1c2UgYSB0Y3BpbmMgVENQDQogaGVhZGVyIDxiPnByb3RlY3Rpb248L2I+IChp ZiB0aGF0IHdhcyBwYXJ0IG9mIHRjcGluYyksIGJ1dCBhdm9pZCBhIHRjcGluYyBwYXlsb2FkDQo8 Yj5lbmNyeXB0aW9uPC9iPj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V291 bGQgdGhlcmUgYmUgYSB1c2UgY2FzZSBmb3IgdGhpcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG11bHRpcGF0aHRjcCBbbWFp bHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Z b3NoaWZ1bWkgTmlzaGlkYTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MDcsIDIwMTQgNzo1NyBQTTxicj4NCjxiPlRv OjwvYj4gbXVsdGlwYXRodGNwPGJyPg0KPGI+U3ViamVjdDo8L2I+IFttdWx0aXBhdGh0Y3BdIEZX OiBbdGNwaW5jXSBQcm90ZWN0IG9yIG5vdCB0aGUgVENQIGhlYWRlciBmaWVsZHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBndWVzcyBtYW55 IGZvbGtzIGluIHRoZSBXRyBhbHJlYWR5IGtub3cgdGhpcywgYnV0IGp1c3QgaW4gY2FzZS4uPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0Y3BpbmMgV0cs IHRoZXkgc3RhcnQgbWFraW5nIGEgZGVzaWduIGNob2ljZSBvbiB3aGljaCBwYXJ0cyBvZiB0Y3Ag c2VnbWVudCBzaG91bGQgYmUgcHJvdGVjdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvdGNwaW5jL2N1cnJlbnQvbXNnMDAzNTkuaHRtbCI+aHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3RjcGluYy9jdXJyZW50L21zZzAwMzU5Lmh0bWw8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkn bSBwZXJzb25hbGx5IHdvbmRlcmluZyBpZiB0aGlzIGRlc2lnbiBkZWNpc2lvbiBjYW4gaGF2ZSBz b21lIGltcGFjdHMgb24gc2VjdXJpbmcgbXB0Y3AuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY2NvcmRpbmcgdG8gdGhlIHByZXZpb3VzIGRpc2N1 c3Npb25zLCBpdCBzZWVtcyB0byBtZSB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gdXRpbGl6ZSBvdXRj b21lcyBmcm9tIHRoZSB0Y3BpbmMgV0cgZm9yIHRoaXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0Y3BpbmMgZm9jdXNlcyBvbiBv bmx5IHByb3RlY3RpbmcgcGF5bG9hZCwgSSdtIHdvbmRlcmluZyBpZiB3ZSBjYW4gc3RpbGwgdXRp bGl6ZSB0aGVpciBvdXRjb21lcyBmb3IgbXB0Y3AuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBiZSBncmVhdCBpZiBzb21lb25lIGNv dWxkIHByb3ZpZGUgc29tZSB0aG91Z2h0cyBvbiB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW9zaGk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_655C07320163294895BBADA28372AF5D1665E9F0FR712WXCHMBA15z_-- From nobody Sat Oct 11 12:37:42 2014 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 66FC01A037C for ; Sat, 11 Oct 2014 05:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.688 X-Spam-Level: X-Spam-Status: No, score=-107.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 OM4pDb_kaYhC for ; Sat, 11 Oct 2014 05:00:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0135C1A00E0 for ; Sat, 11 Oct 2014 05:00:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A3B14181C7D; Sat, 11 Oct 2014 04:59:53 -0700 (PDT) To: alanford@cisco.com, costin.raiciu@cs.pub.ro, m.handley@cs.ucl.ac.uk, olivier.bonaventure@uclouvain.be, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, philip.eardley@bt.com, nishida@sfc.wide.ad.jp X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141011115953.A3B14181C7D@rfc-editor.org> Date: Sat, 11 Oct 2014 04:59:53 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/2_KXQJw_lmEuVHI5pBh_dVCbobI X-Mailman-Approved-At: Sat, 11 Oct 2014 12:37:40 -0700 Cc: friedrich@haussmann.tel, multipathtcp@ietf.org, rfc-editor@rfc-editor.org Subject: [multipathtcp] [Technical Errata Reported] RFC6824 (4129) 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: Sat, 11 Oct 2014 12:00:52 -0000 The following errata report has been submitted for RFC6824, "TCP Extensions for Multipath Operation with Multiple Addresses". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6824&eid=4129 -------------------------------------- Type: Technical Reported by: Friedrich Haussmann Section: B.1.1. Original Text ------------- MPTCP.Checksum (flag): This flag is set to true if at least one of the hosts has set the C bit in the MP_CAPABLE options exchanged during connection establishment, and is set to false otherwise. If this flag is set, the checksum must be computed in all DSS options. Corrected Text -------------- MPTCP.Checksum (flag): This flag is set to true if at least one of the hosts has set the A bit in the MP_CAPABLE options exchanged during connection establishment, and is set to false otherwise. If this flag is set, the checksum must be computed in all DSS options. Notes ----- Checksum is not on bit "C", but instead on bit "A". There are no other instances of referring on bit "C" as the checksum. Bit "C" is unassigned in this version. Other instances of bit "A" as checksum: * Section 3.1. Connection Initiation, p. 16 f. * Section 8. IANA Considerations, Table 3: MPTCP Handshake Algorithms, p. 56 Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6824 (draft-ietf-mptcp-multiaddressed-12) -------------------------------------- Title : TCP Extensions for Multipath Operation with Multiple Addresses Publication Date : January 2013 Author(s) : A. Ford, C. Raiciu, M. Handley, O. Bonaventure Category : EXPERIMENTAL Source : Multipath TCP Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Oct 13 00:10:55 2014 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 33C4E1A88B7 for ; Mon, 13 Oct 2014 00:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.344 X-Spam-Level: ** X-Spam-Status: No, score=2.344 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, 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 BnPN71Lovdgt for ; Mon, 13 Oct 2014 00:10:46 -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 4A0041A88B4 for ; Mon, 13 Oct 2014 00:10:45 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6309A278153 for ; Mon, 13 Oct 2014 16:10:43 +0900 (JST) Received: by mail-wi0-f173.google.com with SMTP id fb4so6530259wid.6 for ; Mon, 13 Oct 2014 00:10:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.198.112 with SMTP id jb16mr18288824wic.10.1413184240820; Mon, 13 Oct 2014 00:10:40 -0700 (PDT) Received: by 10.194.3.82 with HTTP; Mon, 13 Oct 2014 00:10:40 -0700 (PDT) Date: Mon, 13 Oct 2014 00:10:40 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=047d7b622036ad27f905054898a2 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/AZCpp170A_04F-kIA2qKU0HhrJA Subject: [multipathtcp] hawaii 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: Mon, 13 Oct 2014 07:10:51 -0000 --047d7b622036ad27f905054898a2 Content-Type: text/plain; charset=UTF-8 Hi, there are some discussions between chairs and AD whether we will have a meeting in Hawaii as we feel that not so many folks have a plan to go there, but in the end, we got a 1.5 hour meeting slot at 11:50-13:20 Friday, November 14. Although this might not be the best opportunity as we might not have enough people, it may be utilized to share some (even pre-matured) ideas or exchange some info or build networks. If you're interested in presenting something or you have some suggestions for the agenda, please let us know. OTOH, if there's little interest for the slot, we will think about returning the slot. Regards, -- Yoshi & Phil --047d7b622036ad27f905054898a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
there are some discussions betwee= n chairs and AD whether we will have a meeting in Hawaii as we feel that no= t so many folks have a plan to go there, but in the end, we got a 1.5 hour = meeting slot at 11:50-13:20 Friday, November 14.

A= lthough this might not be the best opportunity as we might not have enough = people, it may be utilized to share some (even pre-matured) ideas or exchan= ge some info or build networks.
If you're interested in prese= nting something or you have some suggestions for the agenda, please let us = know.

OTOH, if there's little interest for the= slot, we will think about returning the slot.

Reg= ards,
--
Yoshi & Phil

--047d7b622036ad27f905054898a2-- From nobody Mon Oct 13 14:03:25 2014 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 2D94E1A00A6; Mon, 13 Oct 2014 14:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 7TfD1yCOwoRx; Mon, 13 Oct 2014 14:03:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C0A1A008C; Mon, 13 Oct 2014 14:03:16 -0700 (PDT) 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: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141013210316.11630.2065.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 14:03:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/7z0aSn9wqj5UmzjKa9H9oRJ0EOo Cc: multipathtcp@ietf.org Subject: [multipathtcp] Last Call: (Analysis of MPTCP residual threats and possible fixes) to Informational RFC X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:03:18 -0000 The IESG has received a request from the Multipath TCP WG (mptcp) to consider the following document: - 'Analysis of MPTCP residual threats and possible fixes' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This documents performs an analysis of the residual threats for MPTCP and explores possible solutions to them. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mptcp-attacks/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mptcp-attacks/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 17 00:23:22 2014 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 E1CB81A90F3 for ; Fri, 17 Oct 2014 00:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.12 X-Spam-Level: *** X-Spam-Status: No, score=3.12 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 2V1wITShCDD1 for ; Fri, 17 Oct 2014 00:23:19 -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 6D3261A90F1 for ; Fri, 17 Oct 2014 00:23:19 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5E03B278104 for ; Fri, 17 Oct 2014 16:23:17 +0900 (JST) Received: by mail-wg0-f48.google.com with SMTP id k14so260888wgh.7 for ; Fri, 17 Oct 2014 00:23:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.206.72 with SMTP id lm8mr8333179wjc.70.1413530595054; Fri, 17 Oct 2014 00:23:15 -0700 (PDT) Received: by 10.194.3.82 with HTTP; Fri, 17 Oct 2014 00:23:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Oct 2014 00:23:15 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=047d7bb70a72ff5cb60505993cd1 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/JH2PlCw1VFI5eo-V9YE7fOSSi6k Subject: Re: [multipathtcp] hawaii 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, 17 Oct 2014 07:23:21 -0000 --047d7bb70a72ff5cb60505993cd1 Content-Type: text/plain; charset=UTF-8 Hi, We haven't received any requests or suggestions so far... We'll wait a bit more. -- Yoshi & Phil On Mon, Oct 13, 2014 at 12:10 AM, Yoshifumi Nishida wrote: > Hi, > there are some discussions between chairs and AD whether we will have a > meeting in Hawaii as we feel that not so many folks have a plan to go > there, but in the end, we got a 1.5 hour meeting slot at 11:50-13:20 > Friday, November 14. > > Although this might not be the best opportunity as we might not have > enough people, it may be utilized to share some (even pre-matured) ideas or > exchange some info or build networks. > If you're interested in presenting something or you have some suggestions > for the agenda, please let us know. > > OTOH, if there's little interest for the slot, we will think about > returning the slot. > > Regards, > -- > Yoshi & Phil > > --047d7bb70a72ff5cb60505993cd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
We haven't received any requests or sugg= estions so far...=C2=A0 We'll wait a bit more.
--
Yoshi &= amp; Phil

On M= on, Oct 13, 2014 at 12:10 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.= jp> wrote:
Hi,=C2=A0
there are some discussions between chairs and AD = whether we will have a meeting in Hawaii as we feel that not so many folks = have a plan to go there, but in the end, we got a 1.5 hour meeting slot at = 11:50-13:20 Friday, November 14.

Although this mig= ht not be the best opportunity as we might not have enough people, it may b= e utilized to share some (even pre-matured) ideas or exchange some info or = build networks.
If you're interested in presenting something = or you have some suggestions for the agenda, please let us know.
=
OTOH, if there's little interest for the slot, we will t= hink about returning the slot.

Regards,
= --
Yoshi & Phil


--047d7bb70a72ff5cb60505993cd1-- From nobody Fri Oct 17 00:24:25 2014 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 3D1CA1A90F3 for ; Fri, 17 Oct 2014 00:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, 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 3kwlDsXlbAF6 for ; Fri, 17 Oct 2014 00:14:58 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052F31A90F4 for ; Fri, 17 Oct 2014 00:14:57 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7C92A2781A4 for ; Fri, 17 Oct 2014 16:14:55 +0900 (JST) Received: by mail-wi0-f181.google.com with SMTP id hi2so428281wib.14 for ; Fri, 17 Oct 2014 00:14:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.74.227 with SMTP id x3mr26563043wiv.15.1413530092833; Fri, 17 Oct 2014 00:14:52 -0700 (PDT) Received: by 10.194.3.82 with HTTP; Fri, 17 Oct 2014 00:14:52 -0700 (PDT) In-Reply-To: <20141011115953.A3B14181C7D@rfc-editor.org> References: <20141011115953.A3B14181C7D@rfc-editor.org> Date: Fri, 17 Oct 2014 00:14:52 -0700 Message-ID: From: Yoshifumi Nishida To: RFC Errata System Content-Type: multipart/alternative; boundary=f46d043c7eee1013da0505991fd2 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/9kjcJMKgeLKLPncdYCJT9CBQTUU X-Mailman-Approved-At: Fri, 17 Oct 2014 00:24:24 -0700 Cc: friedrich@haussmann.tel, costin.raiciu@cs.pub.ro, alanford@cisco.com, multipathtcp , Martin Stiemerling , Mark Handley Subject: Re: [multipathtcp] [Technical Errata Reported] RFC6824 (4129) 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, 17 Oct 2014 07:15:00 -0000 --f46d043c7eee1013da0505991fd2 Content-Type: text/plain; charset=UTF-8 Hi, I think this errata is right. Since we're preparing 6824bis, this should be reflected in the new version. Any thoughts? -- Yoshi On Sat, Oct 11, 2014 at 4:59 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC6824, > "TCP Extensions for Multipath Operation with Multiple Addresses". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6824&eid=4129 > > -------------------------------------- > Type: Technical > Reported by: Friedrich Haussmann > > Section: B.1.1. > > Original Text > ------------- > MPTCP.Checksum (flag): This flag is set to true if at least one of > the hosts has set the C bit in the MP_CAPABLE options exchanged > during connection establishment, and is set to false otherwise. > If this flag is set, the checksum must be computed in all DSS > options. > > Corrected Text > -------------- > MPTCP.Checksum (flag): This flag is set to true if at least one of > the hosts has set the A bit in the MP_CAPABLE options exchanged > during connection establishment, and is set to false otherwise. > If this flag is set, the checksum must be computed in all DSS > options. > > Notes > ----- > Checksum is not on bit "C", but instead on bit "A". There are no other > instances of referring on bit "C" as the checksum. Bit "C" is unassigned in > this version. > > Other instances of bit "A" as checksum: > * Section 3.1. Connection Initiation, p. 16 f. > * Section 8. IANA Considerations, Table 3: MPTCP Handshake Algorithms, p. > 56 > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6824 (draft-ietf-mptcp-multiaddressed-12) > -------------------------------------- > Title : TCP Extensions for Multipath Operation with Multiple > Addresses > Publication Date : January 2013 > Author(s) : A. Ford, C. Raiciu, M. Handley, O. Bonaventure > Category : EXPERIMENTAL > Source : Multipath TCP > Area : Transport > Stream : IETF > Verifying Party : IESG > > --f46d043c7eee1013da0505991fd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
I think this errata is right.=C2=A0
Sinc= e we're preparing 6824bis, this should be reflected in the new version.=
Any thoughts?
--
Yoshi

On Sat, Oct 11, 2014 at 4:59 AM, RF= C Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been submi= tted for RFC6824,
"TCP Extensions for Multipath Operation with Multiple Addresses".=

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D6824&eid=3D4129

--------------------------------------
Type: Technical
Reported by: Friedrich Haussmann <friedrich@haussmann.tel>

Section: B.1.1.

Original Text
-------------
MPTCP.Checksum (flag):=C2=A0 This flag is set to true if at least one of =C2=A0 =C2=A0 =C2=A0 the hosts has set the C bit in the MP_CAPABLE options = exchanged
=C2=A0 =C2=A0 =C2=A0 during connection establishment, and is set to false o= therwise.
=C2=A0 =C2=A0 =C2=A0 If this flag is set, the checksum must be computed in = all DSS
=C2=A0 =C2=A0 =C2=A0 options.

Corrected Text
--------------
MPTCP.Checksum (flag):=C2=A0 This flag is set to true if at least one of =C2=A0 =C2=A0 =C2=A0 the hosts has set the A bit in the MP_CAPABLE options = exchanged
=C2=A0 =C2=A0 =C2=A0 during connection establishment, and is set to false o= therwise.
=C2=A0 =C2=A0 =C2=A0 If this flag is set, the checksum must be computed in = all DSS
=C2=A0 =C2=A0 =C2=A0 options.

Notes
-----
Checksum is not on bit "C", but instead on bit "A". The= re are no other instances of referring on bit "C" as the checksum= . Bit "C" is unassigned in this version.

Other instances of bit "A" as checksum:
* Section 3.1. Connection Initiation, p. 16 f.
* Section 8. IANA Considerations, Table 3: MPTCP Handshake Algorithms, p. 5= 6

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6824 (draft-ietf-mptcp-multiaddressed-12)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: TCP Extension= s for Multipath Operation with Multiple Addresses
Publication Date=C2=A0 =C2=A0 : January 2013
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Ford, C. Raiciu, M. = Handley, O. Bonaventure
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : EXPERIMENTAL
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Multipath TCP
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG


--f46d043c7eee1013da0505991fd2-- From nobody Mon Oct 20 18:11:25 2014 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 415691ACFFB for ; Mon, 20 Oct 2014 18:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 2ei-F-qTaUBm for ; Mon, 20 Oct 2014 18:11:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD7E1ACFF1 for ; Mon, 20 Oct 2014 18:11:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNW05672; Tue, 21 Oct 2014 01:11:12 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Oct 2014 02:11:09 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.43]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 21 Oct 2014 09:11:03 +0800 From: Weixinpeng To: Yoshifumi Nishida , multipathtcp Thread-Topic: [multipathtcp] hawaii meeting Thread-Index: AQHP6dtBosypuhIGH0ibolwLv3P9P5w5wvLw Date: Tue, 21 Oct 2014 01:11:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D841B32nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/y05k-uZMaCBZDgevwIbxc4lWvdc Subject: Re: [multipathtcp] hawaii 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, 21 Oct 2014 01:11:23 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D841B32nkgeml507mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQpJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgdG9waWMgZGlzY3Vzc2lvbiBvbiBN UFRDUCBwcm94eSByZWxhdGVkIGlzc3VlcywgYW5kIGl0IHdvdWxkIGJlIGJldHRlciBpZiB3ZSBj b3VsZCBoYXZlIHNvbWUga2luZCBvZiBjb25zZW5zdXMgb24gaXQuDQpUaGFua3MhDQpCZXN0IFJl Z2FyZHMsDQpYaW5wZW5nDQoNCkZyb206IG11bHRpcGF0aHRjcCBbbWFpbHRvOm11bHRpcGF0aHRj cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWW9zaGlmdW1pIE5pc2hpZGENClNlbnQ6 IEZyaWRheSwgT2N0b2JlciAxNywgMjAxNCAzOjIzIFBNDQpUbzogbXVsdGlwYXRodGNwDQpTdWJq ZWN0OiBSZTogW211bHRpcGF0aHRjcF0gaGF3YWlpIG1lZXRpbmcNCg0KSGksDQpXZSBoYXZlbid0 IHJlY2VpdmVkIGFueSByZXF1ZXN0cyBvciBzdWdnZXN0aW9ucyBzbyBmYXIuLi4gIFdlJ2xsIHdh aXQgYSBiaXQgbW9yZS4NCi0tDQpZb3NoaSAmIFBoaWwNCg0KT24gTW9uLCBPY3QgMTMsIDIwMTQg YXQgMTI6MTAgQU0sIFlvc2hpZnVtaSBOaXNoaWRhIDxuaXNoaWRhQHNmYy53aWRlLmFkLmpwPG1h aWx0bzpuaXNoaWRhQHNmYy53aWRlLmFkLmpwPj4gd3JvdGU6DQpIaSwNCnRoZXJlIGFyZSBzb21l IGRpc2N1c3Npb25zIGJldHdlZW4gY2hhaXJzIGFuZCBBRCB3aGV0aGVyIHdlIHdpbGwgaGF2ZSBh IG1lZXRpbmcgaW4gSGF3YWlpIGFzIHdlIGZlZWwgdGhhdCBub3Qgc28gbWFueSBmb2xrcyBoYXZl IGEgcGxhbiB0byBnbyB0aGVyZSwgYnV0IGluIHRoZSBlbmQsIHdlIGdvdCBhIDEuNSBob3VyIG1l ZXRpbmcgc2xvdCBhdCAxMTo1MC0xMzoyMCBGcmlkYXksIE5vdmVtYmVyIDE0Lg0KDQpBbHRob3Vn aCB0aGlzIG1pZ2h0IG5vdCBiZSB0aGUgYmVzdCBvcHBvcnR1bml0eSBhcyB3ZSBtaWdodCBub3Qg aGF2ZSBlbm91Z2ggcGVvcGxlLCBpdCBtYXkgYmUgdXRpbGl6ZWQgdG8gc2hhcmUgc29tZSAoZXZl biBwcmUtbWF0dXJlZCkgaWRlYXMgb3IgZXhjaGFuZ2Ugc29tZSBpbmZvIG9yIGJ1aWxkIG5ldHdv cmtzLg0KSWYgeW91J3JlIGludGVyZXN0ZWQgaW4gcHJlc2VudGluZyBzb21ldGhpbmcgb3IgeW91 IGhhdmUgc29tZSBzdWdnZXN0aW9ucyBmb3IgdGhlIGFnZW5kYSwgcGxlYXNlIGxldCB1cyBrbm93 Lg0KDQpPVE9ILCBpZiB0aGVyZSdzIGxpdHRsZSBpbnRlcmVzdCBmb3IgdGhlIHNsb3QsIHdlIHdp bGwgdGhpbmsgYWJvdXQgcmV0dXJuaW5nIHRoZSBzbG90Lg0KDQpSZWdhcmRzLA0KLS0NCllvc2hp ICYgUGhpbA0KDQoNCg== --_000_C5C3BB522B1DDF478AA09545169155B46D841B32nkgeml507mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBZb3No aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgd2Ug c2hvdWxkIGhhdmUgYSB0b3BpYyBkaXNjdXNzaW9uIG9uIE1QVENQIHByb3h5IHJlbGF0ZWQgaXNz dWVzLCBhbmQgaXQgd291bGQgYmUgYmV0dGVyIGlmIHdlIGNvdWxkIGhhdmUgc29tZSBraW5kIG9m IGNvbnNlbnN1cyBvbiBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJl c3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlhp bnBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbXVsdGlwYXRodGNwIFttYWlsdG86bXVs dGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPllvc2hpZnVt aSBOaXNoaWRhPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAxNywgMjAxNCAzOjIz IFBNPGJyPg0KPGI+VG86PC9iPiBtdWx0aXBhdGh0Y3A8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFttdWx0aXBhdGh0Y3BdIGhhd2FpaSBtZWV0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBoYXZlbid0IHJlY2Vp dmVkIGFueSByZXF1ZXN0cyBvciBzdWdnZXN0aW9ucyBzbyBmYXIuLi4mbmJzcDsgV2UnbGwgd2Fp dCBhIGJpdCBtb3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WW9zaGkg JmFtcDsgUGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBNb24sIE9jdCAx MywgMjAxNCBhdCAxMjoxMCBBTSwgWW9zaGlmdW1pIE5pc2hpZGEgJmx0OzxhIGhyZWY9Im1haWx0 bzpuaXNoaWRhQHNmYy53aWRlLmFkLmpwIiB0YXJnZXQ9Il9ibGFuayI+bmlzaGlkYUBzZmMud2lk ZS5hZC5qcDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpLCZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj50aGVyZSBhcmUgc29tZSBkaXNjdXNzaW9ucyBiZXR3ZWVuIGNoYWly cyBhbmQgQUQgd2hldGhlciB3ZSB3aWxsIGhhdmUgYSBtZWV0aW5nIGluIEhhd2FpaSBhcyB3ZSBm ZWVsIHRoYXQgbm90IHNvIG1hbnkgZm9sa3MgaGF2ZSBhIHBsYW4gdG8gZ28gdGhlcmUsIGJ1dCBp biB0aGUgZW5kLCB3ZSBnb3QgYSAxLjUgaG91ciBtZWV0aW5nIHNsb3QgYXQgMTE6NTAtMTM6MjAg RnJpZGF5LA0KIE5vdmVtYmVyIDE0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+QWx0aG91Z2ggdGhpcyBtaWdodCBub3QgYmUgdGhlIGJlc3Qgb3Bwb3J0 dW5pdHkgYXMgd2UgbWlnaHQgbm90IGhhdmUgZW5vdWdoIHBlb3BsZSwgaXQgbWF5IGJlIHV0aWxp emVkIHRvIHNoYXJlIHNvbWUgKGV2ZW4gcHJlLW1hdHVyZWQpIGlkZWFzIG9yIGV4Y2hhbmdlIHNv bWUgaW5mbyBvciBidWlsZCBuZXR3b3Jrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgeW91J3Jl IGludGVyZXN0ZWQgaW4gcHJlc2VudGluZyBzb21ldGhpbmcgb3IgeW91IGhhdmUgc29tZSBzdWdn ZXN0aW9ucyBmb3IgdGhlIGFnZW5kYSwgcGxlYXNlIGxldCB1cyBrbm93LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T1RPSCwgaWYgdGhlcmUncyBsaXR0 bGUgaW50ZXJlc3QgZm9yIHRoZSBzbG90LCB3ZSB3aWxsIHRoaW5rIGFib3V0IHJldHVybmluZyB0 aGUgc2xvdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllv c2hpICZhbXA7IFBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C5C3BB522B1DDF478AA09545169155B46D841B32nkgeml507mbxchi_-- From nobody Mon Oct 20 22:35:11 2014 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 949961AD052 for ; Mon, 20 Oct 2014 22:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 SlVZ38BhIXU5 for ; Mon, 20 Oct 2014 22:35:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F951A6F91 for ; Mon, 20 Oct 2014 22:35:08 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus002) with ESMTP (Nemesis) id 0MIOcr-1XhqKo2Si7-004FK4; Tue, 21 Oct 2014 07:34:58 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2E64904C-6D25-49DA-B5A3-7B3969F050AA" From: Alper Yegin In-Reply-To: Date: Tue, 21 Oct 2014 08:34:51 +0300 Message-Id: <7700F7D7-80E3-4B98-B285-7A146E502245@yegin.org> References: To: Weixinpeng X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:nrl3KqME8fBRUeXwpo6Ze3vE4LoYeIAkSrqZkjIja6e 0nNZVJn+ufBcYYv/UhZkM7nHPxYEtkjpr1RPkG1AvGbkWSD6B/ TSohinueOr0nPfNeunmx/RoaOPInan6EiYtKiWTqkzfwoqZUum dNdR/2wv51UXZXhMT04MrzQ35Z1W2YCX8SUNfeKLGfavvXxfXE MwoIVe+dgZBe7XXX/uNH5Fnz86A69o/oT0Zy/RWgyVWkuvBUnB JwuqF39BeEy0dIftwH/TDmI5OcH1unIaFFMUP0OItaN/440EYC Ipa0E1/TzRvCKJtCxCJLqRMOcihY1si7D/K4V/qpILWx49mQX0 BHZZpYpyp1oY/ElGe8eR0B9O1vswrudFTCvn1dI2LsMnf1ZHfX KkoayS0hictsA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/wHSpy9c95IjPe7JAxJaIsHyUmNU Cc: multipathtcp Subject: Re: [multipathtcp] hawaii 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, 21 Oct 2014 05:35:10 -0000 --Apple-Mail=_2E64904C-6D25-49DA-B5A3-7B3969F050AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, continuing discussions on MPTCP proxy would be good. On Oct 21, 2014, at 4:11 AM, Weixinpeng wrote: > Hi Yoshi, > I think we should have a topic discussion on MPTCP proxy related = issues, and it would be better if we could have some kind of consensus = on it. > Thanks! > Best Regards, > Xinpeng > =20 > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of = Yoshifumi Nishida > Sent: Friday, October 17, 2014 3:23 PM > To: multipathtcp > Subject: Re: [multipathtcp] hawaii meeting > =20 > Hi, > We haven't received any requests or suggestions so far... We'll wait = a bit more. > -- > Yoshi & Phil > =20 > On Mon, Oct 13, 2014 at 12:10 AM, Yoshifumi Nishida = wrote: > Hi,=20 > there are some discussions between chairs and AD whether we will have = a meeting in Hawaii as we feel that not so many folks have a plan to go = there, but in the end, we got a 1.5 hour meeting slot at 11:50-13:20 = Friday, November 14. > =20 > Although this might not be the best opportunity as we might not have = enough people, it may be utilized to share some (even pre-matured) ideas = or exchange some info or build networks. > If you're interested in presenting something or you have some = suggestions for the agenda, please let us know. > =20 > OTOH, if there's little interest for the slot, we will think about = returning the slot. > =20 > Regards, > -- > Yoshi & Phil > =20 > =20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail=_2E64904C-6D25-49DA-B5A3-7B3969F050AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes, continuing discussions on MPTCP proxy would be = good.

On Oct 21, 2014, at 4:11 AM, Weixinpeng = wrote:

Hi Yoshi,
I think we should have a = topic discussion on MPTCP proxy related issues, and it would be better = if we could have some kind of consensus on = it.
Thanks!
Best = Regards,
Xinpeng
 multipathtcp = [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Yoshifumi = Nishida
Sent: Friday, October 17, 2014 = 3:23 PM
To: multipathtcp
Subject: Re: [multipathtcp] = hawaii meeting
 
Hi,
We haven't received any requests or suggestions = so far...  We'll wait a bit more.
--
_______________________________________________
multipathtcp mailing = list
multipathtcp@ietf.org
https:/= /www.ietf.org/mailman/listinfo/multipathtcp

= --Apple-Mail=_2E64904C-6D25-49DA-B5A3-7B3969F050AA-- From nobody Mon Oct 20 23:14:13 2014 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 106041AD066 for ; Mon, 20 Oct 2014 23:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.221 X-Spam-Level: * X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5fr3LBTrHnL5 for ; Mon, 20 Oct 2014 23:14:08 -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 E5B711AD062 for ; Mon, 20 Oct 2014 23:14:07 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5BA4E27821A for ; Tue, 21 Oct 2014 15:14:05 +0900 (JST) Received: by mail-wi0-f174.google.com with SMTP id r20so1071834wiv.1 for ; Mon, 20 Oct 2014 23:14:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.104.99 with SMTP id gd3mr15884697wib.10.1413872043010; Mon, 20 Oct 2014 23:14:03 -0700 (PDT) Received: by 10.194.3.82 with HTTP; Mon, 20 Oct 2014 23:14:02 -0700 (PDT) In-Reply-To: <7700F7D7-80E3-4B98-B285-7A146E502245@yegin.org> References: <7700F7D7-80E3-4B98-B285-7A146E502245@yegin.org> Date: Mon, 20 Oct 2014 23:14:02 -0700 Message-ID: From: Yoshifumi Nishida To: Alper Yegin Content-Type: multipart/alternative; boundary=f46d04428170e1b48f0505e8bca9 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/_DfBx5I5J4YKtvHOmZdVv9IiNBo Cc: multipathtcp Subject: Re: [multipathtcp] hawaii 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, 21 Oct 2014 06:14:10 -0000 --f46d04428170e1b48f0505e8bca9 Content-Type: text/plain; charset=UTF-8 Hi Weixinpeng, Alper, Thanks for the response. Sounds a good idea. Does anyone want to present something on this topic? Thanks, -- Yoshi On Mon, Oct 20, 2014 at 10:34 PM, Alper Yegin wrote: > Yes, continuing discussions on MPTCP proxy would be good. > > On Oct 21, 2014, at 4:11 AM, Weixinpeng wrote: > > Hi Yoshi, > I think we should have a topic discussion on MPTCP proxy related issues, > and it would be better if we could have some kind of consensus on it. > Thanks! > Best Regards, > Xinpeng > > *From:* multipathtcp [mailto:multipathtcp-bounces@ietf.org] *On Behalf > Of *Yoshifumi Nishida > *Sent:* Friday, October 17, 2014 3:23 PM > *To:* multipathtcp > *Subject:* Re: [multipathtcp] hawaii meeting > > Hi, > We haven't received any requests or suggestions so far... We'll wait a > bit more. > -- > Yoshi & Phil > > On Mon, Oct 13, 2014 at 12:10 AM, Yoshifumi Nishida < > nishida@sfc.wide.ad.jp> wrote: > Hi, > there are some discussions between chairs and AD whether we will have a > meeting in Hawaii as we feel that not so many folks have a plan to go > there, but in the end, we got a 1.5 hour meeting slot at 11:50-13:20 > Friday, November 14. > > Although this might not be the best opportunity as we might not have > enough people, it may be utilized to share some (even pre-matured) ideas or > exchange some info or build networks. > If you're interested in presenting something or you have some suggestions > for the agenda, please let us know. > > OTOH, if there's little interest for the slot, we will think about > returning the slot. > > Regards, > -- > Yoshi & Phil > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > > --f46d04428170e1b48f0505e8bca9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Weixinpeng, Alper,

Thanks for the re= sponse. Sounds a good idea.=C2=A0
Does anyone want to present som= ething on this topic?

Thanks,
--
Yoshi

On Mon, Oct 20, 2014 at 10:34 PM, Alper Yegin <= alper.yegin@yegi= n.org> wrote:
Yes, continuing discussions on MPTCP proxy would be good.

=
On Oct 21, 2014, at 4:11 AM, Weixinpeng wr= ote:

Hi Yoshi,<= u>
I think we sho= uld have a topic discussion on MPTCP proxy related issues, and it would be = better if we could have some kind of consensus on it.<= /div>
Thanks!
Best Regards,
Xinpeng
=C2=A0
From:=C2=A0multipathtcp [m= ailto:mu= ltipathtcp-bounces@ietf.org]=C2=A0On Behalf Of=C2= =A0Yoshifumi Nishida
Sent:=C2=A0Friday, O= ctober 17, 2014 3:23 PM
To:=C2=A0multipathtcp
= Subject:=C2=A0Re: [multipathtcp] hawaii meeting<= /u>
=C2=A0=
Hi,=
We haven't received a= ny requests or suggestions so far...=C2=A0 We'll wait a bit more.
--
Yoshi & Phil
=C2=A0
On Mon, Oct 13, 2014 at = 12:10 AM, Yoshifumi Nishida <nishida@sfc= .wide.ad.jp> wrote:
= Hi,=C2=A0
there are some discussions between chairs and AD = whether we will have a meeting in Hawaii as we feel that not so many folks = have a plan to go there, but in the end, we got a 1.5 hour meeting slot at = 11:50-13:20 Friday, November 14.
=C2=A0
Although this might not be the best opportunity a= s we might not have enough people, it may be utilized to share some (even p= re-matured) ideas or exchange some info or build networks.
If you're intereste= d in presenting something or you have some suggestions for the agenda, plea= se let us know.
=C2=A0
OTOH, if there's little interest for the slot, we will think= about returning the slot.
= =C2=A0
= Regards,
--
= Yoshi & Phil
=
=C2=A0
=C2=A0
<= /div>
__________________________________= _____________
multipathtcp mailing list
multipathtcp@ietf.org
https://ww= w.ietf.org/mailman/listinfo/multipathtcp


--f46d04428170e1b48f0505e8bca9-- From nobody Fri Oct 24 06:12:54 2014 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 711451A009E for ; Fri, 24 Oct 2014 06:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 ppHgWJzhfVPA for ; Fri, 24 Oct 2014 06:12:39 -0700 (PDT) Received: from donder.nssi.telus.com (donder.nssi.telus.com [208.38.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4A72A1A0097 for ; Fri, 24 Oct 2014 06:12:32 -0700 (PDT) DomainKey-Signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:CC:Date:Subject:Thread-Topic: Thread-Index:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:acceptlanguage:Content-Type: MIME-Version; b=hPDknn+0ZS1fBsmFSaAeKMaKoEfm2LIywxD75KQjEnvWPoVI2BB2LiG6 I2+yIe0UREQ5ty+LkshcRa5ehrqDwj6cO7UtIf+mLgWh3naaWVZYgXJI3 cgMZBsD0SjCLx/N+cLrkeJa6PSQFz4C+UHSp6NarPlRC0H54y36Un/3U3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAO5PSlSOsmOR/2dsb2JhbABcgkgjI1RYgwayUZdMAQmGeVQCG24WAX2EAgEBAQQBAQEgCiYbCxACAQgNBAQBASgDAgICJQsUCQgBAQQBDQUIiDkBDLQblHsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpXhVAWFwQGAYJ3NoEeBYtjhASPJ4NJgxuOF4QXTYJLAQEB X-IronPort-AV: E=Sophos;i="5.04,780,1406592000"; d="scan'208,217";a="361387043" Received: from unknown (HELO WP40080.corp.ads) ([142.178.99.145]) by donder-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 24 Oct 2014 13:12:15 +0000 Received: from WP40046.corp.ads ([::1]) by WP40080.corp.ads ([::1]) with mapi; Fri, 24 Oct 2014 07:12:15 -0600 From: Jordan Melzer To: Yoshifumi Nishida , Alper Yegin Date: Fri, 24 Oct 2014 07:12:14 -0600 Thread-Topic: [multipathtcp] hawaii meeting Thread-Index: Ac/s9j/tiWqdBhJuTKm89NqqLRpKJQBaoMOg Message-ID: <80C0017654A043479F53C41112BE847687D6AFF672@WP40046.corp.ads> References: <7700F7D7-80E3-4B98-B285-7A146E502245@yegin.org> In-Reply-To: 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_80C0017654A043479F53C41112BE847687D6AFF672WP40046corpad_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/9vicC1WNWpAIjbqM4O3r5PtG-1M Cc: multipathtcp Subject: Re: [multipathtcp] hawaii 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, 24 Oct 2014 13:12:47 -0000 --_000_80C0017654A043479F53C41112BE847687D6AFF672WP40046corpad_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgaXTigJlzIG9rYXkgdG8gcHJlc2VudCByZW1vdGVseSwgSSBjb3VsZCBnaXZlIGEgYnJpZWYg cHJlc2VudGF0aW9uIG9uIHRoZSBURUxVUyAvIEFsZ29ucXVpbiBDb2xsZWdlIHByb3h5IGltcGxl bWVudGF0aW9uIGFuZCBleHBlcmllbmNlLiAgSXQgd2lsbCBiZSBicmllZiBiZWNhdXNlIHdlIGJ1 aWx0IGEgcHJveHkgYnkgcnVubmluZyBhbiBleGlzdGluZyBUQ1AgcHJveHkgKE1hbGxvcnkpIG9u IGEgbWFjaGluZSB3aXRoIGFuIE1QVENQIGVuYWJsZWQga2VybmVsIChVQyBMb3V2YWluKSwgYW5k IGl0IHdvcmtlZC4NCg0KRnJvbTogbXVsdGlwYXRodGNwIFttYWlsdG86bXVsdGlwYXRodGNwLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBZb3NoaWZ1bWkgTmlzaGlkYQ0KU2VudDogT2N0 b2JlciAyMSwgMjAxNCAwMjoxNCBBTQ0KVG86IEFscGVyIFllZ2luDQpDYzogbXVsdGlwYXRodGNw DQpTdWJqZWN0OiBSZTogW211bHRpcGF0aHRjcF0gaGF3YWlpIG1lZXRpbmcNCg0KSGkgV2VpeGlu cGVuZywgQWxwZXIsDQoNClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLiBTb3VuZHMgYSBnb29kIGlk ZWEuDQpEb2VzIGFueW9uZSB3YW50IHRvIHByZXNlbnQgc29tZXRoaW5nIG9uIHRoaXMgdG9waWM/ DQoNClRoYW5rcywNCi0tDQpZb3NoaQ0KDQpPbiBNb24sIE9jdCAyMCwgMjAxNCBhdCAxMDozNCBQ TSwgQWxwZXIgWWVnaW4gPGFscGVyLnllZ2luQHllZ2luLm9yZzxtYWlsdG86YWxwZXIueWVnaW5A eWVnaW4ub3JnPj4gd3JvdGU6DQpZZXMsIGNvbnRpbnVpbmcgZGlzY3Vzc2lvbnMgb24gTVBUQ1Ag cHJveHkgd291bGQgYmUgZ29vZC4NCg0KT24gT2N0IDIxLCAyMDE0LCBhdCA0OjExIEFNLCBXZWl4 aW5wZW5nIHdyb3RlOg0KDQpIaSBZb3NoaSwNCkkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSB0b3Bp YyBkaXNjdXNzaW9uIG9uIE1QVENQIHByb3h5IHJlbGF0ZWQgaXNzdWVzLCBhbmQgaXQgd291bGQg YmUgYmV0dGVyIGlmIHdlIGNvdWxkIGhhdmUgc29tZSBraW5kIG9mIGNvbnNlbnN1cyBvbiBpdC4N ClRoYW5rcyENCkJlc3QgUmVnYXJkcywNClhpbnBlbmcNCg0KRnJvbTogbXVsdGlwYXRodGNwIFtt YWlsdG86bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm11bHRpcGF0aHRjcC1i b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFlvc2hpZnVtaSBOaXNoaWRhDQpTZW50OiBG cmlkYXksIE9jdG9iZXIgMTcsIDIwMTQgMzoyMyBQTQ0KVG86IG11bHRpcGF0aHRjcA0KU3ViamVj dDogUmU6IFttdWx0aXBhdGh0Y3BdIGhhd2FpaSBtZWV0aW5nDQoNCkhpLA0KV2UgaGF2ZW4ndCBy ZWNlaXZlZCBhbnkgcmVxdWVzdHMgb3Igc3VnZ2VzdGlvbnMgc28gZmFyLi4uICBXZSdsbCB3YWl0 IGEgYml0IG1vcmUuDQotLQ0KWW9zaGkgJiBQaGlsDQoNCk9uIE1vbiwgT2N0IDEzLCAyMDE0IGF0 IDEyOjEwIEFNLCBZb3NoaWZ1bWkgTmlzaGlkYSA8bmlzaGlkYUBzZmMud2lkZS5hZC5qcDxtYWls dG86bmlzaGlkYUBzZmMud2lkZS5hZC5qcD4+IHdyb3RlOg0KSGksDQp0aGVyZSBhcmUgc29tZSBk aXNjdXNzaW9ucyBiZXR3ZWVuIGNoYWlycyBhbmQgQUQgd2hldGhlciB3ZSB3aWxsIGhhdmUgYSBt ZWV0aW5nIGluIEhhd2FpaSBhcyB3ZSBmZWVsIHRoYXQgbm90IHNvIG1hbnkgZm9sa3MgaGF2ZSBh IHBsYW4gdG8gZ28gdGhlcmUsIGJ1dCBpbiB0aGUgZW5kLCB3ZSBnb3QgYSAxLjUgaG91ciBtZWV0 aW5nIHNsb3QgYXQgMTE6NTAtMTM6MjAgRnJpZGF5LCBOb3ZlbWJlciAxNC4NCg0KQWx0aG91Z2gg dGhpcyBtaWdodCBub3QgYmUgdGhlIGJlc3Qgb3Bwb3J0dW5pdHkgYXMgd2UgbWlnaHQgbm90IGhh dmUgZW5vdWdoIHBlb3BsZSwgaXQgbWF5IGJlIHV0aWxpemVkIHRvIHNoYXJlIHNvbWUgKGV2ZW4g cHJlLW1hdHVyZWQpIGlkZWFzIG9yIGV4Y2hhbmdlIHNvbWUgaW5mbyBvciBidWlsZCBuZXR3b3Jr cy4NCklmIHlvdSdyZSBpbnRlcmVzdGVkIGluIHByZXNlbnRpbmcgc29tZXRoaW5nIG9yIHlvdSBo YXZlIHNvbWUgc3VnZ2VzdGlvbnMgZm9yIHRoZSBhZ2VuZGEsIHBsZWFzZSBsZXQgdXMga25vdy4N Cg0KT1RPSCwgaWYgdGhlcmUncyBsaXR0bGUgaW50ZXJlc3QgZm9yIHRoZSBzbG90LCB3ZSB3aWxs IHRoaW5rIGFib3V0IHJldHVybmluZyB0aGUgc2xvdC4NCg0KUmVnYXJkcywNCi0tDQpZb3NoaSAm IFBoaWwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbXVsdGlwYXRodGNwIG1haWxpbmcgbGlzdA0KbXVsdGlwYXRodGNwQGlldGYub3JnPG1haWx0 bzptdWx0aXBhdGh0Y3BAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL211bHRpcGF0aHRjcA0KDQoNCg== --_000_80C0017654A043479F53C41112BE847687D6AFF672WP40046corpad_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1T dW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUNB O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQ0EgbGluaz1ibHVlIHZsaW5r PXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5JZiBpdOKAmXMgb2theSB0byBwcmVzZW50IHJlbW90ZWx5LCBJIGNv dWxkIGdpdmUgYSBicmllZiBwcmVzZW50YXRpb24gb24gdGhlIFRFTFVTIC8gQWxnb25xdWluIENv bGxlZ2UgcHJveHkgaW1wbGVtZW50YXRpb24gYW5kIGV4cGVyaWVuY2UuwqAgSXQgd2lsbCBiZSBi cmllZiBiZWNhdXNlIHdlIGJ1aWx0IGEgcHJveHkgYnkgcnVubmluZyBhbiBleGlzdGluZyBUQ1Ag cHJveHkgKE1hbGxvcnkpIG9uIGEgbWFjaGluZSB3aXRoIGFuIE1QVENQIGVuYWJsZWQga2VybmVs IChVQyBMb3V2YWluKSwgYW5kIGl0IHdvcmtlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gbXVsdGlwYXRodGNwIFttYWlsdG86bXVsdGlwYXRo dGNwLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+WW9zaGlmdW1pIE5pc2hp ZGE8YnI+PGI+U2VudDo8L2I+IE9jdG9iZXIgMjEsIDIwMTQgMDI6MTQgQU08YnI+PGI+VG86PC9i PiBBbHBlciBZZWdpbjxicj48Yj5DYzo8L2I+IG11bHRpcGF0aHRjcDxicj48Yj5TdWJqZWN0Ojwv Yj4gUmU6IFttdWx0aXBhdGh0Y3BdIGhhd2FpaSBtZWV0aW5nPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5IaSBXZWl4aW5wZW5nLCBBbHBlciw8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5UaGFua3MgZm9yIHRoZSByZXNwb25zZS4gU291bmRzIGEgZ29vZCBpZGVhLiZuYnNwOzxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkRvZXMgYW55b25lIHdh bnQgdG8gcHJlc2VudCBzb21ldGhpbmcgb24gdGhpcyB0b3BpYz88bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5UaGFua3MsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+LS08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5Zb3NoaTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBN b24sIE9jdCAyMCwgMjAxNCBhdCAxMDozNCBQTSwgQWxwZXIgWWVnaW4gJmx0OzxhIGhyZWY9Im1h aWx0bzphbHBlci55ZWdpbkB5ZWdpbi5vcmciIHRhcmdldD0iX2JsYW5rIj5hbHBlci55ZWdpbkB5 ZWdpbi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5ZZXMsIGNvbnRpbnVpbmcgZGlzY3Vzc2lvbnMgb24gTVBUQ1AgcHJveHkgd291bGQgYmUg Z29vZC48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48ZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBPY3QgMjEs IDIwMTQsIGF0IDQ6MTEgQU0sIFdlaXhpbnBlbmcgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxibG9j a3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+ PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPkhpIFlvc2hpLDwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04nPkkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSB0b3BpYyBkaXNjdXNzaW9uIG9uIE1QVENQIHBy b3h5IHJlbGF0ZWQgaXNzdWVzLCBhbmQgaXQgd291bGQgYmUgYmV0dGVyIGlmIHdlIGNvdWxkIGhh dmUgc29tZSBraW5kIG9mIGNvbnNlbnN1cyBvbiBpdC48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz5UaGFua3MhPC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04n PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+ QmVzdCBSZWdhcmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPlhpbnBlbmc8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+Jm5ic3A7bXVsdGlwYXRo dGNwIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSZuYnNw OzxiPk9uIEJlaGFsZiBPZiZuYnNwOzwvYj5Zb3NoaWZ1bWkgTmlzaGlkYTxicj48Yj5TZW50Ojwv Yj4mbmJzcDtGcmlkYXksIE9jdG9iZXIgMTcsIDIwMTQgMzoyMyBQTTxicj48Yj5Ubzo8L2I+Jm5i c3A7bXVsdGlwYXRodGNwPGJyPjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBbbXVsdGlwYXRodGNw XSBoYXdhaWkgbWVldGluZzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW47bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPkhpLDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz5XZSBo YXZlbid0IHJlY2VpdmVkIGFueSByZXF1ZXN0cyBvciBzdWdnZXN0aW9ucyBzbyBmYXIuLi4mbmJz cDsgV2UnbGwgd2FpdCBhIGJpdCBtb3JlLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPi0tPC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04nPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OlNpbVN1bjttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+WW9zaGkgJmFtcDsgUGhpbDwvc3Bhbj48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04nPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWls eTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPk9uIE1vbiwgT2N0IDEzLCAyMDE0 IGF0IDEyOjEwIEFNLCBZb3NoaWZ1bWkgTmlzaGlkYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pc2hp ZGFAc2ZjLndpZGUuYWQuanAiIHRhcmdldD0iX2JsYW5rIj5uaXNoaWRhQHNmYy53aWRlLmFkLmpw PC9hPiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW47bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz5IaSwmbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz50aGVyZSBhcmUgc29tZSBkaXNjdXNzaW9ucyBiZXR3 ZWVuIGNoYWlycyBhbmQgQUQgd2hldGhlciB3ZSB3aWxsIGhhdmUgYSBtZWV0aW5nIGluIEhhd2Fp aSBhcyB3ZSBmZWVsIHRoYXQgbm90IHNvIG1hbnkgZm9sa3MgaGF2ZSBhIHBsYW4gdG8gZ28gdGhl cmUsIGJ1dCBpbiB0aGUgZW5kLCB3ZSBnb3QgYSAxLjUgaG91ciBtZWV0aW5nIHNsb3QgYXQgMTE6 NTAtMTM6MjAgRnJpZGF5LCBOb3ZlbWJlciAxNC48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Jz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1p bHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz5BbHRob3VnaCB0aGlzIG1pZ2h0 IG5vdCBiZSB0aGUgYmVzdCBvcHBvcnR1bml0eSBhcyB3ZSBtaWdodCBub3QgaGF2ZSBlbm91Z2gg cGVvcGxlLCBpdCBtYXkgYmUgdXRpbGl6ZWQgdG8gc2hhcmUgc29tZSAoZXZlbiBwcmUtbWF0dXJl ZCkgaWRlYXMgb3IgZXhjaGFuZ2Ugc29tZSBpbmZvIG9yIGJ1aWxkIG5ldHdvcmtzLjwvc3Bhbj48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW47bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPklmIHlvdSdyZSBpbnRlcmVzdGVkIGluIHByZXNlbnRpbmcg c29tZXRoaW5nIG9yIHlvdSBoYXZlIHNvbWUgc3VnZ2VzdGlvbnMgZm9yIHRoZSBhZ2VuZGEsIHBs ZWFzZSBsZXQgdXMga25vdy48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OlNpbVN1bjtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz5PVE9ILCBpZiB0aGVyZSdzIGxpdHRsZSBpbnRlcmVz dCBmb3IgdGhlIHNsb3QsIHdlIHdpbGwgdGhpbmsgYWJvdXQgcmV0dXJuaW5nIHRoZSBzbG90Ljwv c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW47 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04nPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW47bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+LS08L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOJz5Zb3NoaSAmYW1wOyBQaGlsPC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTic+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW47bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIjttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+bXVsdGlwYXRodGNwIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJt YWlsdG86bXVsdGlwYXRodGNwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXVsdGlwYXRodGNw QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL211bHRpcGF0aHRjcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXVsdGlwYXRodGNwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_80C0017654A043479F53C41112BE847687D6AFF672WP40046corpad_-- From nobody Sat Oct 25 16:36:46 2014 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 D66ED1A1AC6 for ; Sat, 25 Oct 2014 16:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.615 X-Spam-Level: *** X-Spam-Status: No, score=3.615 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, 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 mzdge8R1sFS2 for ; Sat, 25 Oct 2014 16:36:42 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D731A1A0F for ; Sat, 25 Oct 2014 16:36:42 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DC04D27816A for ; Sun, 26 Oct 2014 08:36:39 +0900 (JST) Received: by mail-wg0-f51.google.com with SMTP id b13so3308907wgh.22 for ; Sat, 25 Oct 2014 16:36:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.94.132 with SMTP id dc4mr14297644wjb.56.1414280197440; Sat, 25 Oct 2014 16:36:37 -0700 (PDT) Received: by 10.194.3.82 with HTTP; Sat, 25 Oct 2014 16:36:37 -0700 (PDT) In-Reply-To: <80C0017654A043479F53C41112BE847687D6AFF672@WP40046.corp.ads> References: <7700F7D7-80E3-4B98-B285-7A146E502245@yegin.org> <80C0017654A043479F53C41112BE847687D6AFF672@WP40046.corp.ads> Date: Sat, 25 Oct 2014 16:36:37 -0700 Message-ID: From: Yoshifumi Nishida To: Jordan Melzer Content-Type: multipart/alternative; boundary=047d7bb044f2c80cb6050647c430 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/d4WbTabDUYRdqk4vw2SXfvDCXzQ Cc: multipathtcp Subject: Re: [multipathtcp] hawaii 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: Sat, 25 Oct 2014 23:36:45 -0000 --047d7bb044f2c80cb6050647c430 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jordan, OK. Thanks. I will send an instruction for remote presentation later. It seems that we have around 3 presentations for mptcp proxy. Let me know if you have some other requests or suggestions. Thanks, -- Yoshi On Fri, Oct 24, 2014 at 6:12 AM, Jordan Melzer wrote: > If it=E2=80=99s okay to present remotely, I could give a brief presentati= on on the > TELUS / Algonquin College proxy implementation and experience. It will b= e > brief because we built a proxy by running an existing TCP proxy (Mallory) > on a machine with an MPTCP enabled kernel (UC Louvain), and it worked. > > > > *From:* multipathtcp [mailto:multipathtcp-bounces@ietf.org] *On Behalf Of > *Yoshifumi Nishida > *Sent:* October 21, 2014 02:14 AM > *To:* Alper Yegin > *Cc:* multipathtcp > > *Subject:* Re: [multipathtcp] hawaii meeting > > > > Hi Weixinpeng, Alper, > > > > Thanks for the response. Sounds a good idea. > > Does anyone want to present something on this topic? > > > > Thanks, > > -- > > Yoshi > > > > On Mon, Oct 20, 2014 at 10:34 PM, Alper Yegin > wrote: > > Yes, continuing discussions on MPTCP proxy would be good. > > > > On Oct 21, 2014, at 4:11 AM, Weixinpeng wrote: > > > > Hi Yoshi, > > I think we should have a topic discussion on MPTCP proxy related issues, > and it would be better if we could have some kind of consensus on it. > > Thanks! > > Best Regards, > > Xinpeng > > > > *From:* multipathtcp [mailto:multipathtcp-bounces@ietf.org] *On Behalf > Of *Yoshifumi Nishida > *Sent:* Friday, October 17, 2014 3:23 PM > *To:* multipathtcp > *Subject:* Re: [multipathtcp] hawaii meeting > > > > Hi, > > We haven't received any requests or suggestions so far... We'll wait a > bit more. > > -- > > Yoshi & Phil > > > > On Mon, Oct 13, 2014 at 12:10 AM, Yoshifumi Nishida < > nishida@sfc.wide.ad.jp> wrote: > > Hi, > > there are some discussions between chairs and AD whether we will have a > meeting in Hawaii as we feel that not so many folks have a plan to go > there, but in the end, we got a 1.5 hour meeting slot at 11:50-13:20 > Friday, November 14. > > > > Although this might not be the best opportunity as we might not have > enough people, it may be utilized to share some (even pre-matured) ideas = or > exchange some info or build networks. > > If you're interested in presenting something or you have some suggestions > for the agenda, please let us know. > > > > OTOH, if there's little interest for the slot, we will think about > returning the slot. > > > > Regards, > > -- > > Yoshi & Phil > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > > > > --047d7bb044f2c80cb6050647c430 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jordan,

OK. Thanks. I will send an i= nstruction for remote presentation later.
It seems that we have a= round 3 presentations for mptcp proxy.
Let me know if you have so= me other requests or suggestions.

Thanks,
--
Yoshi

On Fri, Oct 24, 2014 at 6:12 AM, Jordan Melzer <= ;Jordan.Melzer= @telus.com> wrote:

If it=E2=80=99s okay to present remotely, I could gi= ve a brief presentation on the TELUS / Algonquin College proxy implementati= on and experience.=C2=A0 It will be brief because we built a proxy by runni= ng an existing TCP proxy (Mallory) on a machine with an MPTCP enabled kerne= l (UC Louvain), and it worked.

=C2=A0

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: October 21, 2014 02:14 AM
To: = Alper Yegin
Cc: multipathtcp

Subject: Re: [multipathtcp] hawaii meeting

=C2=A0<= /p>

Hi Weixinpeng, Alper,

=

=C2=A0

Thanks for the response. Sounds a good idea.=C2=A0

<= /div>

Does anyone want to present something on t= his topic?

=C2=A0=

Thanks,

--

Yoshi

= =C2=A0

On Mon, Oct 20, 2014 at= 10:34 PM, Alper Yegin <alper.yegin@yegin.org> wrote:

Yes, continuing discussions on MPTCP proxy would be good= .

=C2=A0

On Oct 21, 2014, at 4:11 AM, Weixinp= eng wrote:

=C2=A0

Hi Yoshi,=

I think we should have a topic discussion on MPTCP proxy= related issues, and it would be better if we could have some kind of conse= nsus on it.<= /p>

Thanks!<= /p>

Best Regards,

Xinpeng

=C2=A0

From:=C2=A0multipat= htcp [mailto:multipathtcp-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Yoshi= fumi Nishida
Sent:=C2=A0Friday, October 17, 2014 3:23 PM
To= :=C2=A0multipathtcp
Subject:=C2=A0Re: [multipathtcp] hawaii m= eeting

=C2=A0<= u>

Hi,

We haven't received any r= equests or suggestions so far...=C2=A0 We'll wait a bit more.

--

Yoshi & Phil=

=C2=A0

On Mon, Oct 13, 2014 at 12:10 A= M, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:

Hi,=C2=A0

there are some discussions between chairs and AD whether we will have= a meeting in Hawaii as we feel that not so many folks have a plan to go th= ere, but in the end, we got a 1.5 hour meeting slot at 11:50-13:20 Friday, = November 14.=

=C2=A0=

Although this might not be the be= st opportunity as we might not have enough people, it may be utilized to sh= are some (even pre-matured) ideas or exchange some info or build networks.<= /span>

If you're interested in presenting something or you have som= e suggestions for the agenda, please let us know.

=C2=A0<= span style=3D"font-family:SimSun">

OTOH, if there's little interest for the slot, we will think about = returning the slot.=

=C2=A0

<= span lang=3D"EN-US" style=3D"font-family:SimSun">Regards,

--

=

Yoshi & Phil

=C2=A0

=C2=A0<= span style=3D"font-family:SimSun">

_____= __________________________________________
multipathtcp mailing list
= multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp

<= /u>=C2=A0

=C2=A0<= u>


--047d7bb044f2c80cb6050647c430-- From nobody Sun Oct 26 10:43:53 2014 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 0716A1A0276 for ; Sun, 26 Oct 2014 10:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 NTQvukHka84y for ; Sun, 26 Oct 2014 10:43:44 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8441A0072 for ; Sun, 26 Oct 2014 10:43:43 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sun, 26 Oct 2014 17:43:41 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sun, 26 Oct 2014 17:43:40 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Sun, 26 Oct 2014 17:43:40 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.158.61]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9QHhc0X012800; Sun, 26 Oct 2014 17:43:39 GMT Message-ID: <201410261743.s9QHhc0X012800@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 26 Oct 2014 17:37:29 +0000 To: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/aKF6392nfjektfEBahHH85izphY Cc: multipathtcp@ietf.org Subject: [multipathtcp] Nits in rfc6824bis-02 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: Sun, 26 Oct 2014 17:43:51 -0000 Alan, Costin, Mark, Olivier, While refreshing my knowledge of MPTCP I came across the following nits in draft-ietf-mptcp-rfc6824bis-02. Apologies if these have already been pointed out - I'm not following the list closely. The phrase 'TCP option' is sometimes used where 'MPTCP option' or just 'option' would be more appropriate. Eg: * S.3.1: the MP_CAPABLE TCP option * S.3.2: Join Connection (MP_JOIN) TCP option These various TCP options fit together... * S.3.4.1 The Add Address (ADD_ADDR2) TCP option and so on... S.3.6: s/the subflow SHOULD be treated as broken as closed with a RST/ /the subflow SHOULD be treated as broken and closed with a RST/ S.8 s/ADD_ADDR22/ /ADD_ADDR2/ (twice) Cheers Bob ________________________________________________________________ Bob Briscoe, BT From nobody Sun Oct 26 21:25:03 2014 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 731841A6FB4 for ; Sun, 26 Oct 2014 21:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.611 X-Spam-Level: X-Spam-Status: No, score=0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, 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 sxdHtgB_pvf0 for ; Sun, 26 Oct 2014 21:25:00 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 6B3E71A1BBE for ; Sun, 26 Oct 2014 21:24:59 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app04-12004 (RichMail) with SMTP id 2ee4544dc91a850-c49e5; Mon, 27 Oct 2014 12:24:58 +0800 (CST) X-RM-TRANSID: 2ee4544dc91a850-c49e5 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.43.66]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee5544dc919b69-a8be3; Mon, 27 Oct 2014 12:24:58 +0800 (CST) X-RM-TRANSID: 2ee5544dc919b69-a8be3 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: Date: Mon, 27 Oct 2014 12:25:04 +0800 Message-ID: <01a901cff19d$fbb50de0$f31f29a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/xmuvHp1aq45CyRJ66JxQ++/Wr/AAAkPfw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/cS6vVg9LKIVJclGr-5JSAGXH89c Subject: [multipathtcp] FW: New Version Notification for draft-deng-mptcp-proxy-01.txt 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: Mon, 27 Oct 2014 04:25:01 -0000 Hi all, A minor update to the MPTCP proxy draft is uploaded.=20 Your review and comments are very welcome. Lingli > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 27, 2014 12:03 PM > To: Tao Sun; Mohamed Boucadair; Dapeng Liu; Gregory Cauchie; Deng = Lingli; > Gregory Cauchie; Tao Sun; Lingli Deng; Mohamed Boucadair; Dapeng Liu > Subject: New Version Notification for draft-deng-mptcp-proxy-01.txt >=20 >=20 > A new version of I-D, draft-deng-mptcp-proxy-01.txt > has been successfully submitted by Lingli Deng and posted to the > IETF repository. >=20 > Name: draft-deng-mptcp-proxy > Revision: 01 > Title: Use-cases and Requirements for MPTCP Proxy in ISP Networks > Document date: 2014-10-24 > Group: Individual Submission > Pages: 18 > URL: > http://www.ietf.org/internet-drafts/draft-deng-mptcp-proxy-01.txt > Status: = https://datatracker.ietf.org/doc/draft-deng-mptcp-proxy/ > Htmlized: http://tools.ietf.org/html/draft-deng-mptcp-proxy-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-deng-mptcp-proxy-01 >=20 > Abstract: > This document presents the use-cases and identifies requirements = for > ISP deployed MPTCP proxies for both Fixed and Mobile networks. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Mon Oct 27 01:29:18 2014 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 B76F81A8A71 for ; Mon, 27 Oct 2014 01:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zfFO16-5oXK9 for ; Mon, 27 Oct 2014 01:29:10 -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 A890F1A8A62 for ; Mon, 27 Oct 2014 01:29:10 -0700 (PDT) Received: from mbpobo-2.dhcp.info.ucl.ac.be (mbpobo-2.dhcp.info.ucl.ac.be [130.104.228.16]) (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 E726C198417 for ; Mon, 27 Oct 2014 09:28:55 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be E726C198417 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1414398535; bh=hGWr+vmf1k4//xjsvtud+m54/4A4qDq/JwcX8WtZkLg=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CCQ7FUZNZqyLpcDOVphcYpZfOc1uWS1/sOvJ07jU76Bot+LE5yeF+q0zPY4BxFf88 iyNjeXIdl8yKFoEWGdZSK5B044yqmxlLDbKfUJpqRKXq4QCX5vMNQxjzi56pV25StH 8t5AaH+GjBIYd5w1Pk/zvQDk+uFC5EFnscNwwttY= Message-ID: <544E0246.7020508@uclouvain.be> Date: Mon, 27 Oct 2014 09:28:54 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: multipathtcp References: <20141026180007.4251.21705.idtracker@ietfa.amsl.com> In-Reply-To: <20141026180007.4251.21705.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141026180007.4251.21705.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; 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: E726C198417.A18CD X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/15IursX2v4lry-ODWGwoGl17ZI8 Subject: [multipathtcp] Fwd: New Version Notification for draft-bonaventure-mptcp-timestamp-00.txt 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: Mon, 27 Oct 2014 08:29:13 -0000 FYI The main motivation for this draft is to initiate a discussion among MPTCP implementers on the usage of the RFC7323 timestamp option by Multipath TCP. Comments are welcome Olivier -------- Original Message -------- Subject: New Version Notification for draft-bonaventure-mptcp-timestamp-00.txt Date: Sun, 26 Oct 2014 11:00:07 -0700 From: To: Olivier Bonaventure , "Olivier Bonaventure" A new version of I-D, draft-bonaventure-mptcp-timestamp-00.txt has been successfully submitted by Olivier Bonaventure and posted to the IETF repository. Name: draft-bonaventure-mptcp-timestamp Revision: 00 Title: Multipath TCP timestamp option Document date: 2014-10-29 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-timestamp-00.txt Status: https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-timestamp/ Htmlized: http://tools.ietf.org/html/draft-bonaventure-mptcp-timestamp-00 Abstract: The TCP timestamps defined in [RFC1323] were designed to improve round-trip-time estimations and provide protection against wrapped sequence numbers (PAWS). This draft clarifies the utilisation of timestamps by Multipath TCP and proposes a new timestamp option that better suits the needs of Multipath TCP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat . From nobody Mon Oct 27 01:59:42 2014 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 3C0B91A8A8A for ; Mon, 27 Oct 2014 01:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UqrvDSi8-T7S for ; Mon, 27 Oct 2014 01:59:39 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8B91A6F82 for ; Mon, 27 Oct 2014 01:59:39 -0700 (PDT) Received: from mbpobo-2.dhcp.info.ucl.ac.be (mbpobo-2.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 5EE3D18349C for ; Mon, 27 Oct 2014 09:59:34 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 5EE3D18349C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1414400374; bh=S6d0Zm+Pv+z7hHWMigKDetXARDqYMsQSBfWTbG86D8g=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MjBHjJaGl+HxT6KOgx0bsffVKTj+q7nV6yIMbnbcz1ydbkdlGLfnRbX9P4G0QTDdI Dr8LUSe1O+rxJPNPAQ4UJw3pBVSGJqEBp7bm2YgkUZBo2+ghRcRhonob3EQy86xwEW LQTopECaz7Nm11TaVFt9gkKWCF51JVbroTIhsGvo= Message-ID: <544E0975.5060809@uclouvain.be> Date: Mon, 27 Oct 2014 09:59:33 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: multipathtcp References: <20141027084642.10267.56924.idtracker@ietfa.amsl.com> In-Reply-To: <20141027084642.10267.56924.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141027084642.10267.56924.idtracker@ietfa.amsl.com> 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: 5EE3D18349C.A1843 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/IphSqMmkghZQTz5LzxsNjJZHSp0 Subject: [multipathtcp] MPTLS : Making TLS and Multipath TCP stronger together 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: Mon, 27 Oct 2014 08:59:41 -0000 FYI, The submitted draft shows that by better integrating Multipath TCP and TLS together, it is possible to improve the security and reliability of both protocols. MPTLS could be used by all TLS applications and could also serve as a basis for the TCPINC work. I won't be able to attend the Hawaii meeting, but comments and discussion on the list are of course more than welcome. Olivier -------- Original Message -------- A new version of I-D, draft-bonaventure-mptcp-tls-00.txt has been successfully submitted by Olivier Bonaventure and posted to the IETF repository. Name: draft-bonaventure-mptcp-tls Revision: 00 Title: MPTLS : Making TLS and Multipath TCP stronger together Document date: 2014-10-27 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-tls-00.txt Status: https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-tls/ Htmlized: http://tools.ietf.org/html/draft-bonaventure-mptcp-tls-00 Abstract: Multipath TCP and the Transport Layer Security (TLS) include several techniques that improve the reliability and the security of data transfers. In this document we propose Multipath TLS (MPTLS), a tighter coupling between TLS and Multipath TCP that provides improved security and reliability in the presence of adversaries. MPTLS would the resilience of existing TLS applications to attacks. It could also serve as a basis for the TCP extension that is being discussed within the TCPINC working group to provide unauthenticated encryption and integrity protection of TCP streams. From nobody Mon Oct 27 08:56:07 2014 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 20DC41A88ED for ; Mon, 27 Oct 2014 08:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N47qBFa2PzDa for ; Mon, 27 Oct 2014 08:56:03 -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 2C1491A88EF for ; Mon, 27 Oct 2014 08:56:03 -0700 (PDT) Received: from mbpobo-2.dhcp.info.ucl.ac.be (mbpobo-2.dhcp.info.ucl.ac.be [130.104.228.16]) (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 A823519807B; Mon, 27 Oct 2014 16:55:54 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be A823519807B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1414425354; bh=JrAgbXyaUozRUodphe9E9YoZKZjChtQ5jUBAGJ7OhpY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=sixhCtQ5J9i8Lv4rfJJpsHT22/UPT9O5tb/n8jvHIej7hCbFkTnApj+SzAZ1Wi+mv wIpsN2cJO/o/5KddtIIvE/0zknFU9J+8XMd7DdOlQo9hcnppr5mmv9hhmnDHp7Kaj6 9RE8AVNWQShvIm5r8h7ggUN9YPETT4IcLgpVqEFY= Message-ID: <544E6B09.5000200@uclouvain.be> Date: Mon, 27 Oct 2014 16:55:53 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yoshifumi Nishida , Jordan Melzer References: <7700F7D7-80E3-4B98-B285-7A146E502245@yegin.org> <80C0017654A043479F53C41112BE847687D6AFF672@WP40046.corp.ads> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: A823519807B.AFEF6 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/Alk3qVV7hOFUPjuVPVLPA-f1Kho Cc: multipathtcp Subject: Re: [multipathtcp] hawaii meeting 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: Mon, 27 Oct 2014 15:56:05 -0000 Yoshi, > > OK. Thanks. I will send an instruction for remote presentation later. > It seems that we have around 3 presentations for mptcp proxy. > Let me know if you have some other requests or suggestions. Gregory Detal has accumulated a lot of experience in designing and implementing efficient Multipath TCP proxies. A paper describing such proxies has been presented in 2013 at the Hotmiddlebox workshop : Gregory Detal, Christoph Paasch and Olivier Bonaventure, "Multipath in the Middle(Box)", CoNEXT workshop HotMiddlebox, December 2013 http://inl.info.ucl.ac.be/publications/multipath-middlebox Since then, Gregory has improved the software and developed new use cases. If there is a possibility for remote participation, he or I could present how this proxy works and the use cases that it enables. Best regards, Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Mon Oct 27 14:25:08 2014 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 274621AD585; Mon, 27 Oct 2014 14:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 DCw1YY4n5h2J; Mon, 27 Oct 2014 14:24:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4B91AD55B; Mon, 27 Oct 2014 14:24:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027212406.24805.28448.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 14:24:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/ofXPOinK6d05TMoj3MMo-_XBaRc Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-03.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:24:44 -0000 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 : TCP Extensions for Multipath Operation with Multiple Addresses Authors : Alan Ford Costin Raiciu University Politehnica of Bucharest Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-rfc6824bis-03.txt Pages : 67 Date : 2014-10-27 Abstract: TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document obsoletes RFC6824 [5] through clarifications and modifications, primarily driven by deployment experience. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-rfc6824bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 14:37:50 2014 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 9F1B31A000C for ; Mon, 27 Oct 2014 14:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 WxnV7cEFcO0N for ; Mon, 27 Oct 2014 14:37:39 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FDB1AD659 for ; Mon, 27 Oct 2014 14:35:46 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so7741796wiv.14 for ; Mon, 27 Oct 2014 14:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=HoLGvvdDiOEIXbIuzwTzTmtEpAMLJwgJJzK8j+zy4tU=; b=P6zDYf0EjzPvW0T9nwjXlymWUJg3E/9vgSTilG1qz838/XoZNfQm5JnpySIAFGnczx Wqv0HqSNSTnK+GH2sK2x0+AUG00vHrqoAlLM0juKBatvpZrAFnfWgQeoro/4+a5zWFcU MHiwQbAXA/oHMsuk5XQ/bJ27RmcXGGbhS/Csk54B0UFuyEnMyfi993j7vWagY5cR3Por 1rKPEn8KB9jdbdU2rgSXYfgnBsydQlT35m/DIj7eVle3jid/FRHJ2Ltgwn6UKjIQKYef wblcXOcjjJjSWadeqhWCqMHgkEw9RX+v4rXrv+G8GFBNI8ILLl9trJhZ7DqzWRmjRSmV I9lw== X-Received: by 10.195.12.162 with SMTP id er2mr25448127wjd.42.1414445745382; Mon, 27 Oct 2014 14:35:45 -0700 (PDT) Received: from [192.168.0.9] (cpc5-acto4-2-0-cust918.4-2.cable.virginm.net. [86.13.119.151]) by mx.google.com with ESMTPSA id w13sm16919256wjq.29.2014.10.27.14.35.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 14:35:44 -0700 (PDT) From: Alan Ford Content-Type: multipart/alternative; boundary="Apple-Mail=_E8A1F37D-D7C9-400B-AB64-6D5137201760" Date: Mon, 27 Oct 2014 21:35:43 +0000 References: <20141027212407.24805.19174.idtracker@ietfa.amsl.com> To: multipathtcp@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/EgQPL5DzPwW2rLDfR32p48CFs4U Subject: [multipathtcp] Fwd: New Version Notification for draft-ietf-mptcp-rfc6824bis-03.txt 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: Mon, 27 Oct 2014 21:37:46 -0000 --Apple-Mail=_E8A1F37D-D7C9-400B-AB64-6D5137201760 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, We have just submitted a new version of the rfc6824bis draft. This is = taking into account feedback gleaned during IETF90, in particular = adopting the MPTCP TCP RST semantics based on what was proposed in = http://tools.ietf.org/html/draft-bonaventure-mptcp-rst-00, as well as = some clarifications from the deployment experience. Alan Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-mptcp-rfc6824bis-03.txt > Date: 27 October 2014 21:24:07 GMT > To: Alan Ford , University Politehnica of = Bucharest , "Mark J. Handley" = , "Alan Ford" , "Olivier = Bonaventure" , Costin Raiciu = , Mark Handley , = "Costin Raiciu" , Olivier Bonaventure = >=20 >=20 > A new version of I-D, draft-ietf-mptcp-rfc6824bis-03.txt > has been successfully submitted by Alan Ford and posted to the > IETF repository. >=20 > Name: draft-ietf-mptcp-rfc6824bis > Revision: 03 > Title: TCP Extensions for Multipath Operation with = Multiple Addresses > Document date: 2014-10-27 > Group: mptcp > Pages: 67 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-mptcp-rfc6824bis-03.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-rfc6824bis-03 >=20 > Abstract: > TCP/IP communication is currently restricted to a single path per > connection, yet multiple paths often exist between peers. The > simultaneous use of these multiple paths for a TCP/IP session would > improve resource usage within the network and, thus, improve user > experience through higher throughput and improved resilience to > network failure. >=20 > Multipath TCP provides the ability to simultaneously use multiple > paths between peers. This document presents a set of extensions to > traditional TCP to support multipath operation. The protocol offers > the same type of service to applications as TCP (i.e., reliable > bytestream), and it provides the components necessary to establish > and use multiple TCP flows across potentially disjoint paths. >=20 > This document obsoletes RFC6824 [5] through clarifications and > modifications, primarily driven by deployment experience. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_E8A1F37D-D7C9-400B-AB64-6D5137201760 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

We have just submitted a new version of the = rfc6824bis draft. This is taking into account feedback gleaned during = IETF90, in particular adopting the MPTCP TCP RST semantics based on what = was proposed in http://= tools.ietf.org/html/draft-bonaventure-mptcp-rst-00, as well as some = clarifications from the deployment = experience.

Alan

Begin = forwarded message:

Subject: New Version Notification for = draft-ietf-mptcp-rfc6824bis-03.txt
Date: 27 October 2014 = 21:24:07 GMT
To: Alan Ford <alan.ford@gmail.com>, = University Politehnica of Bucharest <costin.raiciu@cs.pub.ro>, = "Mark J. Handley" <m.handley@cs.ucl.ac.uk>, = "Alan Ford" <alan.ford@gmail.com>, = "Olivier Bonaventure" <Olivier.Bonaventure@uclou= vain.be>, Costin Raiciu <costin.raiciu@cs.pub.ro>, = Mark Handley <m.handley@cs.ucl.ac.uk>, = "Costin Raiciu" <costin.raiciu@cs.pub.ro>, = Olivier Bonaventure <olivier.bonaventure@uclou= vain.be>


A new version of I-D, = draft-ietf-mptcp-rfc6824bis-03.txt
has been successfully submitted by = Alan Ford and posted to the
IETF repository.

Name: = draft-ietf-mptcp-rfc6824bis
Revision: = 03
Title: TCP Extensions for Multipath = Operation with Multiple Addresses
Document date: = 2014-10-27
Group: mptcp
Pages: = 67
URL: =            http://www.ietf.org/internet-drafts/draft-ietf-mptcp-rfc6824bis-03.t= xt
Status:         htt= ps://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/
Htmlized= :       http://= tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-03
Diff: =           http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-rfc6824bis-03
=
Abstract:
  TCP/IP communication is currently = restricted to a single path per
  connection, yet multiple = paths often exist between peers.  The
  simultaneous = use of these multiple paths for a TCP/IP session would
=   improve resource usage within the network and, thus, improve = user
  experience through higher throughput and improved = resilience to
  network failure.

=   Multipath TCP provides the ability to simultaneously use = multiple
  paths between peers.  This document = presents a set of extensions to
  traditional TCP to = support multipath operation.  The protocol offers
=   the same type of service to applications as TCP (i.e., = reliable
  bytestream), and it provides the components = necessary to establish
  and use multiple TCP flows across = potentially disjoint paths.

  This document obsoletes = RFC6824 [5] through clarifications and
  modifications, = primarily driven by deployment experience.




Please = note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_E8A1F37D-D7C9-400B-AB64-6D5137201760-- From nobody Mon Oct 27 21:48:21 2014 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 B1EC31A1B70 for ; Mon, 27 Oct 2014 21:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, 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 F1G5HCgojgPH for ; Mon, 27 Oct 2014 21:48:17 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AAF1A1B6D for ; Mon, 27 Oct 2014 21:48:16 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6BE292781AD for ; Tue, 28 Oct 2014 13:48:14 +0900 (JST) Received: by mail-wi0-f178.google.com with SMTP id q5so412422wiv.5 for ; Mon, 27 Oct 2014 21:48:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.110.4 with SMTP id hw4mr997213wjb.102.1414471691416; Mon, 27 Oct 2014 21:48:11 -0700 (PDT) Received: by 10.194.3.82 with HTTP; Mon, 27 Oct 2014 21:48:11 -0700 (PDT) In-Reply-To: <544E6B09.5000200@uclouvain.be> References: <7700F7D7-80E3-4B98-B285-7A146E502245@yegin.org> <80C0017654A043479F53C41112BE847687D6AFF672@WP40046.corp.ads> <544E6B09.5000200@uclouvain.be> Date: Mon, 27 Oct 2014 21:48:11 -0700 Message-ID: From: Yoshifumi Nishida To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=047d7b87451cb63f430506745aa3 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/xoFl4tp51zValWISFJFGBHA6Riw Cc: multipathtcp Subject: Re: [multipathtcp] hawaii 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, 28 Oct 2014 04:48:19 -0000 --047d7b87451cb63f430506745aa3 Content-Type: text/plain; charset=UTF-8 Hi Olivier, OK. Sounds good. I've already asked meetecho team to support remote presentations for the meeting. I'll send you some instructions later. Thanks, -- Yoshi On Mon, Oct 27, 2014 at 8:55 AM, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > Yoshi, > >> >> OK. Thanks. I will send an instruction for remote presentation later. >> It seems that we have around 3 presentations for mptcp proxy. >> Let me know if you have some other requests or suggestions. >> > > Gregory Detal has accumulated a lot of experience in designing and > implementing efficient Multipath TCP proxies. A paper describing such > proxies has been presented in 2013 at the Hotmiddlebox workshop : > > Gregory Detal, Christoph Paasch and Olivier Bonaventure, "Multipath in the > Middle(Box)", CoNEXT workshop HotMiddlebox, December 2013 > > http://inl.info.ucl.ac.be/publications/multipath-middlebox > > Since then, Gregory has improved the software and developed new use cases. > If there is a possibility for remote participation, he or I could present > how this proxy works and the use cases that it enables. > > Best regards, > > > Olivier > > > -- > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be > --047d7b87451cb63f430506745aa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

OK. Sounds good. I've a= lready asked meetecho team to support remote presentations for the meeting.=
I'll send you some instructions later.

<= div>Thanks,
--
Yoshi


On Mon, Oct 27, 2014 at 8:55 AM, Oliv= ier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:
Yoshi,

OK. Thanks. I will send an instruction for remote presentation later.
It seems that we have around 3 presentations for mptcp proxy.
Let me know if you have some other requests or suggestions.

 Gregory Detal has accumulated a lot of experience in designing and implemen= ting efficient Multipath TCP proxies. A paper describing such proxies has b= een presented in 2013 at the Hotmiddlebox workshop :

Gregory Detal, Christoph Paasch and Olivier Bonaventure, "Multipath in= the Middle(Box)", CoNEXT workshop HotMiddlebox, December 2013

http://inl.info.ucl.ac.be/publications/multipath-middlebox

Since then, Gregory has improved the software and developed new use cases. = If there is a possibility for remote participation, he or I could present h= ow this proxy works and the use cases that it enables.

Best regards,


Olivier


--
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

--047d7b87451cb63f430506745aa3-- From nobody Tue Oct 28 20:53:43 2014 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 013141A6F3C for ; Tue, 28 Oct 2014 20:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.12 X-Spam-Level: *** X-Spam-Status: No, score=3.12 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 4x1nQxSoDAJD for ; Tue, 28 Oct 2014 20:53:39 -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 53FBF1A6F3A for ; Tue, 28 Oct 2014 20:53:38 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D1C302780E6 for ; Wed, 29 Oct 2014 12:53:36 +0900 (JST) Received: by mail-wi0-f170.google.com with SMTP id q5so528802wiv.3 for ; Tue, 28 Oct 2014 20:53:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.239.10 with SMTP id vo10mr9369315wjc.29.1414554814540; Tue, 28 Oct 2014 20:53:34 -0700 (PDT) Received: by 10.194.3.82 with HTTP; Tue, 28 Oct 2014 20:53:34 -0700 (PDT) Date: Tue, 28 Oct 2014 20:53:34 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a11c28ecc3c73b3050687b542 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/bCs3SpqVtzbe8PSLHT7xHp09eOU Subject: [multipathtcp] draft agenda for hawaii 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: Wed, 29 Oct 2014 03:53:41 -0000 --001a11c28ecc3c73b3050687b542 Content-Type: text/plain; charset=UTF-8 Hi, I've just updated draft agenda for hawaii meeting. Please note this is still preliminary. Please check the following URL and let us know if you have comments or suggestions. http://www.ietf.org/proceedings/91/agenda/agenda-91-mptcp Regards, -- Yoshi & Phil --001a11c28ecc3c73b3050687b542 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I've just updated draft agenda = for hawaii meeting. Please note this is still preliminary.=C2=A0
= Please check the following URL and let us know if you have comments or sugg= estions.


Regards,
--
Yoshi & Phil
--001a11c28ecc3c73b3050687b542-- From nobody Wed Oct 29 21:55:36 2014 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 127CD1AD008 for ; Wed, 29 Oct 2014 21:55:35 -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 LnDAgblP_dIi for ; Wed, 29 Oct 2014 21:55:33 -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 ADF891AD00A for ; Wed, 29 Oct 2014 21:55:32 -0700 (PDT) Received: from [136.186.229.154] (nwilliams-laptop.caia.swin.edu.au [136.186.229.154]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id s9U4tRvX009636; Thu, 30 Oct 2014 15:55:28 +1100 Message-ID: <5451C4B6.2050209@swin.edu.au> Date: Thu, 30 Oct 2014 15:55:18 +1100 From: Nigel Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be, multipathtcp References: <20141026180007.4251.21705.idtracker@ietfa.amsl.com> <544E0246.7020508@uclouvain.be> In-Reply-To: <544E0246.7020508@uclouvain.be> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/1Kg1E-d0RGZ2_MMoOFL0xqv0kxo Subject: Re: [multipathtcp] Fwd: New Version Notification for draft-bonaventure-mptcp-timestamp-00.txt 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, 30 Oct 2014 04:55:35 -0000 Hi Olivier, Just had a couple questions to get a better understanding of how an implementation might behave. Is the expectation that an MPTCP-TS option (either the sender-timestamp or echo) be included on outgoing packets whenever there is space for it? (and only withheld if there is say a larger MPTCP option or we require an additional SACK block etc) At the end of Section 3 there is the following note: "The MPTCP TS may also be used to verify that a subflow remains active by forcing a remote host to reply to an MPTCP segment without sending data." I assume this is done by sending a MPTCP-TS option with E unset to elicit an echo? If this is the case, since replying with a timestamp echo is a "SHOULD" behaviour, how much can we rely on this to indicate a subflow's status?. Perhaps you could clarify in case I've misunderstood. cheers, nigel On 27/10/14 19:28, Olivier Bonaventure wrote: > FYI > > The main motivation for this draft is to initiate a discussion among > MPTCP implementers on the usage of the RFC7323 timestamp option by > Multipath TCP. > > Comments are welcome > > Olivier > > > -------- Original Message -------- > Subject: New Version Notification for > draft-bonaventure-mptcp-timestamp-00.txt > Date: Sun, 26 Oct 2014 11:00:07 -0700 > From: > To: Olivier Bonaventure , "Olivier > Bonaventure" > > > A new version of I-D, draft-bonaventure-mptcp-timestamp-00.txt > has been successfully submitted by Olivier Bonaventure and posted to the > IETF repository. > > Name: draft-bonaventure-mptcp-timestamp > Revision: 00 > Title: Multipath TCP timestamp option > Document date: 2014-10-29 > Group: Individual Submission > Pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-timestamp-00.txt > > Status: https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-timestamp/ > Htmlized: http://tools.ietf.org/html/draft-bonaventure-mptcp-timestamp-00 > > > Abstract: > The TCP timestamps defined in [RFC1323] were designed to improve > round-trip-time estimations and provide protection against wrapped > sequence numbers (PAWS). This draft clarifies the utilisation of > timestamps by Multipath TCP and proposes a new timestamp option that > better suits the needs of Multipath TCP. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > . > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp