[multipathtcp] Draft minutes from MPTCP WG meeting

[<[e-mail]>]

Here are the draft minutes for the WG meeting on Monday. Please let us know of any corrections.

Many thanks to Pasi and Alan for taking the notes


Multipath TCP (MPTCP)
Draft agenda Date: Monday, November 2, 2015, 9:00 - 11:30 (Morning Session I)
Room: 413

Taking notes: Pasi Sarolahti

- Intro - Chairs [15mins]
-------------------------

* Status Updates

* Discussion on interim meeting output and other progression between meetings: E.g. increasing version number, which opens possibility to redesign signaling

* Chairs: Realistic to last call before next IETF?

* Christoph Paasch: depending on how much we change the spec, it may be difficult to get done by next IETF, but will try to do that

* Shaoib Rao: why decided to drop implementation advice?

* Phil Eardly: Implementation People thought that the protocol documentation was sufficient

** Shaoib Rao: why do we support both 8-byte and 4-byte fields? why do we want to support 4 bytes?

** Yoshi Nishida: already discussed and consensus-called before

** Christoph: good point, people would not switch to 8 bytes, but will be longer discussion to change this. Linux implementation support receiving both variants, but never sends 8 bytes

** Shaoib Rao: If timestamp option is mandatory, we would not need 8 bytes

** Alan Ford: we would not need to use timestamp option with 8-byte option, but some people might have other uses. Linux does not need to send both if it can accept. If we only support 8 bytes, what problem would it solve? makes simpler implementation, but it is only optional to implement

** Christoph: decission can be triggered by application based on envrionment

** Shaoib Rao: receiver should need to support both variants always.

** Shaoib: what is the motivation for 4 bytes?

** Alan: saving option space

** Shaoib: Header option placement is also problematic, alignment is important

** Alan: space constraints are problem

** Chistoph: implementation choice, can place options otherwise

** Yoshi: making 8 bytes mandatory, 4 bytes optional, would that make people happy?

** Alan: that's basically what we already have. If we spell out more explictly that sending is optional and receiving mandatory, would you be happier? Conclusion: nothing fundamentally changes, but we spell out more clearly in the draft that sending is optional

Implementation updates:

** Shaoib: implementing MPTCP in Solaris kernel, seems to be working well


- Making Multipath TCP robust for stateless webservers - Christoph Paasch (10 mins)    (draft-paasch-mptcp-syncookies)
------------------------------------------------------

(going through slides)

Yoshi: implementation status?

Christoph: no implementation yet

Phil: any implementation plans in Louvain?

Fabien Duchêne: no plans for implementation at Louvain yet

Shaoib: can try to implement but can't estimate when? Seems very complicated but does seem necessary. Yes, seems relevant.

Phil: this would not be backward compatible

Alan: yes this is v1, not v0. Earlier you did not need to put key in data ACK, now you do need keys in data-ack

Alan: would love to get consensus on this, so that we can work forward

Phil: plan to give it a week or two, then do an explicit consensus call


- Reflecting on the MPTCP handshake" - Christoph Paasch (20 mins)
(draft-paasch-mptcp-loadbalancer + security)
--------------------------------------------

* Shaoib (on deployment behind L4 loadbalancers): question about currently deployed solution (missed)

* Christoph (answering): Netscaler is L7 load balancer, terminates connections

