* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Mptcp Status Pages

Multipath TCP (Active WG)
Tsv Area: Mirja Kühlewind, Spencer Dawkins | 2009-Oct-15 —  
Chairs
 
 


IETF-99 mptcp minutes

Session 2017-07-18 1550-1750: Athens/Barcelona - Audio stream - mptcp chatroom
Session 2017-07-21 1150-1320: Congress Hall I - Audio stream - mptcp chatroom

Minutes

minutes-99-mptcp-00 minutes



          MP-TCP Session 1, Tuesday 15:50
          scribes Dave Allan, Ilpo Järvinen
          
          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
          additional 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
          straightforward.
          Julius: For the peanut gallery, what is the application 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. Mirja: 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 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
          connections. If the client adds a subflow, one will be added between
          the converter and the server. In many use cases you have a large 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 cookie, so there is
          a wrong 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 unknown 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 working 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
          besides MP-TCP, so this may not be the right group. A: speaking as an
          individual. Mirja: Individual, but can change that anytime.
          Med: If we want this specific to MP-TCP, it is a matter 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 app layer protocols
          go. It is in scope as an MP-TCP solution so IMO it is a good map with
          this WG. Mirja: 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
          implementability. There are no domain names, this is good.  If this goes
          through other 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
          mailing 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 discovered 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 different spaces. I think this has reason to exist even if
          Olivier’s draft is also pursued.  Generalizing often yields unmanagable
          protocols. I wonder if there 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 want 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 transaction had assigned ranges of version numbers for converter
          and for SOCKs then this would be possible.
          Julius: The initial truncation of data, needs some discussion, 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. Agreeing
          on a new major version number is close to being as big as that for HTTP.
          Probably should not 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 savings 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 delay, so going to get large RTT.  Ben: Again funky
          security properties. None of the SOCKS5 clients today do any encryption
          between client and proxy. Plain text passwords.  Outside a private LAN,
          TLS should be mandatory.
          Olivier: It does not use TFO, thanks for providing the 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 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. Any further comments in follow-up? Otherwise I suggest the authors
          rev the draft 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. Removing 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,
          which 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
          implementer that uses address identifier on MP-PRIO, so remove it. Keeps
          protocol simple and usable.
          Phil: Anyone unhappy with proposed solution, please hum. [Silence]. Okay
          with 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
          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 wire 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 identifier. 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
          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 problem. Application
          layer library 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
          of the transport layer protocol. Also, paths not equal.
          Markus: also delay.
          Brian: I like approach 1 but share Alan's concerns. No incremental
          deployment, means you need negotiation, makes it more complex. Would
          that be done before 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 Interactive 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
          established until you need to use it.
          Alan: Options in SYN before data, what are you signing with HMAC? No data
          until 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 latency.
          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
          bringing 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
          [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 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,
          can be dynamic.
          Olivier: In bis, requirements on shorter cookies are relaxed, since
          MPCAPABLE 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 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 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 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 accommodating
          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 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]
          
          



Generated from PyHt script /wg/mptcp/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -