From nobody Wed Aug 2 00:27:15 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CCE12EC3F for ; Wed, 2 Aug 2017 00:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 c2nD_8pyqTef for ; Wed, 2 Aug 2017 00:27:09 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1196D124234 for ; Wed, 2 Aug 2017 00:27:08 -0700 (PDT) Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 2 Aug 2017 08:27:03 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 2 Aug 2017 08:27:05 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Aug 2017 08:27:05 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Wed, 2 Aug 2017 08:27:05 +0100 From: To: Thread-Topic: Draft minutes from IETF-99 Thread-Index: AdMLYBre5HcS5whEQqWBOgyfr+rxGA== Date: Wed, 2 Aug 2017 07:27:04 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_c7794827744a4d4ebc51a22092b12394rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Draft minutes from IETF-99 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 07:27:14 -0000 --_000_c7794827744a4d4ebc51a22092b12394rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here are the draft minutes from Prague. Many thanks to our scribes - Dave, Ilpo and Brian - for the excellent notes= . Please send any updates and corrections. There are a couple of comments tha= t are missing (and my notes didn't help). Thanks Phil & Yoshi --- MP-TCP Session 1, Tuesday 15:50 scribes Dave Allan, Ilpo J=E4rvinen WG-status Implementation Updates - Chris Paasch - iOS and Linux Update "MPTCP in iOS11" slide Julius: who picks the mode, the user or developer? A: Developer. Julius: What does "only for developers" in one of the bullets mean? A: Can= only use it on a developer phone (with paid developer Apple account). Debashish: Wifi assist. if two interfaces on the cellular connection. A: We= do not support this. Debashish: we see some use cases where this is possible. Marcus: On iOS, do you plan on supporting proxies from the phone itself. A= : Can't comment. - Fabien Duchene - implementation results Alan: this is using vanilla 6824bis A: yes - other updates no update - hackathon news Quentin Alan: The general point is that the MP-TCP reset option was to carry additi= onal semantics. Timeout, again the reason codes had a general logic, if it = could be useful for an admin to analyze a problem, or analyze a bug. We don= 't necessarily need reason codes for everything. It has stuff like lack of = resources or ???, exactly the stuff we'd want to see for transient problems= . A: we can continue the discussion on mail. reaction to the experimental option: Alan: should be a fairly straightforw= ard. Julius: For the peanut gallery, what is the application of this? Alan: loca= l experiments - Alan Ford - RFC 6824bis Phil: A question to revisit on Friday, if there are any further suggestions= of extensions to the bis version before we declare victory. DO we have imp= lementations of all the new bits? Alan & Chris P: Linux is fine, but IOS is= not complete Alan: we have one implementation of everything. Discussion about hackathon MPTCP code availability, Chris P?: should all be= available once pushed out Phil: Is this sufficient to go standards track. Mirja: Up to the WG, will b= e justified in the shepherd's write up. Phil: Discuss timing a bit more on = Friday. Need a security area review to make sure they are happy. Proxies - Olivier, MPTCP Converters Jabber: When the converter translates TCP to MP-TCP, who decides to do this= , is it the client or the converter. A: do not understand the question. Alan Ford: How do we add another subflow to this? A: you have two MP-TCP co= nnections. If the client adds a subflow, one will be added between the conv= erter and the server. In many use cases you have a large numebr of connecti= ons. Alan: The presence of all this direct stuff tells you the server supp= orts MP-TCP, in the previous example it wasn't there. Vladimir: About TFO, isn't it dangerous to pass the TFO cookie to the clien= t vs. keep it in the converter? A: Depends on deployment. If you think of = a converter with a single IP address serving a lot of clients there may be = a problem. Pool of IP addresses, makes sense to send cookie back. Chris P. What happens if the converter changes its cookie, so there is a wr= ong cookie on the client side. A: you would not ack the message and have a= restart, normal TFO procedure. Julius: More comments after socks 6. Extensibility, what do you do with un= known TLV. A: there is an error TLV in the draft. Julius: Actual procedures= not described. You are only replying with a SYN-ACK when you get a SYN-ACK= from the other side. A: we want to test the connection to the server is wo= rking correctly. The connections do not always succeed. Some small changes = to be done in the stack interactions. Jabber: Only plain MP-TCP support is the client the middlebox. A: take that= question to the list. Mirja: this is an app layer protocol. And can be used for other things besi= des MP-TCP, so this may not be the right group. A: speaking as an individua= l. Mirja: Individual, but can change that anytime. Med: If we want this specific to MP-TCP, it is a matter of scoping the docu= ment. If it is a proxy just get the port number. Mirja: This is the right direction but not the right WG. Sounds a bit like = ICE (?). Oliver: This does match the charter item. Mirja: It does not need to be a W= G document, could still be elsewhere? Phil: We need to discuss perhaps in a= smaller venue. Alan Ford: This is very MP-TCP specific as far as app layer protocols go. I= t is in scope as an MP-TCP solution so IMO it is a good map with this WG. M= irja: Shop this around to other WGs. Julius: The use case comes from MP-TCP. Julius: This is a quite manageable document, written with an eye to impleme= ntability. There are no domain names, this is good. If this goes through o= ther WGs, will it still have this property. Oliver: Do not know. Do not want the converter to have to do a DNS lookup. = A side effect is that it becomes doable in kernels. Mirja: As an AD I'd recommend announcing this on the TSV AREA and TCP maili= ng lists. Phil: This is a nice to read document. I encourage everyone to read it. The= contributors really listened to the feedback from previous efforts. - Vladimir -SOCKS protocol version 6 Julius: In the late 90s, early 2000s, it was great to use SOCKS5, but we di= scovered one RTT was added to no benefit, it took 20 years to get that back= . Thank you. Need to stress how much Olivier and your drafts live in diffe= rent spaces. I think this has reason to exist even if Olivier's draft is al= so pursued. Generalizing often yields unmanagable protocols. I wonder if t= here is a way to talk to a proxy and know if a converter or SOCKS6. Vladimir: No sure how to answer that question. Should go like this. Hi, I w= ant to speak version X, server, I speak version Y. If client speaks SOCKS5 = then the server should speak SOCKS5. Olivier: We start with a fixed header with a version number. If the first t= ransaction had assigned ranges of version numbers for converter and for SOC= Ks then this would be possible. Julius: The initial truncation of data, needs some discussion, A: will amen= d the draft. Ben Schwartz: Similar proposal in DPRIV, ability to demux on first few byte= s is controversial as it constrains protocol design. Socks5 is incredibly w= idely deployed. Your proposal is an improvement. Agreeing on a new major ve= rsion number is close to being as big as that for HTTP. Probably should no= t be done in MP-TCP A: plan is to do this in INTAREA. Point out that the major improvement is in reduction of RTTs. Two use cases= , localhost, and remainder on a LAN with low latencies. SO the latency savi= ngs is useful, but only if SOCKs server is a large distance from you. The = TLS should be mandatory, or some other encryption. 4G and 5G have high dela= y, so going to get large RTT. Ben: Again funky security properties. None o= f the SOCKS5 clients today do any encryption between client and proxy. Plai= n text passwords. Outside a private LAN, TLS should be mandatory. Olivier: It does not use TFO, thanks for providing the code. AS for the exi= stence of HTTP proxies, there are other applications. Ben: HTTP connect is a superset of the functionality. Phil: Presenting this in INTAREA later in the week. A:Yes. MP-TCP Session 2, Friday 11:50 scribe Brian Trammell 3.3 Follow-up discussions from Tuesday's proxy discussions [15mins] Phil: SOCKS work will probably go forward in INTAREA. Converter discussion = was quite promising, people like the approach, need more time to read it. A= ny further comments in follow-up? Otherwise I suggest the authors rev the d= raft addressing comments, will work out which working group that should go = forward in. Discussion? 4. A security attack - Zhiyun Qian [15mins] See slide 8 in chair slides "MP-PRIO attack". MP-PRIO can be used by a MITM= to divert all traffic on to its own path, degrading to normal TCP. Removin= g address identifier from the option fixes this. Upcoming paper at ICNP. Alan Ford: MP-PRIO is a backup bit, predates the PRIO bit in the MP-JOIN, w= hich negates the point of this signal. Real question: is there a reason to = change the priority of a subflow from another subflow? Olivier: Attack important in practice. Multiple connection, can be used to = move all traffic to an untrusted network e.g. wifi. Don't know any implemen= ter that uses address identifier on MP-PRIO, so remove it. Keeps protocol s= imple and usable. Phil: Anyone unhappy with proposed solution, please hum. [Silence]. Okay wi= th it? [Tired hums]. Need more time? [Silence] 5. A proposal for MPTCP Robust session Establishment (MPTCP RobE) Markus Amend - "A proposal for MPTCP Robust session Establishment (MPTCP Ro= bE)" [15mins] Alan Ford: last slide covers everything I was going to say. Biggest killer = is no key in MP_CAPABLE. Semantics of the key simply aren't the same as wha= t you're using. Can't assume that two keys on the wire are the same identit= y. Most concerned as to how you see this working without the key, what's yo= ur way around it? Markus: Key missing in first SYN, can't use as identifier. Last ACK has bot= h keys available, then you can make the decision on the receiver side. Alan: Would not have been the same key B Markus: Host B answers with different keys B. Key B can be replaced... Alan: Security alarm bells. Can't point to just one thing. Very uncomfortab= le. Olivier: Good motivation, looking at Happy Eyeballs, though, this seems app= licable. Work in TAPS for racing, is the same problem. Application layer li= brary can do this, not application itself. Build a shim layer, then the app= -layer solution is easier. Markus: Then we have some overhead Olivier: But you can learn the network, and remember it, you don't have to = do this for every connection. Markus: Put it in the standard, not in the libraries, then it's general. Christoph: Important work. iOS uses the timer based approach. Independent o= f the transport layer protocol. Also, paths not equal. Markus: also delay. Brian: I like approach 1 but share Alan's concerns. No incremental deployme= nt, means you need negotiation, makes it more complex. Would that be done b= efore MP-QUIC is, for example? Approach 3, little bit more latency but less= complexity. Don't race in MPTCP layer; racing in two places is messy, and = you have to race v4v6 Anna: **missing** Separate robustness and latency 6. Proposal for a new Multipath TCP option Quentin De Coninck - "Every Millisecond Counts: Tuning Multipath TCP for In= teractive Applications on Smartphones" [15mins] Uma: Low latency very important, 5G etc. What is the gain you achieve with = you this approach over classical MPTCP? Quentin: Latency remains quite the same, but the cellular won't get establi= shed until you need to use it. Alan: Options in SYN before data, what are you signing with HMAC? No data u= ntil third ACK. What is DSN on slide 8? Are you sending data in the SYN? Quentin: Yes. Alan: Cool. Anna: Curious about impact on delay bet. detection to establish new subflow= and cost of setting it up. Magnitude important to see whole picture on lat= ency. Quentin: You see this with a low latency main net and a high latency second= net. When the nets are comparable, Phil: Is this a change to base protocol? Changes security properties? Quentin: Yes Christoph: Important to reduce handshake time. But when cell is down bringi= ng it back up again is very slow and in this case the handshake is lost in = noise. Do you have MB detection? Quentin: No but we could. 7. Better documenting interactions between MPTCP and TFO - Christoph [10min= s] Alan: I'd love to see this in bis, but I can't write the text Olivier: We will help. Michael Scharf: as TCPM chair, haven't been here for a while. In TCPM are t= hinking about moving TFO to PS. Does MPTCP have an opinion on this? Please = give input to tcpm list. Yoshi via jabber: different TFO cookies sizes for TCP and MPTCP? Christoph: implementation dependent, currently cookie reduced to 4 bytes, c= an be dynamic. Olivier: In bis, requirements on shorter cookies are relaxed, since MPCAPAB= LE is only 4 bytes. Important for MPTCP is DS mapping for SYN data. Phil: Anyone against including this in the bis? [Nobody]. Too early to deci= de? [Nobody] In favour [some noise]. Christoph, you and Olivier please work= up some text. Juliusz: Is it okay for MPTCP PS to refer to experimental TFO? Michael Scharf: TCPM can move TFO to PS if there were a problem Alan: TFO is informative in bis, so not a problem. 8. Using MPTCP on IPv6 only hosts in networks with NAT64 - Quentin [10mins] Mohamed Boucadair: There are means to discover NAT64, learn prefixes of all= NAT64, you have multiple in path, generic problem. DHCP option is not an o= ption, BEHAVE says don't do that, various issues. Juliusz: One POV that NAT64 is a hack that does not belong in the internet,= I hope for a burst of common sense. Wonder about accommodating for NAT64 b= rokenness within MPTCP. Mohamed: **nat discussion** Olivier: *missing, network issues* NAT64 will exist. Please use a well-know= n prefix. Christoph: This is a really big problem when the device is on a v6 only net= and we used to be a v4 only *net error* I think we could document this in = the bis. 9. Plans for progressing MPTCP [10mins] --_000_c7794827744a4d4ebc51a22092b12394rew09926dag03bdomain1sy_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

Here are the draft minutes from Prague. <= /p>

 

Many thanks to our scribes – Dave, Ilpo and Br= ian – for the excellent notes.

 

Please send any updates and corrections. There are a= couple of comments that are missing (and my notes didn’t help).

Thanks

Phil & Yoshi

 

---

 

MP-TCP Session 1, Tuesday 15:50

scribes Dave Allan, Ilpo J=E4rvinen

 

WG-status

 

Implementation Updates

- Chris Paasch - iOS and Linux Update

  "MPTCP in iOS11" slide

Julius: who picks the mode, the user or developer? A= : Developer.

Julius: What does "only for developers" in= one of the bullets mean?  A: Can only use it on a developer phone (wi= th paid developer Apple account).

 

 

Debashish: Wifi assist. if two interfaces on the cel= lular connection. A: We do not support this.

Debashish: we see some use cases where this is possi= ble.

Marcus:  On iOS, do you plan on supporting prox= ies from the phone itself. A: Can't comment.

- Fabien Duchene - implementation results=

   Alan: this is using vanilla 6824bis A: = yes

- other updates

no update

- hackathon news Quentin

Alan: The general point is that the MP-TCP reset opt= ion was to carry additional semantics. Timeout, again the reason codes had = a general logic, if it could be useful for an admin to analyze a problem, o= r analyze a bug. We don't necessarily need reason codes for everything. It has stuff like lack of resources or ?= ??, exactly the stuff we'd want to see for transient problems.  A: we = can continue the discussion on mail.

reaction to the experimental option:  Alan: sho= uld be a fairly straightforward. 

Julius: For the peanut gallery, what is the applicat= ion of this? Alan: local experiments

 

 

- Alan Ford - RFC 6824bis

Phil: A question to revisit on Friday, if there are = any further suggestions of extensions to the bis version before we declare = victory. DO we have implementations of all the new bits? Alan & Chris P= : Linux is fine, but IOS is not complete Alan: we have one implementation of everything.

Discussion about hackathon MPTCP code availability, = Chris P?: should all be available once pushed out

Phil: Is this sufficient to go standards track. Mirj= a: Up to the WG, will be justified in the shepherd’s write up. Phil: = Discuss timing a bit more on Friday. Need a security area review to make su= re they are happy.

 

 

Proxies

- Olivier, MPTCP Converters

Jabber: When the converter translates TCP to MP-TCP,= who decides to do this, is it the client or the converter. A: do not under= stand the question.

Alan Ford: How do we add another subflow to this? A:= you have two MP-TCP connections. If the client adds a subflow, one will be= added between the converter and the server. In many use cases you have a l= arge numebr of connections.  Alan: The presence of all this direct stuff tells you the server supports MP-TCP= , in the previous example it wasn't there.

Vladimir: About TFO, isn't it dangerous to pass the = TFO cookie to the client vs. keep it in the converter?  A: Depends on = deployment. If you think of a converter with a single IP address serving a = lot of clients there may be a problem. Pool of IP addresses, makes sense to send cookie back.

Chris P. What happens if the converter changes its c= ookie, so there is a wrong cookie on the client side.  A: you would no= t ack the message and have a restart, normal TFO procedure.

Julius: More comments after socks 6.  Extensibi= lity, what do you do with unknown TLV. A: there is an error TLV in the draf= t. Julius: Actual procedures not described. You are only replying with a SY= N-ACK when you get a SYN-ACK from the other side. A: we want to test the connection to the server is working correctly= . The connections do not always succeed. Some small changes to be done in t= he stack interactions.

Jabber: Only plain MP-TCP support is the client the = middlebox. A: take that question to the list.

Mirja: this is an app layer protocol. And can be use= d for other things besides MP-TCP, so this may not be the right group. A: s= peaking as an individual. Mirja: Individual, but can change that anytime.&n= bsp;

Med: If we want this specific to MP-TCP, it is a mat= ter of scoping the document. If it is a proxy just get the port number.

Mirja: This is the right direction but not the right= WG. Sounds a bit like ICE (?).

Oliver: This does match the charter item. Mirja: It = does not need to be a WG document, could still be elsewhere? Phil: We need = to discuss perhaps in a smaller venue.

Alan Ford: This is very MP-TCP specific as far as ap= p layer protocols go. It is in scope as an MP-TCP solution so IMO it is a g= ood map with this WG. Mirja: Shop this around to other WGs. 

Julius: The use case comes from MP-TCP. <= /p>

Julius: This is a quite manageable document, written= with an eye to implementability. There are no domain names, this is good.&= nbsp; If this goes through other WGs, will it still have this property.

Oliver: Do not know. Do not want the converter to ha= ve to do a DNS lookup. A side effect is that it becomes doable in kernels.<= o:p>

Mirja: As an AD I'd recommend announcing this on the= TSV AREA and TCP mailing lists.

Phil: This is a nice to read document. I encourage e= veryone to read it. The contributors really listened to the feedback from p= revious efforts.

 

 

- Vladimir -SOCKS protocol version 6

Julius: In the late 90s, early 2000s, it was great t= o use SOCKS5, but we discovered one RTT was added to no benefit, it took 20= years to get that back. Thank you.  Need to stress how much Olivier a= nd your drafts live in different spaces. I think this has reason to exist even if Olivier’s draft is also pur= sued.  Generalizing often yields unmanagable protocols. I wonder if th= ere is a way to talk to a proxy and know if a converter or SOCKS6.

Vladimir: No sure how to answer that question. Shoul= d go like this. Hi, I want to speak version X, server, I speak version Y. I= f client speaks SOCKS5 then the server should speak SOCKS5.

Olivier: We start with a fixed header with a version= number. If the first transaction had assigned ranges of version numbers fo= r converter and for SOCKs then this would be possible.

Julius: The initial truncation of data, needs some d= iscussion, A: will amend the draft.

Ben Schwartz: Similar proposal in DPRIV, ability to = demux on first few bytes is controversial as it constrains protocol design.= Socks5 is incredibly widely deployed. Your proposal is an improvement. Agr= eeing on a new major version number is close to being as big as that for HTTP.  Probably should not be do= ne in MP-TCP A: plan is to do this in INTAREA.

Point out that the major improvement is in reduction= of RTTs. Two use cases, localhost, and remainder on a LAN with low latenci= es. SO the latency savings is useful, but only if SOCKs server is a large d= istance from you.  The TLS should be mandatory, or some other encryption. 4G and 5G have high delay, so goin= g to get large RTT.  Ben: Again funky security properties. None of the= SOCKS5 clients today do any encryption between client and proxy. Plain tex= t passwords.  Outside a private LAN, TLS should be mandatory.

Olivier: It does not use TFO, thanks for providing t= he code. AS for the existence of HTTP proxies, there are other applications= .

Ben: HTTP connect is a superset of the functionality= .

Phil: Presenting this in INTAREA later in the week. = A:Yes.

 

 

 

 

 

MP-TCP Session 2, Friday 11:50

scribe Brian Trammell

 

3.3 Follow-up discussions from Tuesday's proxy discu= ssions [15mins]

Phil: SOCKS work will probably go forward in INTAREA= . Converter discussion was quite promising, people like the approach, need = more time to read it. Any further comments in follow-up? Otherwise I sugges= t the authors rev the draft addressing comments, will work out which working group that should go forward in. Dis= cussion?

 

4. A security attack - Zhiyun Qian [15mins]

See slide 8 in chair slides "MP-PRIO attack&quo= t;. MP-PRIO can be used by a MITM to divert all traffic on to its own path,= degrading to normal TCP. Removing address identifier from the option fixes= this. Upcoming paper at ICNP.

Alan Ford: MP-PRIO is a backup bit, predates the PRI= O bit in the MP-JOIN, which negates the point of this signal. Real question= : is there a reason to change the priority of a subflow from another subflo= w?

Olivier: Attack important in practice. Multiple conn= ection, can be used to move all traffic to an untrusted network e.g. wifi. = Don't know any implementer that uses address identifier on MP-PRIO, so remo= ve it. Keeps protocol simple and usable.

Phil: Anyone unhappy with proposed solution, please = hum. [Silence]. Okay with it? [Tired hums]. Need more time? [Silence]<= /o:p>

 

5. A proposal for MPTCP Robust session Establishment= (MPTCP RobE)

Markus Amend - "A proposal for MPTCP Robust ses= sion Establishment (MPTCP RobE)" [15mins]

Alan Ford: last slide covers everything I was going = to say. Biggest killer is no key in MP_CAPABLE. Semantics of the key simply= aren't the same as what you're using. Can't assume that two keys on the wi= re are the same identity. Most concerned as to how you see this working without the key, what's your way around it?=

Markus: Key missing in first SYN, can't use as ident= ifier. Last ACK has both keys available, then you can make the decision on = the receiver side.

Alan: Would not have been the same key B<= /p>

Markus: Host B answers with different keys B. Key B = can be replaced...

Alan: Security alarm bells. Can't point to just one = thing. Very uncomfortable.

Olivier: Good motivation, looking at Happy Eyeballs,= though, this seems applicable. Work in TAPS for racing, is the same proble= m. Application layer library can do this, not application itself. Build a s= him layer, then the app-layer solution is easier.

Markus: Then we have some overhead

Olivier: But you can learn the network, and remember= it, you don't have to do this for every connection.

Markus: Put it in the standard, not in the libraries= , then it's general.

Christoph: Important work. iOS uses the timer based = approach. Independent of the transport layer protocol. Also, paths not equa= l.

Markus: also delay.

Brian: I like approach 1 but share Alan's concerns. = No incremental deployment, means you need negotiation, makes it more comple= x. Would that be done before MP-QUIC is, for example? Approach 3, little bi= t more latency but less complexity. Don't race in MPTCP layer; racing in two places is messy, and you have to = race v4v6

Anna: **missing** Separate robustness and latency

 

6. Proposal for a new Multipath TCP option

Quentin De Coninck - "Every Millisecond Counts:= Tuning Multipath TCP for Interactive Applications on Smartphones" [15= mins]

Uma: Low latency very important, 5G etc. What is the= gain you achieve with you this approach over classical MPTCP?

Quentin: Latency remains quite the same, but the cel= lular won't get established until you need to use it.

Alan: Options in SYN before data, what are you signi= ng with HMAC? No data until third ACK. What is DSN on slide 8? Are you send= ing data in the SYN?

Quentin: Yes.

Alan: Cool.

Anna: Curious about impact on delay bet. detection t= o establish new subflow and cost of setting it up. Magnitude important to s= ee whole picture on latency.

Quentin: You see this with a low latency main net an= d a high latency second net. When the nets are comparable,

Phil: Is this a change to base protocol? Changes sec= urity properties?

Quentin: Yes

Christoph: Important to reduce handshake time. But w= hen cell is down bringing it back up again is very slow and in this case th= e handshake is lost in noise. Do you have MB detection?

Quentin: No but we could.

 

7. Better documenting interactions between MPTCP and= TFO - Christoph [10mins]

Alan: I'd love to see this in bis, but I can't write= the text

Olivier: We will help.

Michael Scharf: as TCPM chair, haven't been here for= a while. In TCPM are thinking about moving TFO to PS. Does MPTCP have an o= pinion on this? Please give input to tcpm list.

Yoshi via jabber: different TFO cookies sizes for TC= P and MPTCP?

Christoph: implementation dependent, currently cooki= e reduced to 4 bytes, can be dynamic.

Olivier: In bis, requirements on shorter cookies are= relaxed, since MPCAPABLE is only 4 bytes. Important for MPTCP is DS mappin= g for SYN data.

Phil: Anyone against including this in the bis? [Nob= ody]. Too early to decide? [Nobody] In favour [some noise]. Christoph, you = and Olivier please work up some text.

Juliusz: Is it okay for MPTCP PS to refer to experim= ental TFO?

Michael Scharf: TCPM can move TFO to PS if there wer= e a problem

Alan: TFO is informative in bis, so not a problem.

 

8. Using MPTCP on IPv6 only hosts in networks with N= AT64 - Quentin [10mins]

Mohamed Boucadair: There are means to discover NAT64= , learn prefixes of all NAT64, you have multiple in path, generic problem. = DHCP option is not an option, BEHAVE says don't do that, various issues.

Juliusz: One POV that NAT64 is a hack that does not = belong in the internet, I hope for a burst of common sense. Wonder about ac= commodating for NAT64 brokenness within MPTCP.

Mohamed: **nat discussion**

Olivier: *missing, network issues* NAT64 will exist.= Please use a well-known prefix.

Christoph: This is a really big problem when the dev= ice is on a v6 only net and we used to be a v4 only *net error* I think we = could document this in the bis.

 

9. Plans for progressing MPTCP [10mins]

--_000_c7794827744a4d4ebc51a22092b12394rew09926dag03bdomain1sy_-- From nobody Wed Aug 2 11:28:39 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0C0129B26 for ; Wed, 2 Aug 2017 11:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 x7JRwL38lyyj for ; Wed, 2 Aug 2017 11:28:37 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC6D126C0F for ; Wed, 2 Aug 2017 11:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8804; q=dns/txt; s=iport; t=1501698517; x=1502908117; h=from:to:cc:subject:date:message-id:mime-version; bh=B9KT1vM6pgTZWCTYyuf/f6rQKtVZiAZOzTYYQqs8rUE=; b=AYoNKzQz75Jr4VOMdxXFCBBh+TPLx6eqE76df4l+NLtj9duLBYIPbV3Q SfexhF4pLhDMOGNlNyXxcYAYSHD024p+4IF5XlhcGubnmYcplvZ1rppnQ 53ERd/b1b2zqeF7OHX5EZl7pslkYxclLwfS43bnz7Cnm5U2071Ite2dzR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGAQCnGIJZ/5JdJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgm9rZIEbjgeQA5JNhTGCEoVHHIQbPxgBAgEBAQEBAQFrHQuFQgpMEgFKAgQ?= =?us-ascii?q?wJwQOiVBkrhaCJieLJAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DKIICg1qHWQmDI?= =?us-ascii?q?DCCMQWffAKBZpJEgg2FVophlXoBHzg/S3cVWwGHB4gjgTCBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,312,1498521600"; d="scan'208,217";a="465621410" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2017 18:28:36 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v72ISauC021653 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 2 Aug 2017 18:28:36 GMT Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Aug 2017 13:28:35 -0500 Received: from xch-aln-016.cisco.com ([173.36.7.26]) by XCH-ALN-016.cisco.com ([173.36.7.26]) with mapi id 15.00.1210.000; Wed, 2 Aug 2017 13:28:35 -0500 From: "Nandini Ganesh (nanv)" To: "multipathtcp@ietf.org" CC: "Sri Gundavelli (sgundave)" Thread-Topic: Questions on explicit proxy Thread-Index: AQHTC70mHDHo8tD06EeFDc/Iu2yRcg== Date: Wed, 2 Aug 2017 18:28:35 +0000 Message-ID: <9AD3F237-E91D-404E-A6B4-3F988AAE0749@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.41.33.143] Content-Type: multipart/alternative; boundary="_000_9AD3F237E91D404EA6B43F988AAE0749ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Questions on explicit proxy X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 18:28:39 -0000 --_000_9AD3F237E91D404EA6B43F988AAE0749ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBiZWVuIHJldmlld2luZyBib3RoIHRoZSBjdXJyZW50IGRyYWZ0cyBmb3Ig ZXhwbGljaXQgcHJveHkvY29udmVydGVycyBmb3IgTVBUQ1AuDQoNCkkgaGF2ZSB0aGUgZm9sbG93 aW5nIHF1ZXN0aW9ucyByZWdhcmRpbmcgcGxhaW4gbW9kZSBkcmFmdA0KDQoxLiAgICAgICBQbGVh c2UgY2FuIHlvdSBnaXZlIGFuIGV4YW1wbGUgb2YgYSB1c2UtY2FzZSB3aGVyZSB0aGUgRC1iaXQg aXMgc2V0IE1QX0NPTlZFUlRfSUUgYW5kIGhvdyB0aGlzIOKAnHNvdXJjZSBhZGRyZXNz4oCdIHdp bGwgYmUgdXNlZD8NCg0KMi4gICAgICAgVGhlIGRvd25zdHJlYW0gZXhwbGljaXQgcHJveHkgd2ls bCBhbHdheXMgaW50ZXJjZXB0IHRoZSB0cmFmZmljIGFuZCBjb252ZXJ0IGl0IHRvIFRDUC4gIElm IHRoZSBzZXJ2ZXIgaXMgdXBncmFkZWQgdG8gc3VwcG9ydCBNUFRDUCwgaXMgdGhlcmUgYSBtZXRo b2QgdG8gZHluYW1pY2FsbHkgbGVhcm4gdGhpcz8NCg0KDQoNCkFsc28sIGFyZSB0aGVyZSBhbnkg c2FtcGxlIGltcGxlbWVudGF0aW9ucyBvZiBleHBsaWNpdCBNUFRDUCBwcm94eSBhcyBzdWdnZXN0 ZWQgaW4gdGhlIGRyYWZ0cz8NCg0KVGhhbmtzLA0KTmFuZGluaQ0KDQoNCg0K --_000_9AD3F237E91D404EA6B43F988AAE0749ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <03E732A35C183F4AAC1ECD27444E79BD@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lu cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTUyMDEx ODI3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1MTA2 NjgxNTQgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDozMS41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFu Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J IGhhdmUgYmVlbiByZXZpZXdpbmcgYm90aCB0aGUgY3VycmVudCBkcmFmdHMgZm9yIGV4cGxpY2l0 IHByb3h5L2NvbnZlcnRlcnMgZm9yIE1QVENQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+SSBoYXZlIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zIHJlZ2FyZGluZyBw bGFpbiBtb2RlIGRyYWZ0DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjMxLjVwdDt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIGNhbiB5b3UgZ2l2ZSBh biBleGFtcGxlIG9mIGEgdXNlLWNhc2Ugd2hlcmUgdGhlIEQtYml0IGlzIHNldCBNUF9DT05WRVJU X0lFIGFuZCBob3cgdGhpcyDigJxzb3VyY2UgYWRkcmVzc+KAnSB3aWxsIGJlIHVzZWQ/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDozMS41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPlRoZSBkb3duc3RyZWFtIGV4cGxpY2l0IHByb3h5IHdpbGwgYWx3YXlzIGlu dGVyY2VwdCB0aGUgdHJhZmZpYyBhbmQgY29udmVydCBpdCB0byBUQ1AuICZuYnNwO0lmIHRoZSBz ZXJ2ZXIgaXMgdXBncmFkZWQgdG8gc3VwcG9ydCBNUFRDUCwgaXMgdGhlcmUgYSBtZXRob2QgdG8g ZHluYW1pY2FsbHkgbGVhcm4gdGhpcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjMxLjVwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+QWxzbywgYXJlIHRoZXJlIGFueSBzYW1wbGUgaW1wbGVtZW50YXRpb25zIG9m IGV4cGxpY2l0IE1QVENQIHByb3h5IGFzIHN1Z2dlc3RlZCBpbiB0aGUgZHJhZnRzPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDxicj4NCk5hbmRpbmk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_9AD3F237E91D404EA6B43F988AAE0749ciscocom_-- From nobody Wed Aug 2 23:15:22 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611991321F5 for ; Wed, 2 Aug 2017 23:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 JrOATzU_VCEC for ; Wed, 2 Aug 2017 23:15:19 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9761A131C6C for ; Wed, 2 Aug 2017 23:15:19 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 41C7B1C039A; Thu, 3 Aug 2017 08:15:18 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 2464240058; Thu, 3 Aug 2017 08:15:18 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0352.000; Thu, 3 Aug 2017 08:15:17 +0200 From: To: "Nandini Ganesh (nanv)" , "multipathtcp@ietf.org" CC: "Sri Gundavelli (sgundave)" Thread-Topic: [multipathtcp] Questions on explicit proxy Thread-Index: AQHTC70mHDHo8tD06EeFDc/Iu2yRcqJyIqHA Date: Thu, 3 Aug 2017 06:15:17 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0165DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <9AD3F237-E91D-404E-A6B4-3F988AAE0749@cisco.com> In-Reply-To: <9AD3F237-E91D-404E-A6B4-3F988AAE0749@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0165DFOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Questions on explicit proxy X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 06:15:21 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0165DFOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmFuZGluaSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IG11bHRpcGF0aHRjcCBbbWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYub3JnXSBEZSBs YSBwYXJ0IGRlIE5hbmRpbmkgR2FuZXNoIChuYW52KQ0KRW52b3nDqSA6IG1lcmNyZWRpIDIgYW/D u3QgMjAxNyAyMDoyOQ0Kw4AgOiBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCkNjIDogU3JpIEd1bmRh dmVsbGkgKHNndW5kYXZlKQ0KT2JqZXQgOiBbbXVsdGlwYXRodGNwXSBRdWVzdGlvbnMgb24gZXhw bGljaXQgcHJveHkNCg0KSGksDQoNCkkgaGF2ZSBiZWVuIHJldmlld2luZyBib3RoIHRoZSBjdXJy ZW50IGRyYWZ0cyBmb3IgZXhwbGljaXQgcHJveHkvY29udmVydGVycyBmb3IgTVBUQ1AuDQoNCkkg aGF2ZSB0aGUgZm9sbG93aW5nIHF1ZXN0aW9ucyByZWdhcmRpbmcgcGxhaW4gbW9kZSBkcmFmdA0K DQoxLiAgICAgICBQbGVhc2UgY2FuIHlvdSBnaXZlIGFuIGV4YW1wbGUgb2YgYSB1c2UtY2FzZSB3 aGVyZSB0aGUgRC1iaXQgaXMgc2V0IE1QX0NPTlZFUlRfSUUgYW5kIGhvdyB0aGlzIOKAnHNvdXJj ZSBhZGRyZXNz4oCdIHdpbGwgYmUgdXNlZD8NCg0KW01lZF0gVGhlIG1haW4gdXNlIGNhc2UgaXMg Zm9yIElQdjYgc291cmNlIGFkZHJlc3MgcHJlc2VydmF0aW9uIHRvIGF2b2lkIE5QVHY2IChSRkM2 Mjk2KS4gQW4gZXhhbXBsZSBpcyBzaG93biBpbiBzbGlkZSAxOCBvZiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvOTgvbWF0ZXJpYWxzL3NsaWRlcy05OC1tcHRjcC1zZXNzYS1u ZXR3b3JrLWFzc2lzdGVkLW1wdGNwLiBUaGUgcGFja2V0IHRoYXQgd2lsbCBiZSByZWxheWVkIGJ5 IHRoZSBwcm94eSB3aWxsIGJlIHNvdXJjZWQgd2l0aCB0aGUgSVB2NiBhZGRyZXNzIGluZGljYXRl ZCBpbiB0aGUgcHJveHkgc3VwcGxpZWQgZGF0YS4gRG9pbmcgc28gYXZvaWRzIGJyZWFraW5nIGFw cGxpY2F0aW9ucyB3aXRoIHJlZmVycmFscyBhbmQgbWFueSBvdGhlciB0aGluZ3MgdGhhdCB3b3Vs ZCBicmVhayB3aXRoIE5QVHY2IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI5NiNz ZWN0aW9uLTUpDQoNCg0KMi4gICAgICAgVGhlIGRvd25zdHJlYW0gZXhwbGljaXQgcHJveHkgd2ls bCBhbHdheXMgaW50ZXJjZXB0IHRoZSB0cmFmZmljIGFuZCBjb252ZXJ0IGl0IHRvIFRDUC4gIElm IHRoZSBzZXJ2ZXIgaXMgdXBncmFkZWQgdG8gc3VwcG9ydCBNUFRDUCwgaXMgdGhlcmUgYSBtZXRo b2QgdG8gZHluYW1pY2FsbHkgbGVhcm4gdGhpcz8NCg0KDQpbTWVkXSBUaGUgcHJveHkgZG9lcyBu b3Qgc3lzdGVtYXRpY2FsbHkgY29udmVydCBhbiBNUFRDUCBjb25uZWN0aW9uIGludG8gVENQOyBp dCBuZWVkcyB0byB3YWl0IGZvciB0aGUgU1lOLUFDSyBmcm9tIHRoZSByZW1vdGUgc2VydmVyIHRv IGRldGVybWluZSB3aGV0aGVyIHRoZSByZW1vdGUgc2VydmVyIGlzIE1QVENQIGNvbXBsaWFudC4g V2UgY2xhcmlmaWVkIHRoaXMgaW4gdGhlIG5ldyBjb252ZXJ0ZXIgZGVzaWduOyB5b3UgY2FuIHJl ZmVyIGZvciBpbnN0YW5jZSB0byBzbGlkZSA4IG9mIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvbWVldGluZy85OS9tYXRlcmlhbHMvc2xpZGVzLTk5LW1wdGNwLXNlc3NhLTAtcnR0LXRjcC1j b252ZXJ0ZXJzDQoNCkFsc28sIGFyZSB0aGVyZSBhbnkgc2FtcGxlIGltcGxlbWVudGF0aW9ucyBv ZiBleHBsaWNpdCBNUFRDUCBwcm94eSBhcyBzdWdnZXN0ZWQgaW4gdGhlIGRyYWZ0cz8NCltNZWRd IEnigJltIGF3YXJlIG9mIHNvbWUgbm9uLXB1YmxpYyBpbXBsZW1lbnRhdGlvbnMuIFRob3NlIGlt cGxlbWVudGF0aW9ucyBuZWVkIHRvIGJlIGFkYXB0ZWQgYW55d2F5IHRvIGZvbGxvdyB0aGUgbmV3 IHNwZWMgYXMgc2tldGNoZWQgaW4gdGhlIGNvbnZlcnRlciBkcmFmdC4gUGxlYXNlIHVzZSB0aGUg Y29udmVydGVyIGRyYWZ0IGFzIHRoZSByZWZlcmVuY2UgZG9jdW1lbnQuIFRoYW5rIHlvdS4NCg0K VGhhbmtzLA0KTmFuZGluaQ0KDQoNCg0K --_000_787AE7BB302AE849A7480A190F8B93300A0165DFOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1 NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3 MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJv dHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0K CWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTAxNjk1MTI0Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDM4MDEwOTAyIDM1NzU2OTkw MCA2Nzg5NTMyMSA2Nzg5NTMyMyA2Nzg5NTMxMSA2Nzg5NTMyMSA2Nzg5NTMyMyA2Nzg5NTMxMSA2 Nzg5NTMyMSA2Nzg5NTMyMzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMy LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4Ljc1cHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo2Ny41cHQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoxMDMuNXB0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEz OS41cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE3NS41cHQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoyMTEuNXB0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI0 Ny41cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEwLjBjbTsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjMxOS41cHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJG UiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBOYW5k aW5pLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IG11bHRpcGF0aHRjcCBbbWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGll dGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTmFuZGluaSBHYW5lc2ggKG5hbnYpPGJyPg0K PGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDIgYW/Du3QgMjAxNyAyMDoyOTxicj4NCjxi PsOAJm5ic3A7OjwvYj4gbXVsdGlwYXRodGNwQGlldGYub3JnPGJyPg0KPGI+Q2MmbmJzcDs6PC9i PiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBbbXVs dGlwYXRodGNwXSBRdWVzdGlvbnMgb24gZXhwbGljaXQgcHJveHk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhhdmUgYmVlbiByZXZpZXdpbmcgYm90 aCB0aGUgY3VycmVudCBkcmFmdHMgZm9yIGV4cGxpY2l0IHByb3h5L2NvbnZlcnRlcnMgZm9yIE1Q VENQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5JIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgcmVnYXJkaW5n IHBsYWluIG1vZGUgZHJhZnQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzIuMjVwdDt0ZXh0LWluZGVudDotMTgu NzVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlBsZWFzZSBjYW4geW91IGdpdmUgYW4gZXhhbXBsZSBvZiBhIHVzZS1jYXNlIHdo ZXJlIHRoZSBELWJpdCBpcyBzZXQgTVBfQ09OVkVSVF9JRSBhbmQgaG93IHRoaXMg4oCcc291cmNl IGFkZHJlc3PigJ0gd2lsbCBiZSB1c2VkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBUaGUgbWFpbiB1 c2UgY2FzZSBpcyBmb3IgSVB2NiBzb3VyY2UgYWRkcmVzcyBwcmVzZXJ2YXRpb24gdG8gYXZvaWQg TlBUdjYgKFJGQzYyOTYpLiBBbiBleGFtcGxlIGlzIHNob3duIGluIHNsaWRlIDE4IG9mDQo8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTgvbWF0ZXJpYWxzL3Ns aWRlcy05OC1tcHRjcC1zZXNzYS1uZXR3b3JrLWFzc2lzdGVkLW1wdGNwIj4NCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OC9tYXRlcmlhbHMvc2xpZGVzLTk4LW1wdGNwLXNl c3NhLW5ldHdvcmstYXNzaXN0ZWQtbXB0Y3A8L2E+LiBUaGUgcGFja2V0IHRoYXQgd2lsbCBiZSBy ZWxheWVkIGJ5IHRoZSBwcm94eSB3aWxsIGJlIHNvdXJjZWQgd2l0aCB0aGUgSVB2NiBhZGRyZXNz IGluZGljYXRlZCBpbiB0aGUgcHJveHkgc3VwcGxpZWQgZGF0YS4gRG9pbmcgc28gYXZvaWRzIGJy ZWFraW5nIGFwcGxpY2F0aW9ucw0KIHdpdGggcmVmZXJyYWxzIGFuZCBtYW55IG90aGVyIHRoaW5n cyB0aGF0IHdvdWxkIGJyZWFrIHdpdGggTlBUdjYgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM2Mjk2I3NlY3Rpb24tNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzYyOTYjc2VjdGlvbi01PC9hPikNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDozMS41cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4yLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhl IGRvd25zdHJlYW0gZXhwbGljaXQgcHJveHkgd2lsbCBhbHdheXMgaW50ZXJjZXB0IHRoZSB0cmFm ZmljIGFuZCBjb252ZXJ0IGl0IHRvIFRDUC4gJm5ic3A7SWYgdGhlIHNlcnZlciBpcyB1cGdyYWRl ZCB0byBzdXBwb3J0IE1QVENQLCBpcyB0aGVyZSBhIG1ldGhvZCB0byBkeW5hbWljYWxseSBsZWFy biB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzEuNXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gVGhlIHBy b3h5IGRvZXMgbm90IHN5c3RlbWF0aWNhbGx5IGNvbnZlcnQgYW4gTVBUQ1AgY29ubmVjdGlvbiBp bnRvIFRDUDsgaXQgbmVlZHMgdG8gd2FpdCBmb3IgdGhlIFNZTi1BQ0sgZnJvbSB0aGUgcmVtb3Rl IHNlcnZlciB0byBkZXRlcm1pbmUgd2hldGhlcg0KIHRoZSByZW1vdGUgc2VydmVyIGlzIE1QVENQ IGNvbXBsaWFudC4gV2UgY2xhcmlmaWVkIHRoaXMgaW4gdGhlIG5ldyBjb252ZXJ0ZXIgZGVzaWdu OyB5b3UgY2FuIHJlZmVyIGZvciBpbnN0YW5jZSB0byBzbGlkZSA4IG9mDQo8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTkvbWF0ZXJpYWxzL3NsaWRlcy05OS1t cHRjcC1zZXNzYS0wLXJ0dC10Y3AtY29udmVydGVycyI+DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL21lZXRpbmcvOTkvbWF0ZXJpYWxzL3NsaWRlcy05OS1tcHRjcC1zZXNzYS0wLXJ0dC10 Y3AtY29udmVydGVyczwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbHNvLCBhcmUgdGhlcmUgYW55IHNhbXBsZSBpbXBsZW1l bnRhdGlvbnMgb2YgZXhwbGljaXQgTVBUQ1AgcHJveHkgYXMgc3VnZ2VzdGVkIGluIHRoZSBkcmFm dHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBJ4oCZbSBhd2FyZSBvZiBzb21lIG5vbi1w dWJsaWMgaW1wbGVtZW50YXRpb25zLiBUaG9zZSBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBiZSBh ZGFwdGVkIGFueXdheSB0byBmb2xsb3cgdGhlIG5ldyBzcGVjIGFzIHNrZXRjaGVkIGluIHRoZSBj b252ZXJ0ZXIgZHJhZnQuDQogUGxlYXNlIHVzZSB0aGUgY29udmVydGVyIGRyYWZ0IGFzIHRoZSBy ZWZlcmVuY2UgZG9jdW1lbnQuIFRoYW5rIHlvdS4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRo YW5rcyw8YnI+DQpOYW5kaW5pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300A0165DFOPEXCLILMA3corp_-- From nobody Tue Aug 8 20:35:01 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF5D12702E for ; Tue, 8 Aug 2017 20:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Th6PbL5rArAX for ; Tue, 8 Aug 2017 20:34:59 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9190B124B09 for ; Tue, 8 Aug 2017 20:34:59 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id v189so22695440pgd.2 for ; Tue, 08 Aug 2017 20:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=VRrWomT3ionb2HJxejG+c38LHd/ZS3L7Hhc+aDa69ZY=; b=tHXY5YQRhi7OoXGcLTo29/2Tgipj8/ZaczyIpkciAVNPboI2TAYhAe4LZ75gjn6Ja5 2+YcgexjLiV0Bvrt+3CUTxPD/VWHM4dkl0eMWNgI4EOY+QtDcQ4fSlK2Ao9hvhKhh7WZ YnXWr487CAOCnYRrOUZ2Sxb2K7rRHoEYAJr8O6YhhqKaFxij69gNgpwSri3RQSLzF2jw WbfhmDQz0lfeO8lCITG0MEL8jfD04zYvkShxrNKXDYR3xXRo2nPz0dRdxYz7Nuuf6fLJ dXHfkcWy/QYS+v0EseMIEQ1j2h1TMZU4JB83a3wHL6gtHVfrnQ3OkI6zDIsUMCluHQLp CnUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=VRrWomT3ionb2HJxejG+c38LHd/ZS3L7Hhc+aDa69ZY=; b=Z3nglURX8riv7ZcEjgDax6LOf2CzX8k6+V+T8ZwKvmAINxuDFy1aMOd4relWXURQTq HrQbf+C12puyAvrLrVI+yZ48/IXZCpEw+ZKPDtq150uO73E0z0FgviL+37/XTeopm9QL E4ZpIQsSYlvFJWYqVVETifDxbLmIkRldRUhY6kBhA2rJyeSzEMx2wgpAeCsKRrjRQ4s/ md/yDSwpm1Xct6vPH//bOjGlFv6ipARcZnaLfhWsBxLgKf5HeM3GoMP8W1dYrcAWtYMs GREqwEK5fn2HThcu+2EPMdrIzubx+BScNYOiuPSFjfyVBbLqIEyMTM+y16s+6A34aCWt 8aMg== X-Gm-Message-State: AHYfb5i0HJhSGlVjiztpdDmy9FCzJYWnCP/SUvS/OfbTU/wKsZNN5NcN XcpnYE6a31RVbUyXL7Y= X-Received: by 10.101.70.137 with SMTP id h9mr6185725pgr.50.1502249698800; Tue, 08 Aug 2017 20:34:58 -0700 (PDT) Received: from [127.0.0.1] (107.182.176.120.16clouds.com. [107.182.176.120]) by smtp.gmail.com with ESMTPSA id q3sm4685615pgf.69.2017.08.08.20.34.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Aug 2017 20:34:57 -0700 (PDT) From: Vincent Stone Content-Type: multipart/alternative; boundary="Apple-Mail=_FD667CF6-D66F-4589-ABB2-E0278516DC45" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <0940F5BC-7405-4AB0-9C73-E125B56F66B2@gmail.com> Date: Wed, 9 Aug 2017 11:34:58 +0800 To: multipathtcp@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [multipathtcp] Regarding the release of sending buffer X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 03:35:00 -0000 --Apple-Mail=_FD667CF6-D66F-4589-ABB2-E0278516DC45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I have a question about when the packet can be freed from the send = buffer. In section 3.3.2 of RFC 6824: An MPTCP sender MUST NOT free data from the send buffer until it has been acknowledged by both a Data ACK received on any subflow and at the subflow level by all subflows on which the data was sent. The former condition ensures liveness of the connection and the latter condition ensures liveness and self-consistence of a subflow when data needs to be retransmitted. Note, however, that if some data needs to be retransmitted multiple times over a subflow, there is a risk of blocking the sending window. In this case, the MPTCP sender can decide to terminate the subflow that is behaving badly by sending a RST. If data is acknowledged by Data ACK, that means it has been already = received by receiver. There is no need to wait for the subflow level = ACK. Even if the subflow decides to retransmit the data, we can just = retransmit a fake/dumb packet, because that packet will be ignored by = the receiver (out of receive window) anyway. Or we can advance the send = window of the subflow upon the receiving of data ack to prevent the = subflow level retransmission. So my question is: can the data be freed = from the send buffer once it has been acknowledged by the Data ACK? Best regards, Vincent= --Apple-Mail=_FD667CF6-D66F-4589-ABB2-E0278516DC45 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi all,
I have a question about when the packet can be freed from the send buffer.
In section 3.3.2 of RFC 6824:
   An MPTCP sender MUST NOT free data from the send buffer until it has
   been acknowledged by both a Data ACK received on any subflow and at
   the subflow level by all subflows on which the data was sent.  The
   former condition ensures liveness of the connection and the latter
   condition ensures liveness and self-consistence of a subflow when
   data needs to be retransmitted.  Note, however, that if some data
   needs to be retransmitted multiple times over a subflow, there is a
   risk of blocking the sending window.  In this case, the MPTCP sender
   can decide to terminate the subflow that is behaving badly by sending
   a RST.

If data is acknowledged by Data ACK, that means it has been already received by receiver. There is no need to wait for the subflow level ACK. Even if the subflow decides to retransmit the data, we can just retransmit a fake/dumb packet, because that packet will be ignored by the receiver (out of receive window) anyway. Or we can advance the send window of the subflow upon the receiving of data ack to prevent the subflow level retransmission. So my question is: can the data be freed from the send buffer once it has been acknowledged by the Data ACK?

Best regards,

Vincent
--Apple-Mail=_FD667CF6-D66F-4589-ABB2-E0278516DC45-- From nobody Tue Aug 8 20:48:19 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7FD124BAC for ; Tue, 8 Aug 2017 20:48:18 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 p56-ZWmKxePF for ; Tue, 8 Aug 2017 20:48:17 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 9D5F8124B09 for ; Tue, 8 Aug 2017 20:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1502250497; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ubjcfPVJQfqYZuymCxTjYg8mb5UcKDYbPeI5jDRh51U=; b=JMSzE3NEih14T4I0CnT3jZrHrP+d0+1arhJ8ezGyftL5L+wIeWF4B6TPofIYK07Q T8z0V7fckjU8/ffTfUknDch/FlhyqOj3uXrMgW6wI6Oy8zJEZcUT2Sd0VQXOH18K v6U6xYyg8z7C1GqpT41CHjZW+0KJXfHmdeVClz5IrSydfihuiurDhuwxEI5WQ8xQ Bb00fzUMF6p7Z38ezhHAdUDK/T/Ao/lcu8GplO6NhSRy9NRxBvRosr6jn0UWUEN0 qWAsbmI6ylTFvj7RFat57PfwTLV8wJ/2QbmV/cu0+Y8n6jK/reWT0SxuGiso1AI/ GScu5JGzC+ee5lsf4ZmEJw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id EA.5C.06961.1068A895; Tue, 8 Aug 2017 20:48:17 -0700 (PDT) X-AuditID: 11973e15-9dace9c000001b31-fc-598a8601727e Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay2.apple.com (Apple SCV relay) with SMTP id B4.4C.09069.1068A895; Tue, 8 Aug 2017 20:48:17 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from localhost ([17.234.103.78]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUE00AXFFWGE970@nwk-mmpp-sz11.apple.com>; Tue, 08 Aug 2017 20:48:17 -0700 (PDT) Sender: cpaasch@apple.com Date: Tue, 08 Aug 2017 20:48:15 -0700 From: Christoph Paasch To: Vincent Stone Cc: multipathtcp@ietf.org Message-id: <20170809034815.GX3648@Chimay.local> References: <0940F5BC-7405-4AB0-9C73-E125B56F66B2@gmail.com> In-reply-to: <0940F5BC-7405-4AB0-9C73-E125B56F66B2@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUi2FDorMvY1hVpcOAbn8Xn1dfZLA5d2MTu wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGVMXfWKqeA1X8W+rr9sDYzXuLsYOTkkBEwk Lj5dzNLFyMUhJLCaSWLV/MtMMIlZLR+ZIRKHGCW+L2hhAUnwCghK/Jh8D8jm4GAWkJc4eF4W JMwsIC3x6O8MdghbS+L7o1awciGBRiaJR9sqQWxhAUmJ7jt3mEFsFgFViY0d38F2sQHVv73d zgpiiwjoSGz9tI8NYo6kxIq/n1ghep0ldi+5zgpxgoHExJkbWUFOEBKwkfj73gYkzClgK9F7 4QBYq6iAssTfw/fA/pIQmMImsfn5A5YJjCKzkHwwC+GDWUg+mIXkgwWMLKsYhXITM3N0M/PM 9BILCnJS9ZLzczcxguJgup3oDsYzq6wOMQpwMCrx8N7Y0xkpxJpYVlyZe4hRmoNFSZy3L6sr UkggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjX/vhhpZP94/+NFF8nWwXpMuqn77920zfh7X2 nNNFVs3yO8O4x8Y5Wp55g8/NmWFbForPf80nnult/S/0bUpZNlfMpN9vPovFCF27nXnsuQNf Y/uRw/+mfrC6/7ZERGmuwNeymQ5qp6vkFxkoWxb4rPoTWXe35hfn3gMNDr0zmR1j57HOn8em xFKckWioxVxUnAgAITh7zGQCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FA8W5exrSvSoH02j8Xn1dfZLA5d2MTu wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGVMXfWKqeA1X8W+rr9sDYzXuLsYOTkkBEwk ZrV8ZO5i5OIQEjjEKPF9QQsLSIJXQFDix+R7QDYHB7OAvMTB87IgYWYBaYlHf2ewQ9haEt8f tYKVCwk0Mkk82lYJYgsLSEp037nDDGKzCKhKbOz4zgRiswHVv73dzgpiiwjoSGz9tI8NYo6k xIq/n1ghep0ldi+5zgpxgoHExJkbWUFOEBKwkfj73gYkzClgK9F74QBYq6iAssTfw/dYJjAK zkJy9CyEo2chOXoWkqMXMLKsYhQoSs1JrDTSSywoyEnVS87P3cQIDttC5x2Mx5ZZHWIU4GBU 4uG9saczUog1say4MhcYQhzMSiK883K6IoV4UxIrq1KL8uOLSnNSiw8xSnOwKInz7t/SESkk kJ5YkpqdmlqQWgSTZeLglGpgnLbTzvLBTf78mOpXZ2Z/m5F2n8f06yT2Xa4tNZPYd7oWTGuO 2HGywfWayKl3UhlKwTKKj4oLHhu4fQpTuFnLZZDMwx+6o2r7jxKFFZ95vHczGxSbnvPdWX5s 1f2d2+4ZPu2O4+nluhlvzbr15JKDYUHbzixMjJ+Qvcw4/kKeTp/xQ8u6Y0KblFiKMxINtZiL ihMBqQRAi1cCAAA= Archived-At: Subject: Re: [multipathtcp] Regarding the release of sending buffer X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 03:48:18 -0000 Hello, On 09/08/17 - 11:34:58, Vincent Stone wrote: > Hi all, > I have a question about when the packet can be freed from the send buffer. > In section 3.3.2 of RFC 6824: > An MPTCP sender MUST NOT free data from the send buffer until it has > been acknowledged by both a Data ACK received on any subflow and at > the subflow level by all subflows on which the data was sent. The > former condition ensures liveness of the connection and the latter > condition ensures liveness and self-consistence of a subflow when > data needs to be retransmitted. Note, however, that if some data > needs to be retransmitted multiple times over a subflow, there is a > risk of blocking the sending window. In this case, the MPTCP sender > can decide to terminate the subflow that is behaving badly by sending > a RST. > > If data is acknowledged by Data ACK, that means it has been already received by receiver. There is no need to wait for the subflow level ACK. Even if the subflow decides to retransmit the data, we can just retransmit a fake/dumb packet, because that packet will be ignored by the receiver (out of receive window) anyway. Or we can advance the send window of the subflow upon the receiving of data ack to prevent the subflow level retransmission. So my question is: can the data be freed from the send buffer once it has been acknowledged by the Data ACK? the problem is that when you do this, the subflow on which you are preventing the retransmission by advancing the send-window or where you are sending a fake-packet, won't look like "regular" TCP anymore. Middleboxes and firewalls will start blocking this traffic and the receiver must also be able to gracefully handle this. That's the reason why MPTCP tries hard to make every subflow look like it is regular TCP, besides a few TCP-options. Cheers, Christoph From nobody Wed Aug 9 00:22:10 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FA3132414 for ; Wed, 9 Aug 2017 00:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xzYpQDZvXRlb for ; Wed, 9 Aug 2017 00:22:04 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4403E1274A5 for ; Wed, 9 Aug 2017 00:22:02 -0700 (PDT) Received: from EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 9 Aug 2017 08:21:58 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 9 Aug 2017 08:22:00 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 9 Aug 2017 08:21:59 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.002; Wed, 9 Aug 2017 08:21:59 +0100 From: To: Thread-Topic: Draft minutes from IETF-99 Thread-Index: AdMLYBre5HcS5whEQqWBOgyfr+rxGAFgANEg Date: Wed, 9 Aug 2017 07:21:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.232] Content-Type: multipart/alternative; boundary="_000_e5034ef6db454b00a004469e03c59f15rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Draft minutes from IETF-99 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 07:22:09 -0000 --_000_e5034ef6db454b00a004469e03c59f15rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I uploaded these. Still time for corrections Thanks From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 02 August 2017 08:27 To: multipathtcp@ietf.org Subject: [multipathtcp] Draft minutes from IETF-99 Hi, Here are the draft minutes from Prague. Many thanks to our scribes - Dave, Ilpo and Brian - for the excellent notes= . Please send any updates and corrections. There are a couple of comments tha= t are missing (and my notes didn't help). Thanks Phil & Yoshi --- MP-TCP Session 1, Tuesday 15:50 scribes Dave Allan, Ilpo J=E4rvinen WG-status Implementation Updates - Chris Paasch - iOS and Linux Update "MPTCP in iOS11" slide Julius: who picks the mode, the user or developer? A: Developer. Julius: What does "only for developers" in one of the bullets mean? A: Can= only use it on a developer phone (with paid developer Apple account). Debashish: Wifi assist. if two interfaces on the cellular connection. A: We= do not support this. Debashish: we see some use cases where this is possible. Marcus: On iOS, do you plan on supporting proxies from the phone itself. A= : Can't comment. - Fabien Duchene - implementation results Alan: this is using vanilla 6824bis A: yes - other updates no update - hackathon news Quentin Alan: The general point is that the MP-TCP reset option was to carry additi= onal semantics. Timeout, again the reason codes had a general logic, if it = could be useful for an admin to analyze a problem, or analyze a bug. We don= 't necessarily need reason codes for everything. It has stuff like lack of = resources or ???, exactly the stuff we'd want to see for transient problems= . A: we can continue the discussion on mail. reaction to the experimental option: Alan: should be a fairly straightforw= ard. Julius: For the peanut gallery, what is the application of this? Alan: loca= l experiments - Alan Ford - RFC 6824bis Phil: A question to revisit on Friday, if there are any further suggestions= of extensions to the bis version before we declare victory. DO we have imp= lementations of all the new bits? Alan & Chris P: Linux is fine, but IOS is= not complete Alan: we have one implementation of everything. Discussion about hackathon MPTCP code availability, Chris P?: should all be= available once pushed out Phil: Is this sufficient to go standards track. Mirja: Up to the WG, will b= e justified in the shepherd's write up. Phil: Discuss timing a bit more on = Friday. Need a security area review to make sure they are happy. Proxies - Olivier, MPTCP Converters Jabber: When the converter translates TCP to MP-TCP, who decides to do this= , is it the client or the converter. A: do not understand the question. Alan Ford: How do we add another subflow to this? A: you have two MP-TCP co= nnections. If the client adds a subflow, one will be added between the conv= erter and the server. In many use cases you have a large numebr of connecti= ons. Alan: The presence of all this direct stuff tells you the server supp= orts MP-TCP, in the previous example it wasn't there. Vladimir: About TFO, isn't it dangerous to pass the TFO cookie to the clien= t vs. keep it in the converter? A: Depends on deployment. If you think of = a converter with a single IP address serving a lot of clients there may be = a problem. Pool of IP addresses, makes sense to send cookie back. Chris P. What happens if the converter changes its cookie, so there is a wr= ong cookie on the client side. A: you would not ack the message and have a= restart, normal TFO procedure. Julius: More comments after socks 6. Extensibility, what do you do with un= known TLV. A: there is an error TLV in the draft. Julius: Actual procedures= not described. You are only replying with a SYN-ACK when you get a SYN-ACK= from the other side. A: we want to test the connection to the server is wo= rking correctly. The connections do not always succeed. Some small changes = to be done in the stack interactions. Jabber: Only plain MP-TCP support is the client the middlebox. A: take that= question to the list. Mirja: this is an app layer protocol. And can be used for other things besi= des MP-TCP, so this may not be the right group. A: speaking as an individua= l. Mirja: Individual, but can change that anytime. Med: If we want this specific to MP-TCP, it is a matter of scoping the docu= ment. If it is a proxy just get the port number. Mirja: This is the right direction but not the right WG. Sounds a bit like = ICE (?). Oliver: This does match the charter item. Mirja: It does not need to be a W= G document, could still be elsewhere? Phil: We need to discuss perhaps in a= smaller venue. Alan Ford: This is very MP-TCP specific as far as app layer protocols go. I= t is in scope as an MP-TCP solution so IMO it is a good map with this WG. M= irja: Shop this around to other WGs. Julius: The use case comes from MP-TCP. Julius: This is a quite manageable document, written with an eye to impleme= ntability. There are no domain names, this is good. If this goes through o= ther WGs, will it still have this property. Oliver: Do not know. Do not want the converter to have to do a DNS lookup. = A side effect is that it becomes doable in kernels. Mirja: As an AD I'd recommend announcing this on the TSV AREA and TCP maili= ng lists. Phil: This is a nice to read document. I encourage everyone to read it. The= contributors really listened to the feedback from previous efforts. - Vladimir -SOCKS protocol version 6 Julius: In the late 90s, early 2000s, it was great to use SOCKS5, but we di= scovered one RTT was added to no benefit, it took 20 years to get that back= . Thank you. Need to stress how much Olivier and your drafts live in diffe= rent spaces. I think this has reason to exist even if Olivier's draft is al= so pursued. Generalizing often yields unmanagable protocols. I wonder if t= here is a way to talk to a proxy and know if a converter or SOCKS6. Vladimir: No sure how to answer that question. Should go like this. Hi, I w= ant to speak version X, server, I speak version Y. If client speaks SOCKS5 = then the server should speak SOCKS5. Olivier: We start with a fixed header with a version number. If the first t= ransaction had assigned ranges of version numbers for converter and for SOC= Ks then this would be possible. Julius: The initial truncation of data, needs some discussion, A: will amen= d the draft. Ben Schwartz: Similar proposal in DPRIV, ability to demux on first few byte= s is controversial as it constrains protocol design. Socks5 is incredibly w= idely deployed. Your proposal is an improvement. Agreeing on a new major ve= rsion number is close to being as big as that for HTTP. Probably should no= t be done in MP-TCP A: plan is to do this in INTAREA. Point out that the major improvement is in reduction of RTTs. Two use cases= , localhost, and remainder on a LAN with low latencies. SO the latency savi= ngs is useful, but only if SOCKs server is a large distance from you. The = TLS should be mandatory, or some other encryption. 4G and 5G have high dela= y, so going to get large RTT. Ben: Again funky security properties. None o= f the SOCKS5 clients today do any encryption between client and proxy. Plai= n text passwords. Outside a private LAN, TLS should be mandatory. Olivier: It does not use TFO, thanks for providing the code. AS for the exi= stence of HTTP proxies, there are other applications. Ben: HTTP connect is a superset of the functionality. Phil: Presenting this in INTAREA later in the week. A:Yes. MP-TCP Session 2, Friday 11:50 scribe Brian Trammell 3.3 Follow-up discussions from Tuesday's proxy discussions [15mins] Phil: SOCKS work will probably go forward in INTAREA. Converter discussion = was quite promising, people like the approach, need more time to read it. A= ny further comments in follow-up? Otherwise I suggest the authors rev the d= raft addressing comments, will work out which working group that should go = forward in. Discussion? 4. A security attack - Zhiyun Qian [15mins] See slide 8 in chair slides "MP-PRIO attack". MP-PRIO can be used by a MITM= to divert all traffic on to its own path, degrading to normal TCP. Removin= g address identifier from the option fixes this. Upcoming paper at ICNP. Alan Ford: MP-PRIO is a backup bit, predates the PRIO bit in the MP-JOIN, w= hich negates the point of this signal. Real question: is there a reason to = change the priority of a subflow from another subflow? Olivier: Attack important in practice. Multiple connection, can be used to = move all traffic to an untrusted network e.g. wifi. Don't know any implemen= ter that uses address identifier on MP-PRIO, so remove it. Keeps protocol s= imple and usable. Phil: Anyone unhappy with proposed solution, please hum. [Silence]. Okay wi= th it? [Tired hums]. Need more time? [Silence] 5. A proposal for MPTCP Robust session Establishment (MPTCP RobE) Markus Amend - "A proposal for MPTCP Robust session Establishment (MPTCP Ro= bE)" [15mins] Alan Ford: last slide covers everything I was going to say. Biggest killer = is no key in MP_CAPABLE. Semantics of the key simply aren't the same as wha= t you're using. Can't assume that two keys on the wire are the same identit= y. Most concerned as to how you see this working without the key, what's yo= ur way around it? Markus: Key missing in first SYN, can't use as identifier. Last ACK has bot= h keys available, then you can make the decision on the receiver side. Alan: Would not have been the same key B Markus: Host B answers with different keys B. Key B can be replaced... Alan: Security alarm bells. Can't point to just one thing. Very uncomfortab= le. Olivier: Good motivation, looking at Happy Eyeballs, though, this seems app= licable. Work in TAPS for racing, is the same problem. Application layer li= brary can do this, not application itself. Build a shim layer, then the app= -layer solution is easier. Markus: Then we have some overhead Olivier: But you can learn the network, and remember it, you don't have to = do this for every connection. Markus: Put it in the standard, not in the libraries, then it's general. Christoph: Important work. iOS uses the timer based approach. Independent o= f the transport layer protocol. Also, paths not equal. Markus: also delay. Brian: I like approach 1 but share Alan's concerns. No incremental deployme= nt, means you need negotiation, makes it more complex. Would that be done b= efore MP-QUIC is, for example? Approach 3, little bit more latency but less= complexity. Don't race in MPTCP layer; racing in two places is messy, and = you have to race v4v6 Anna: **missing** Separate robustness and latency 6. Proposal for a new Multipath TCP option Quentin De Coninck - "Every Millisecond Counts: Tuning Multipath TCP for In= teractive Applications on Smartphones" [15mins] Uma: Low latency very important, 5G etc. What is the gain you achieve with = you this approach over classical MPTCP? Quentin: Latency remains quite the same, but the cellular won't get establi= shed until you need to use it. Alan: Options in SYN before data, what are you signing with HMAC? No data u= ntil third ACK. What is DSN on slide 8? Are you sending data in the SYN? Quentin: Yes. Alan: Cool. Anna: Curious about impact on delay bet. detection to establish new subflow= and cost of setting it up. Magnitude important to see whole picture on lat= ency. Quentin: You see this with a low latency main net and a high latency second= net. When the nets are comparable, Phil: Is this a change to base protocol? Changes security properties? Quentin: Yes Christoph: Important to reduce handshake time. But when cell is down bringi= ng it back up again is very slow and in this case the handshake is lost in = noise. Do you have MB detection? Quentin: No but we could. 7. Better documenting interactions between MPTCP and TFO - Christoph [10min= s] Alan: I'd love to see this in bis, but I can't write the text Olivier: We will help. Michael Scharf: as TCPM chair, haven't been here for a while. In TCPM are t= hinking about moving TFO to PS. Does MPTCP have an opinion on this? Please = give input to tcpm list. Yoshi via jabber: different TFO cookies sizes for TCP and MPTCP? Christoph: implementation dependent, currently cookie reduced to 4 bytes, c= an be dynamic. Olivier: In bis, requirements on shorter cookies are relaxed, since MPCAPAB= LE is only 4 bytes. Important for MPTCP is DS mapping for SYN data. Phil: Anyone against including this in the bis? [Nobody]. Too early to deci= de? [Nobody] In favour [some noise]. Christoph, you and Olivier please work= up some text. Juliusz: Is it okay for MPTCP PS to refer to experimental TFO? Michael Scharf: TCPM can move TFO to PS if there were a problem Alan: TFO is informative in bis, so not a problem. 8. Using MPTCP on IPv6 only hosts in networks with NAT64 - Quentin [10mins] Mohamed Boucadair: There are means to discover NAT64, learn prefixes of all= NAT64, you have multiple in path, generic problem. DHCP option is not an o= ption, BEHAVE says don't do that, various issues. Juliusz: One POV that NAT64 is a hack that does not belong in the internet,= I hope for a burst of common sense. Wonder about accommodating for NAT64 b= rokenness within MPTCP. Mohamed: **nat discussion** Olivier: *missing, network issues* NAT64 will exist. Please use a well-know= n prefix. Christoph: This is a really big problem when the device is on a v6 only net= and we used to be a v4 only *net error* I think we could document this in = the bis. 9. Plans for progressing MPTCP [10mins] --_000_e5034ef6db454b00a004469e03c59f15rew09926dag03bdomain1sy_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I uploaded these. Still time for cor= rections

Thanks

 

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 02 August 2017 08:27
To: multipathtcp@ietf.org
Subject: [multipathtcp] Draft minutes from IETF-99=

 

Hi,

Here are the draft minutes from Prague. <= /p>

 

Many thanks to our scribes – Dave, Ilpo and Br= ian – for the excellent notes.

 

Please send any updates and corrections. There are a= couple of comments that are missing (and my notes didn’t help).

Thanks

Phil & Yoshi

 

---

 

MP-TCP Session 1, Tuesday 15:50

scribes Dave Allan, Ilpo J=E4rvinen

 

WG-status

 

Implementation Updates

- Chris Paasch - iOS and Linux Update

  "MPTCP in iOS11" slide

Julius: who picks the mode, the user or developer? A= : Developer.

Julius: What does "only for developers" in= one of the bullets mean?  A: Can only use it on a developer phone (wi= th paid developer Apple account).

 

 

Debashish: Wifi assist. if two interfaces on the cel= lular connection. A: We do not support this.

Debashish: we see some use cases where this is possi= ble.

Marcus:  On iOS, do you plan on supporting prox= ies from the phone itself. A: Can't comment.

- Fabien Duchene - implementation results=

   Alan: this is using vanilla 6824bis A: = yes

- other updates

no update

- hackathon news Quentin

Alan: The general point is that the MP-TCP reset opt= ion was to carry additional semantics. Timeout, again the reason codes had = a general logic, if it could be useful for an admin to analyze a problem, o= r analyze a bug. We don't necessarily need reason codes for everything. It has stuff like lack of resources or ?= ??, exactly the stuff we'd want to see for transient problems.  A: we = can continue the discussion on mail.

reaction to the experimental option:  Alan: sho= uld be a fairly straightforward. 

Julius: For the peanut gallery, what is the applicat= ion of this? Alan: local experiments

 

 

- Alan Ford - RFC 6824bis

Phil: A question to revisit on Friday, if there are = any further suggestions of extensions to the bis version before we declare = victory. DO we have implementations of all the new bits? Alan & Chris P= : Linux is fine, but IOS is not complete Alan: we have one implementation of everything.

Discussion about hackathon MPTCP code availability, = Chris P?: should all be available once pushed out

Phil: Is this sufficient to go standards track. Mirj= a: Up to the WG, will be justified in the shepherd’s write up. Phil: = Discuss timing a bit more on Friday. Need a security area review to make su= re they are happy.

 

 

Proxies

- Olivier, MPTCP Converters

Jabber: When the converter translates TCP to MP-TCP,= who decides to do this, is it the client or the converter. A: do not under= stand the question.

Alan Ford: How do we add another subflow to this? A:= you have two MP-TCP connections. If the client adds a subflow, one will be= added between the converter and the server. In many use cases you have a l= arge numebr of connections.  Alan: The presence of all this direct stuff tells you the server supports MP-TCP= , in the previous example it wasn't there.

Vladimir: About TFO, isn't it dangerous to pass the = TFO cookie to the client vs. keep it in the converter?  A: Depends on = deployment. If you think of a converter with a single IP address serving a = lot of clients there may be a problem. Pool of IP addresses, makes sense to send cookie back.

Chris P. What happens if the converter changes its c= ookie, so there is a wrong cookie on the client side.  A: you would no= t ack the message and have a restart, normal TFO procedure.

Julius: More comments after socks 6.  Extensibi= lity, what do you do with unknown TLV. A: there is an error TLV in the draf= t. Julius: Actual procedures not described. You are only replying with a SY= N-ACK when you get a SYN-ACK from the other side. A: we want to test the connection to the server is working correctly= . The connections do not always succeed. Some small changes to be done in t= he stack interactions.

Jabber: Only plain MP-TCP support is the client the = middlebox. A: take that question to the list.

Mirja: this is an app layer protocol. And can be use= d for other things besides MP-TCP, so this may not be the right group. A: s= peaking as an individual. Mirja: Individual, but can change that anytime.&n= bsp;

Med: If we want this specific to MP-TCP, it is a mat= ter of scoping the document. If it is a proxy just get the port number.

Mirja: This is the right direction but not the right= WG. Sounds a bit like ICE (?).

Oliver: This does match the charter item. Mirja: It = does not need to be a WG document, could still be elsewhere? Phil: We need = to discuss perhaps in a smaller venue.

Alan Ford: This is very MP-TCP specific as far as ap= p layer protocols go. It is in scope as an MP-TCP solution so IMO it is a g= ood map with this WG. Mirja: Shop this around to other WGs. 

Julius: The use case comes from MP-TCP. <= /p>

Julius: This is a quite manageable document, written= with an eye to implementability. There are no domain names, this is good.&= nbsp; If this goes through other WGs, will it still have this property.

Oliver: Do not know. Do not want the converter to ha= ve to do a DNS lookup. A side effect is that it becomes doable in kernels.<= o:p>

Mirja: As an AD I'd recommend announcing this on the= TSV AREA and TCP mailing lists.

Phil: This is a nice to read document. I encourage e= veryone to read it. The contributors really listened to the feedback from p= revious efforts.

 

 

- Vladimir -SOCKS protocol version 6

Julius: In the late 90s, early 2000s, it was great t= o use SOCKS5, but we discovered one RTT was added to no benefit, it took 20= years to get that back. Thank you.  Need to stress how much Olivier a= nd your drafts live in different spaces. I think this has reason to exist even if Olivier’s draft is also pur= sued.  Generalizing often yields unmanagable protocols. I wonder if th= ere is a way to talk to a proxy and know if a converter or SOCKS6.

Vladimir: No sure how to answer that question. Shoul= d go like this. Hi, I want to speak version X, server, I speak version Y. I= f client speaks SOCKS5 then the server should speak SOCKS5.

Olivier: We start with a fixed header with a version= number. If the first transaction had assigned ranges of version numbers fo= r converter and for SOCKs then this would be possible.

Julius: The initial truncation of data, needs some d= iscussion, A: will amend the draft.

Ben Schwartz: Similar proposal in DPRIV, ability to = demux on first few bytes is controversial as it constrains protocol design.= Socks5 is incredibly widely deployed. Your proposal is an improvement. Agr= eeing on a new major version number is close to being as big as that for HTTP.  Probably should not be do= ne in MP-TCP A: plan is to do this in INTAREA.

Point out that the major improvement is in reduction= of RTTs. Two use cases, localhost, and remainder on a LAN with low latenci= es. SO the latency savings is useful, but only if SOCKs server is a large d= istance from you.  The TLS should be mandatory, or some other encryption. 4G and 5G have high delay, so goin= g to get large RTT.  Ben: Again funky security properties. None of the= SOCKS5 clients today do any encryption between client and proxy. Plain tex= t passwords.  Outside a private LAN, TLS should be mandatory.

Olivier: It does not use TFO, thanks for providing t= he code. AS for the existence of HTTP proxies, there are other applications= .

Ben: HTTP connect is a superset of the functionality= .

Phil: Presenting this in INTAREA later in the week. = A:Yes.

 

 

 

 

 

MP-TCP Session 2, Friday 11:50

scribe Brian Trammell

 

3.3 Follow-up discussions from Tuesday's proxy discu= ssions [15mins]

Phil: SOCKS work will probably go forward in INTAREA= . Converter discussion was quite promising, people like the approach, need = more time to read it. Any further comments in follow-up? Otherwise I sugges= t the authors rev the draft addressing comments, will work out which working group that should go forward in. Dis= cussion?

 

4. A security attack - Zhiyun Qian [15mins]

See slide 8 in chair slides "MP-PRIO attack&quo= t;. MP-PRIO can be used by a MITM to divert all traffic on to its own path,= degrading to normal TCP. Removing address identifier from the option fixes= this. Upcoming paper at ICNP.

Alan Ford: MP-PRIO is a backup bit, predates the PRI= O bit in the MP-JOIN, which negates the point of this signal. Real question= : is there a reason to change the priority of a subflow from another subflo= w?

Olivier: Attack important in practice. Multiple conn= ection, can be used to move all traffic to an untrusted network e.g. wifi. = Don't know any implementer that uses address identifier on MP-PRIO, so remo= ve it. Keeps protocol simple and usable.

Phil: Anyone unhappy with proposed solution, please = hum. [Silence]. Okay with it? [Tired hums]. Need more time? [Silence]<= /o:p>

 

5. A proposal for MPTCP Robust session Establishment= (MPTCP RobE)

Markus Amend - "A proposal for MPTCP Robust ses= sion Establishment (MPTCP RobE)" [15mins]

Alan Ford: last slide covers everything I was going = to say. Biggest killer is no key in MP_CAPABLE. Semantics of the key simply= aren't the same as what you're using. Can't assume that two keys on the wi= re are the same identity. Most concerned as to how you see this working without the key, what's your way around it?=

Markus: Key missing in first SYN, can't use as ident= ifier. Last ACK has both keys available, then you can make the decision on = the receiver side.

Alan: Would not have been the same key B<= /p>

Markus: Host B answers with different keys B. Key B = can be replaced...

Alan: Security alarm bells. Can't point to just one = thing. Very uncomfortable.

Olivier: Good motivation, looking at Happy Eyeballs,= though, this seems applicable. Work in TAPS for racing, is the same proble= m. Application layer library can do this, not application itself. Build a s= him layer, then the app-layer solution is easier.

Markus: Then we have some overhead

Olivier: But you can learn the network, and remember= it, you don't have to do this for every connection.

Markus: Put it in the standard, not in the libraries= , then it's general.

Christoph: Important work. iOS uses the timer based = approach. Independent of the transport layer protocol. Also, paths not equa= l.

Markus: also delay.

Brian: I like approach 1 but share Alan's concerns. = No incremental deployment, means you need negotiation, makes it more comple= x. Would that be done before MP-QUIC is, for example? Approach 3, little bi= t more latency but less complexity. Don't race in MPTCP layer; racing in two places is messy, and you have to = race v4v6

Anna: **missing** Separate robustness and latency

 

6. Proposal for a new Multipath TCP option

Quentin De Coninck - "Every Millisecond Counts:= Tuning Multipath TCP for Interactive Applications on Smartphones" [15= mins]

Uma: Low latency very important, 5G etc. What is the= gain you achieve with you this approach over classical MPTCP?

Quentin: Latency remains quite the same, but the cel= lular won't get established until you need to use it.

Alan: Options in SYN before data, what are you signi= ng with HMAC? No data until third ACK. What is DSN on slide 8? Are you send= ing data in the SYN?

Quentin: Yes.

Alan: Cool.

Anna: Curious about impact on delay bet. detection t= o establish new subflow and cost of setting it up. Magnitude important to s= ee whole picture on latency.

Quentin: You see this with a low latency main net an= d a high latency second net. When the nets are comparable,

Phil: Is this a change to base protocol? Changes sec= urity properties?

Quentin: Yes

Christoph: Important to reduce handshake time. But w= hen cell is down bringing it back up again is very slow and in this case th= e handshake is lost in noise. Do you have MB detection?

Quentin: No but we could.

 

7. Better documenting interactions between MPTCP and= TFO - Christoph [10mins]

Alan: I'd love to see this in bis, but I can't write= the text

Olivier: We will help.

Michael Scharf: as TCPM chair, haven't been here for= a while. In TCPM are thinking about moving TFO to PS. Does MPTCP have an o= pinion on this? Please give input to tcpm list.

Yoshi via jabber: different TFO cookies sizes for TC= P and MPTCP?

Christoph: implementation dependent, currently cooki= e reduced to 4 bytes, can be dynamic.

Olivier: In bis, requirements on shorter cookies are= relaxed, since MPCAPABLE is only 4 bytes. Important for MPTCP is DS mappin= g for SYN data.

Phil: Anyone against including this in the bis? [Nob= ody]. Too early to decide? [Nobody] In favour [some noise]. Christoph, you = and Olivier please work up some text.

Juliusz: Is it okay for MPTCP PS to refer to experim= ental TFO?

Michael Scharf: TCPM can move TFO to PS if there wer= e a problem

Alan: TFO is informative in bis, so not a problem.

 

8. Using MPTCP on IPv6 only hosts in networks with N= AT64 - Quentin [10mins]

Mohamed Boucadair: There are means to discover NAT64= , learn prefixes of all NAT64, you have multiple in path, generic problem. = DHCP option is not an option, BEHAVE says don't do that, various issues.

Juliusz: One POV that NAT64 is a hack that does not = belong in the internet, I hope for a burst of common sense. Wonder about ac= commodating for NAT64 brokenness within MPTCP.

Mohamed: **nat discussion**

Olivier: *missing, network issues* NAT64 will exist.= Please use a well-known prefix.

Christoph: This is a really big problem when the dev= ice is on a v6 only net and we used to be a v4 only *net error* I think we = could document this in the bis.

 

9. Plans for progressing MPTCP [10mins]

--_000_e5034ef6db454b00a004469e03c59f15rew09926dag03bdomain1sy_-- From nobody Thu Aug 10 01:46:45 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EB613265D for ; Thu, 10 Aug 2017 01:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1uTeKUiyxl7B for ; Thu, 10 Aug 2017 01:46:42 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8323413265B for ; Thu, 10 Aug 2017 01:46:42 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id o86so515019pfj.1 for ; Thu, 10 Aug 2017 01:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0Az7WDYHgUzHl1E176454Z4QGAQO1+tccRHBOvPoI94=; b=ldzwueiwElpHsHR4pXcch5JpuNxgBhwOHcySuX3OjwsMnt5pcbKG/cvHO+zLeqP46F mgV3/9XRrzCCHTbwkouCreczC2Q7uJU8lk3MZkdfWqegB3Gl8XkBR7S2DDphvFwDgFqM VK/Y5LxmPrbzV1w85D7Vxu3BUYtZDROLyaC2gOlhdYCf1WcKWf67QFlSUdgBJY0rxtbt UTyzOS0G7vQlmBniytE95Wyl2jILgRH3KEvJZoLITl210/hleyA6aBrR3eU8j+PWOsE/ zD/9wVu5QiGrodRBo/TbKJL7xcsj/3C+PChOqbWjBKmRCRMxZlHqkk4/9EzUjjxpKEGJ lXsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0Az7WDYHgUzHl1E176454Z4QGAQO1+tccRHBOvPoI94=; b=HrIaI/pNHKECINZTPGyLJBpavmHQJUH91ZlKf9J3g3dcSpCRYDQ5KK82WbQET4NT2g 0PLHp33socV9xxkBzTf5+jTLbnxh+fqh+0ZRs85qeJ4nqJ0ZDjh1yEjhGPOpN8qmOYVt b/Nxt9JNYWXXam+129/kn+6ye/v+0SUznrI7YcHesv4TZ8P37GfPyhnIQHTZn0j5W73F C0RRS9+EgZuFml8gN3pYyXXAOfLMTJRsTxHvKcwLMjabcYebHQZzO5wX250JHWARyZOe bZxGoLiw0PKPe3EeeqoRCoVEe5hUn8tpdAvCS0DUX0IFZDuOpA5pcYCS199tV/mfq6EL D6zQ== X-Gm-Message-State: AHYfb5gEOEqktwz0GCmpWdr/lzwusIw4a7IgqKEuXjOaR4sw/K2B2uxD eZisIU3x4a2fSQ== X-Received: by 10.84.229.6 with SMTP id b6mr12490916plk.274.1502354801958; Thu, 10 Aug 2017 01:46:41 -0700 (PDT) Received: from [127.0.0.1] (107.182.176.120.16clouds.com. [107.182.176.120]) by smtp.gmail.com with ESMTPSA id e5sm11500194pgn.55.2017.08.10.01.46.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 01:46:41 -0700 (PDT) From: Vincent Stone Message-Id: <05010808-D254-4630-A49C-84F21CAA8175@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_17E05D57-506D-4CE3-AB31-D4F9FE533ABB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 10 Aug 2017 16:42:18 +0800 In-Reply-To: <20170809034815.GX3648@Chimay.local> Cc: multipathtcp@ietf.org To: Christoph Paasch References: <0940F5BC-7405-4AB0-9C73-E125B56F66B2@gmail.com> <20170809034815.GX3648@Chimay.local> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [multipathtcp] Regarding the release of sending buffer X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 08:46:43 -0000 --Apple-Mail=_17E05D57-506D-4CE3-AB31-D4F9FE533ABB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for your response. Let us say we take the preventing = retransmission approach. Can the middlebox/firewall notice that?=20 There is only 1 scenario in which the middlebox will deem the data = should be retransmitted( keep in mind that the data has already been = delivered correctly to the receiver because it has already been = acknowleged by Data ACK):=20 all following ACKs after the data has been lost/dropped(Just dropped = single ACK for the data is not enough because of accumulative ACK). In = that case the flow should be terminated anyway.=20 In fact, there is no way in which a middlebox can distinguish between = sender don't retransmit the packet and the retransmitted packet has been = lost. So I think it is safe to prevent the retransmission, thus we can = free the data upon receiving Data ACK safely. Best regards, Vincent > On Aug 9, 2017, at 11:48, Christoph Paasch > wrote: >=20 > 't look like "regular" TCP anymore. >=20 > Middleboxes and firewalls will start blocking this traffic and the = receiver > must also be able to gracefully handle this. >=20 > That's the reason why MPTCP tries hard to make every subflow look like = it is > regular TCP, besides a few TCP-options. --Apple-Mail=_17E05D57-506D-4CE3-AB31-D4F9FE533ABB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thanks for your response. Let us say we take the preventing = retransmission approach. Can the middlebox/firewall notice = that? 
There is only 1 scenario in which the = middlebox will deem the data should be retransmitted( keep in mind that = the data has already been delivered correctly to the receiver because it = has already been acknowleged by Data ACK): 
all = following ACKs after the data has been lost/dropped(Just dropped single = ACK for the data is not enough because of accumulative ACK). In that = case the flow should be terminated anyway. 
In = fact, there is no way in which a middlebox can distinguish between = sender don't retransmit the packet and the retransmitted packet has been = lost. So I think it is safe to prevent the retransmission, thus we can = free the data upon receiving Data ACK safely.

Best regards,
Vincent

On Aug 9, 2017, at 11:48, Christoph Paasch = <cpaasch@apple.com> wrote:

't look like "regular" TCP = anymore.

Middleboxes and firewalls will = start blocking this traffic and the receiver
must also be able to gracefully handle = this.

That's the reason why MPTCP = tries hard to make every subflow look like it is
regular TCP, besides a few = TCP-options.

= --Apple-Mail=_17E05D57-506D-4CE3-AB31-D4F9FE533ABB-- From nobody Thu Aug 10 01:47:48 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551CF12706D for ; Thu, 10 Aug 2017 01:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 am2zblv_YNkd for ; Thu, 10 Aug 2017 01:47:45 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F407126E3A for ; Thu, 10 Aug 2017 01:47:45 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id v77so401216pgb.3 for ; Thu, 10 Aug 2017 01:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=C0zXIT5hwkHcbU+nxh4cCWDHAoFLPAsKaeqRUoXhtMY=; b=C5busoetcnzZ1Fp2Kjwb6ged8RKAx7fDtaz7G5TS3wV8B3JxJMiE39Ptzr4Ws9lEG7 4rRFnrctaN8p43yUkPcWc6hzgQSkvwQdgoaAX1/VTPQPcq6287ZX/azvQSRZWfpVE7Lt wpk16967nBp8f+WVWQIEcZEDuNb+kR/4/OA6PXBowzjo9289SDJ8ypuuehp4oF4Vv9lT Nv4xWMxQfakjlbRd6gbzf1rMn4r05Gf+LVOgMPaF1DBmps2c78z/an5aiVDkSIyO0dEN qZ/CkovDLRIUeWkQf2A27CodWy0oD8pnQbyRnvZa1BDM4m7Tt//CBpnhXuPRmrFAY0Ey DTWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=C0zXIT5hwkHcbU+nxh4cCWDHAoFLPAsKaeqRUoXhtMY=; b=K4KRgm6KYxgNl61PeIqMo/bIimfw8DUyLXvl8C10YL1gjwq4WAW59rjJddpvWHhD7t GGXO4bX8c3W3GbAS7bQhe9iAfItqqIMj7tI5CQvm7CkqA0Jujmp88A6qqiX/qdqASnki Kt4tjAvDJ9kzEc3pMEZntow1YAjU+xwGu3nhS9D+J5+SH/5LapKzgARsbRsOhyyhj4Cs pC2mWESKSsGRQGhTns2IGZq9DLLe4X7yjHxGwjLjtQRzTd9qT0zKmaFIQuMB7g3G/WQ6 yW0qJHNW7uoJ0qu4kArZ9Nl/L8i2picggWxZdx+ztTRZuCC/QM3JLgO1PVe5kz9qpJr9 xB1A== X-Gm-Message-State: AHYfb5j6HuApjOTR0lV7HOHGw34tXpWyT3dW+8nTwvzJYB/DPplbb5MH 4VoYhvSIFQjOqg== X-Received: by 10.98.212.92 with SMTP id u28mr11186197pfl.316.1502354864440; Thu, 10 Aug 2017 01:47:44 -0700 (PDT) Received: from [127.0.0.1] (107.182.176.120.16clouds.com. [107.182.176.120]) by smtp.gmail.com with ESMTPSA id 84sm9283106pgd.48.2017.08.10.01.47.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 01:47:43 -0700 (PDT) From: Vincent Stone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CC04B9C3-2E5B-4F4D-9C8F-D4FB969DD9F2" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 10 Aug 2017 16:47:41 +0800 In-Reply-To: <20170809034815.GX3648@Chimay.local> Cc: multipathtcp@ietf.org To: Christoph Paasch References: <0940F5BC-7405-4AB0-9C73-E125B56F66B2@gmail.com> <20170809034815.GX3648@Chimay.local> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [multipathtcp] Regarding the release of sending buffer X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 08:47:47 -0000 --Apple-Mail=_CC04B9C3-2E5B-4F4D-9C8F-D4FB969DD9F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for your response. Let us say we take the preventing = retransmission approach. Can the middlebox/firewall notice that?=20 There is only 1 scenario in which the middlebox will deem the data = should be retransmitted( keep in mind that the data has already been = delivered correctly to the receiver because it has already been = acknowleged by Data ACK):=20 all following ACKs after the data has been lost/dropped(Just dropped = single ACK for the data is not enough because of accumulative ACK). In = that case the flow should be terminated anyway.=20 In fact, there is no way in which a middlebox can distinguish between = sender don't retransmit the packet and the retransmitted packet has been = lost. So I think it is safe to prevent the retransmission, thus we can = free the data upon receiving Data ACK safely. Best regards, Vincent > On Aug 9, 2017, at 11:48, Christoph Paasch > wrote: >=20 > 't look like "regular" TCP anymore. >=20 > Middleboxes and firewalls will start blocking this traffic and the = receiver > must also be able to gracefully handle this. >=20 > That's the reason why MPTCP tries hard to make every subflow look like = it is > regular TCP, besides a few TCP-options. --Apple-Mail=_CC04B9C3-2E5B-4F4D-9C8F-D4FB969DD9F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thanks for your response. Let us say we take the preventing = retransmission approach. Can the middlebox/firewall notice = that? 
There is only 1 scenario in which the = middlebox will deem the data should be retransmitted( keep in mind that = the data has already been delivered correctly to the receiver because it = has already been acknowleged by Data ACK): 
all = following ACKs after the data has been lost/dropped(Just dropped single = ACK for the data is not enough because of accumulative ACK). In that = case the flow should be terminated anyway. 
In = fact, there is no way in which a middlebox can distinguish between = sender don't retransmit the packet and the retransmitted packet has been = lost. So I think it is safe to prevent the retransmission, thus we can = free the data upon receiving Data ACK safely.

Best regards,
Vincent

On Aug 9, 2017, at 11:48, Christoph Paasch = <cpaasch@apple.com> wrote:

't look like "regular" TCP = anymore.

Middleboxes and firewalls will = start blocking this traffic and the receiver
must also be able to gracefully handle = this.

That's the reason why MPTCP = tries hard to make every subflow look like it is
regular TCP, besides a few = TCP-options.

= --Apple-Mail=_CC04B9C3-2E5B-4F4D-9C8F-D4FB969DD9F2-- From nobody Thu Aug 10 09:21:41 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0058F1323A8 for ; Thu, 10 Aug 2017 09:21:32 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 jqKGfEC3cT5F for ; Thu, 10 Aug 2017 09:21:28 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 AB28B13239E for ; Thu, 10 Aug 2017 09:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1502382087; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IStno7p19M2MB7Cw6HtMc4V6eOQfxfCbBKqwRQw1OSU=; b=cER5qIOn8xV07SaDZDHiTsf1MkettVnpN8gxaD4tmuJnhZly3+JPhGwHff8Gml/4 6CnJZOPINOVscrWHICVoAB9O0zGqGKQa2bSNFWzgvdA26Uqn3mblHdzfsmgcnZMt DVd2yk0zgwXZ6grnEUpJdsnttfJa1bMj31TlFFq3wzCOuWfhzYN/XwO2QWdp7rcx k1gXvSYySOUAVMr6mJVkXr7iaqmM/VyTdIYgOxQLlXa/X/ojkidgZpGWv1dv6qcE KznVWxSLT4vOvnoRXLqFKIYNzrOX3uM0ChEDmeBeQw66aboD7wdph6Pm2KYtHWT/ KwA3lfAxMtoor+aKSowAaA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id FD.F3.08001.7088C895; Thu, 10 Aug 2017 09:21:27 -0700 (PDT) X-AuditID: 11ab0217-0ed229c000001f41-e5-598c8807e24f Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay8.apple.com (Apple SCV relay) with SMTP id 7A.BE.06978.7088C895; Thu, 10 Aug 2017 09:21:27 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from localhost ([17.150.219.132]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUH00EZD9FR7970@nwk-mmpp-sz09.apple.com>; Thu, 10 Aug 2017 09:21:27 -0700 (PDT) Sender: cpaasch@apple.com Date: Thu, 10 Aug 2017 09:21:26 -0700 From: Christoph Paasch To: Vincent Stone Cc: multipathtcp@ietf.org Message-id: <20170810162126.GJ3755@Chimay.local> References: <0940F5BC-7405-4AB0-9C73-E125B56F66B2@gmail.com> <20170809034815.GX3648@Chimay.local> In-reply-to: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FCYpsve0RNp8L7b3OLz6utsFocubGJ3 YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDI+fgsrWMBbcfPnU+YGxlNcXYycHBICJhLz 9+9mB7GFBNYySaz7IgQTn3x8AmsXIxdQ/CCjxL4l78CKeAUEJX5MvsfSxcjBwSwgL3HwvCxI mFlAWuLR3xnsELaWxPdHrSwQvU1MEjN3XmQDSQgLSEp037nDDGKzCKhKzJn4FSzOBtTw9nY7 K4gtIqAjsfXTPjaIQZISK/5+YoXodZbYveQ6K8QNBhLNM3YzQSyYxijxZc9GJpAEp4CtRNuT 02BXiAooS/w9fA/sCgmBKWwSW642sUxgFJmF5IlZCE/MQvLELCRPLGBkWcUonJuYmaObmWdk rJdYUJCTqpecn7uJERQLq5nEdzB+fm14iFGAg1GJh/eDZk+kEGtiWXFl7iFGaQ4WJXFel/Pd kUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY2f+strGqU6yuOR2+QuLH/LWnr4RsXXC70vpS 5bZNVg/iXSb6sUufqJXjFzXK+cS5rdJujZNPnMH0ZxOvplXUv0pOdJVT0Xjt4WT0V/LwqZ9u uz9cij0uuT9f/Kd9cMR51dXdEn/Y865fep/CeqR2wu/ih9+1M+Suhv1f6uXJciBPvv6U58cY JZbijERDLeai4kQA6Y43s2YCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUi2FAcoMve0RNpsOaYnMXn1dfZLA5d2MTu wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGV8/BZWsIC34ubPp8wNjKe4uhg5OSQETCQm H5/A2sXIxSEkcJBRYt+Sd+wgCV4BQYkfk++xdDFycDALyEscPC8LEmYWkJZ49HcGO4StJfH9 USsLRG8Tk8TMnRfZQBLCApIS3XfuMIPYLAKqEnMmfgWLswE1vL3dzgpiiwjoSGz9tI8NYpCk xIq/n1ghep0ldi+5zgpxg4FE84zdTBALpjFKfNmzkQkkwSlgK9H25DTYFaICyhJ/D99jmcAo OAvJ3bMQ7p6F5O5ZSO5ewMiyilGgKDUnsdJCL7GgICdVLzk/dxMjOHQL03YwNi23OsQowMGo xMObINodKcSaWFZcmXuIUYKDWUmEt6OyJ1KINyWxsiq1KD++qDQntfgQozQHi5I47/QOoGqB 9MSS1OzU1ILUIpgsEwenVANjZpBAqZNJAIvavsun5Z0yPq1JmXux10Oy+T7DeU+3AuXyh2+e z1L1rrMLu5v+cFt/qFXqtRSeFv/YVy9TmvNf+plJ1XrlRokHFlnUF+ds5224++eQFqvKjFly OyR5fXtOaCtM6p/3gSfUrXGyxZ3Y6jkbj8VLv4hl47pou0LtsOzf3Z//GiuxFGckGmoxFxUn AgCvIlOKWQIAAA== Archived-At: Subject: Re: [multipathtcp] Regarding the release of sending buffer X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 16:21:32 -0000 Hello, On 10/08/17 - 16:47:41, Vincent Stone wrote: > Thanks for your response. Let us say we take the preventing retransmission approach. Can the middlebox/firewall notice that? yes, because the firewall will see a hole in the sequence-number space. > There is only 1 scenario in which the middlebox will deem the data should be retransmitted( keep in mind that the data has already been delivered correctly to the receiver because it has already been acknowleged by Data ACK): > all following ACKs after the data has been lost/dropped(Just dropped single ACK for the data is not enough because of accumulative ACK). In that case the flow should be terminated anyway. > In fact, there is no way in which a middlebox can distinguish between sender don't retransmit the packet and the retransmitted packet has been lost. So I think it is safe to prevent the retransmission, thus we can free the data upon receiving Data ACK safely. What the middlebox will see with regular TCP is that first there is a hole in the sequence-number space and then the sender will retransmit it, thus filling the hole. If we don't retransmit, the hole will never be filled up and the middlebox might stall the flow. Christoph > > Best regards, > Vincent > > > On Aug 9, 2017, at 11:48, Christoph Paasch > wrote: > > > > 't look like "regular" TCP anymore. > > > > Middleboxes and firewalls will start blocking this traffic and the receiver > > must also be able to gracefully handle this. > > > > That's the reason why MPTCP tries hard to make every subflow look like it is > > regular TCP, besides a few TCP-options. > From nobody Sat Aug 12 01:50:21 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31DA13274D for ; Sat, 12 Aug 2017 01:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6wz7HV50_RJP for ; Sat, 12 Aug 2017 01:50:18 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3F313274A for ; Sat, 12 Aug 2017 01:50:18 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id v189so23987875pgd.2 for ; Sat, 12 Aug 2017 01:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lsle5QjMjUJbmSTUGTO5e1mT1j3nPXyRqjG/UutHRQ4=; b=TCbu6gXNVMSLMgkyA0676wPEgdoErzDJTmaI7d7KAs1EUXVCP9rdBv8RbCRb7kjTXg 7hzImg2Ej/pJrzKW0WT0y8NdpKOOIq9eaTnR1SNox0BtCgehGHtuV3tnLhhDe8I++9Rp piNCTgeQKzI1kTlOMeIM2xPVkF4UhejhS3fRnjP5LRsKORogA7mz3rDuwb4ZbNlyNr6F nu3k3Atv5TCeGWjEPUQ2Gg6wP0VWIMln5N3HZaS2VUwiJVBXEPHqBfeexGLb9zibyQRy OKhrVNHFkPdXB2rvCiJ0y5QRpH8WBXO3rC8NftBjjPy9TXkuI6kh1JBYNNwe8+j2ku4Z QtRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lsle5QjMjUJbmSTUGTO5e1mT1j3nPXyRqjG/UutHRQ4=; b=sY9P396EKcNuoKkDEg+RY52TJ/MML2vT/5xEPDfRnkSNkLPUm0RZdnSWbn2DVtWEyi 3w9TqStvBz/omqtsGqcmB2PKolEjiLAee3nXpWtAfs91g6nAhU457OUfKv7tdLs98D2x 0nuh2APGJ6Df0aB3CtV4uT2Sm8iLpzhTQp6t6D7pxwcoW7K6ZyxGSdw35DtN912/4Nix NseeBI80X+1SzNoY6uFZg1c55c4OgHxBB37T+oywXL3ZrgymxRUyIOeWHsKBULbVWGLw KL+p2vDXlhC8Q8eq1Qwshr0dDyyqUhJcSSHcOENgtaWfTd5zwLZWck6Gd7macdjIVtqc pS/A== X-Gm-Message-State: AHYfb5iUbNuLa+/oYwr5z+L3PTImC3jRnhMhbx3FFOi9P7p7qj33RbiB y7Wryh7Usot/lg== X-Received: by 10.84.128.108 with SMTP id 99mr20469474pla.167.1502527818312; Sat, 12 Aug 2017 01:50:18 -0700 (PDT) Received: from [127.0.0.1] (107.182.176.120.16clouds.com. [107.182.176.120]) by smtp.gmail.com with ESMTPSA id v134sm4994660pgb.58.2017.08.12.01.50.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2017 01:50:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Vincent Stone In-Reply-To: <20170810162126.GJ3755@Chimay.local> Date: Sat, 12 Aug 2017 16:50:14 +0800 Cc: multipathtcp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6583CF4F-66C5-4121-97A4-B634D05CF8C5@gmail.com> References: <0940F5BC-7405-4AB0-9C73-E125B56F66B2@gmail.com> <20170809034815.GX3648@Chimay.local> <20170810162126.GJ3755@Chimay.local> To: Christoph Paasch X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [multipathtcp] Regarding the release of sending buffer X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 08:50:20 -0000 > If we don't retransmit, the hole will never be filled up and the = middlebox > might stall the flow. The hole in sequence-number space can be filled either by retransmitted = packet or subsequent accumulative ACK. Even if we don't retransmit the = packet, the hole will be filled up by accumulative ACK sooner or later. = If not, that means all following ACKs have been lost. In that case the = flow should be terminated anyway.=20 And middlebox can not distinguish between no-retransmition of the packet = and the lost retransmitted packet.=20 Best regards, Vincent. > On Aug 11, 2017, at 00:21, Christoph Paasch wrote: >=20 > Hello, >=20 > On 10/08/17 - 16:47:41, Vincent Stone wrote: >> Thanks for your response. Let us say we take the preventing = retransmission approach. Can the middlebox/firewall notice that?=20 >=20 > yes, because the firewall will see a hole in the sequence-number = space. >=20 >> There is only 1 scenario in which the middlebox will deem the data = should be retransmitted( keep in mind that the data has already been = delivered correctly to the receiver because it has already been = acknowleged by Data ACK):=20 >> all following ACKs after the data has been lost/dropped(Just dropped = single ACK for the data is not enough because of accumulative ACK). In = that case the flow should be terminated anyway.=20 >> In fact, there is no way in which a middlebox can distinguish between = sender don't retransmit the packet and the retransmitted packet has been = lost. So I think it is safe to prevent the retransmission, thus we can = free the data upon receiving Data ACK safely. >=20 > What the middlebox will see with regular TCP is that first there is a = hole in the > sequence-number space and then the sender will retransmit it, thus = filling > the hole. >=20 > If we don't retransmit, the hole will never be filled up and the = middlebox > might stall the flow. >=20 >=20 > Christoph >=20 >>=20 >> Best regards, >> Vincent >>=20 >>> On Aug 9, 2017, at 11:48, Christoph Paasch > wrote: >>>=20 >>> 't look like "regular" TCP anymore. >>>=20 >>> Middleboxes and firewalls will start blocking this traffic and the = receiver >>> must also be able to gracefully handle this. >>>=20 >>> That's the reason why MPTCP tries hard to make every subflow look = like it is >>> regular TCP, besides a few TCP-options. >>=20