* (missed Alan's question/comment)

* Yoshi: is token used only for server?

* Christoph: use is to identify the MPTCP connection, for single server this works well

* Yoshi: you want to change meaning only for one use case?

* Christoph: increasing information that the token carries

* Alan: to summarize: you want to decouple token from key. makes lot of sense, seems fine. from signaling point of view: have flag to get key form external source, to say that key comes from TLS or somewhere else. Logical extension to what we got. Earlier we completely ran out of option space when trying to do this. Maybe we should wait for TCPINC, to see if they give some additional tools

* Christoph: worried about TCPINC, not sure how quick they are going to proceed.

* Phil: we should be able to finish our work earlier

* Alan: this does not need to be part of base v1 spec, but additional mechanism.

* Christoph: can live very well with the TLS, but getting locally meaningful token would be a big issue.

* Phil: are the two issues (loadbalancers, security) totally separable issues?

* Christoph: need to make token meaningful

* Alan: TLS is a potential solution to the problem

* Christoph: might we just decrease the size of the keys, they are already sent in the clear. Are there any MPTCP deployments that are not using TLS, and think seeing keys in clear is fine.

* Alan: our goal has never been to provide secure solution, but something equivalent to TCP.

* Alan: this should be specified in a separate draft, at least initially... concerned that this is a distraction, makes a jump away from where we are.

* Christoph: can we try to see whether we want to solve one of those issues?

* Phil: comments? personally think the datacenter case is important to solve. Should be designing for the present, not the future.

* Christoph: do you think it is worthwhile to have draft to support discussion?

* Yoshi: yes

* Phil: wider issue: should there be more flexibility about the security solution?

* Alan: we already have that kind of flexibility, haven't yet specified what the negotiation means. Would need to work through the details.

* Daniel Giffin: Both main TCPINC have been adopted to specify the negotiation of encryption protocol, also uses session ID (TCP-ENO), you might find that is useful.

* Christoph: We are deferring key exchange until after the SYN, could do it already in SYN, maybe this would make it simpler in terms of signaling.

* Phil's conclusion: make a draft about the possible solution space


- Mptcp enduser use cases and enhancement opportunities - Chetan Harsha   (20 mins)   (draft-palanivelanchetansenthil-mptcp-enhancements)
-----------------------------------------------

* Christoph: is it separate TCP connections when MPTCP is disabled (about slide on upload latency graph, with number of subflows)

* Chetan: yes

* Yoshi: why the red line behaves so differently with ups and downs?

(some discussion clarifying the graphs)

* Phil: interested in hearing about protocol tweaks you might suggest?

* Chetan: not sure yet what the changes could be, currently just some parameters

* Christoph: there is generally need for more signaling in MPTCP, to indicate subflow characteristics, to help scheduling traffic, but it is a bigger change is protocol.

* David Allan: if you are going to depend a lot on end-user signaling, makes life difficult for proxies.

* Shaoib: performance depends also on scheduler, that's why MPTCP results differ.


- LISA: A Linked Slow-Start Algorithm for MPTCP  - Runa Barik          (20 mins)    (draft-barik-mptcp-lisa)
----------------------------------------

* Yoshi: if bottleneck is not shared, we don't have to use slow-start?

* Runa: we are reducing latency in non-shared scenario also. Some differences are explained that paths are both 3G or WiFi.

(some additional discussion clarifying the results)

* Ilpo Järvinen: not sure why number of retransmissions affects the way you say

* Runa: because of slow-start loss it is explained, not understanding Ilpo's point

* Christoph: could be nice to see the patch and paper traces.

* Runa: will do, but currently a paper in submission.

* Phil: hard to understand

* Michio Honda: your point that slowing down slow start will reduce retransmissions, does not work in large delay-bw environments. Should see graphs relating to BDP. Current parameters are unrealistic.


Management information base for MPTCP - Fabien Duchêne(15 mins)
(draft-duchene-mptcp-mib-00)
------------------------------------------

* Shaoib: thank you, this is very useful. One thing missing: what are the combinations of the flows supporting MPTCP vs. TCP. Port numbers, addresses as well.

* Fabien: will look at them, because wanted to keep it simple, might be getting complicated, but is interesting

* Phil: good to have more feedback

* Yoshi: question to AD: when we define MIB, do we need cross-area review?

* Martin Stiemerling: should get MIB doctor review, might be useful to ask them when you have stable version, but before WGLC.

* Phil: should it be WG document before doing it? A: yes.

* Phil: plan to make this WG document before the next IETF


Phil: Update of Louvain Linux implementation? in terms of getting to mainline kernel

* Fabien: Nothing much to report

* Christoph: there are lot of users, but no contributions that come back


MPTCP for FreeBSD update  - Grenville Armitage (5 mins)
-------------------------------------------

* Phil: anybody here interested in FreeBSD stuff (no hands)

* Phil: how much does the current version implement?

* Grenville: the URL on slides will describe the features

-- Meeting concluded at 11:15 --




Philip Eardley
Research and Innovation
This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000