Minutes for MPTCP at IETF-96
minutes-96-mptcp-1
| Meeting Minutes | Multipath TCP (mptcp) WG | |
|---|---|---|
| Date and time | 2016-07-18 13:40 | |
| Title | Minutes for MPTCP at IETF-96 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2016-08-09 |
minutes-96-mptcp-1
Multipath TCP (MPTCP)
Meeting : IETF96, Monday July 18, 2016, 15:40-17:00
Location : Charlottenburg I
Chairs : Philip Eardley
Yoshifumi Nishida
AD : Mirja Kühlewind
URL : http://tools.ietf.org/wg/mptcp/
Note Taker: Mirja Kühlewind
--------------------------------------------------------------------------
1: RFC6824bis discussion
Rolf:
Siri data set?
Christoph:
connection are per-siri request
Costin:
Controlled number of iphones for this experiment?
Christoph:
Tuned off (and on) syn-cookies and collected data on the server
Phil:
'loss' means third ACK is loss and you compare the amount of total
data retransmitted
Christoph:
benefit where there is in general more loss
Costin:
I see the point but that obvious
Christoph:
making the third ACK reliable is important because it makes MPTCP
fallback less where you need it
Costin:
depends because you can also get stuck with bad wifi because user try
to stick to wifi
Christoph:
other case when you walk out of home and then wifi becomes lossy
Costin:
all per flow data?
Christoph:
yes
Phil:
Is there a transition/deployment problem when we bump the version
number?
Christoph:
not worried about it because we know the servers and the version number
to ensure that right client is connected to right server
Costin:
Good question. Other people that run MPTCP...?
If both end under control, we know it's no problem. So are there
deployments where you interoperate with other stacks? Please come and
tell
Rao Shoaib:
How does versioning work if I don't have both under control
Alan: Additional functional has to be added anyway. You can use negotiation
or versioning.
Specify highest number you support, e.g. client and server both
support 1 it's fine. Client with version 0 and server only 1 doesn't
work.
Costin:
I pushed to re-discuss version number bump because I'm really worried
about transition because should not make things worse and should be
worth the pain for the right reason. If client runs version 1 by
default, server will drop it
Alan:
It's true but will only drop to TCP. Could even add flag that says a
need a capability, server would also drop
Costin:
How to treat the 2% from Christoph, for long term. We need to
understand the benefit
Rao:
Why not fallback to version 0?
Costin:
because that's an additional fallback
Christoph:
client falls seamlessly fall-back to zero
Alan:
not within the same connection. Trade-off between short term
transition vs. long term simpler implementation that is desirable.
Christoph: ????
Alan:
if we only use flag, it's kind of version numbers anyway
Costin:
but you don't have to do happy-eye for versioning
Alan:
only if server also supports version zero
Costin:
Are implementors happy with that
Phil:
Olivier or Fabien?
Oliver:
no strong opinion; will add complexity to stack but don't have
resources at ucl to do that. there are companies that could to it
Rao:
don't want to support two different versions but flags will also cause
problems with clients. We can't have clients that cannot connect if
there is no backward-compatibility
Alan:
there is a solution if server supports both versions. But modern
servers might not do that. But if you want to get all functionality
you have to do that anyway. Why not make it simple in the bis draft
with the lessons we learnt
Rao:
not problem but costumer has version we need to work with and fallback
and support it; might be problematic for implementation
Christoph:
integrating lesson learnt is now because there is not yet much
deployment
Rao:
if we upgrade we should enhance on versioning
Alan:
field says that it's the highest version I support
Rao:
but server might only support one version; should we send back what is
supported
Alan:
client support 0 and server only 1; it doesn't work. Otherwise it
would. That's the only case where you wouldn't get mptcp compared to
today. But defined protocol for experiments
Costin:
It's a large software change and we should not underestimate that
effort; How can we support those feature without bumping there version
number. Benefit are 2% of connection that will work, everything else
can be provided without new version
Christoph:
saving option space
Costin:
don't care
Olivier:
should not be in situation where we are at version 5 and need to
support all others as well. Need to tell which one is supported and
fallback to regular TCP otherwise
Alan:
yes, that's an easy change and we can make this happen. Costin's point
about flags: I have trouble to see how it fits in this working group;
you have one flag always set to support all changes we want. let's try
to be clean by making all changes
Rolf:
2% is important. Open multiple connection and fallback.
Phil:
Hum now, two choices
Alan:
If don't change the version number, would need to figure out to make
it happen otherwise because need larger options for additional
functionality and that's not simple, or need to discuss if we still
want additional functionality which I think we are
Hum:
- stick to decision to change version number: quite a lot hums
- change decision and not bump version number: few hums
Good consensus for first choice.
Rolf (Jabber):
number of samples in measurements?
Christoph: was large
--------------------------------------------------------------------------
2: RFC6824bis updates - Alan Ford
Olivier:
G bit leaves option of using it at client side. Wouldn't it be better
if the server makes the decision. Get rid of G bit if you just look at
the length
Alan:
not key sends initially. simplified example if G is supported but
otherwise server uses to support
Olivier:
TLS uses key from app. same key on client and server, if not how do
you derived them
Alan:
each end derived both
Oliver:
two different key. in TLS you can very long connections and you can
change key. if app changes key, you change as well?
Alan:
it would change because you ask key exporter every time.
Olivier:
when you receive mp-join you pass to app, application has to
understand mptcp which more complicated than only socket option
Christoph:
Yes, we have to dive a bit deeper into how exactly key-renegotiation
will affect MPTCP.
Olivier:
look at ssh as well because need solution for both
Alan:
both out of scope for the bis. but interesting idea to push key down
Olivier:
important for implementability
Subodh Iyengar:
webrtc does similar things; look at it
Costin: ????
Christoph:
it's good to mandate TLS
Alan:
if you want to use appl security, you have to use TLS
Costin:
the problem with this solution is that is only supports TLS over MPTCP
for load balancing. You wouldn't be able to load balance regular HTTP
traffic, for instance.
Alan:
Correct, but leaving flexibility for any application that is
MPTCP-aware.
Olivier:
It's a good feature and support it. benefits load balancing
Phil:
Good discussion and think about what should be added. Are people in
position to hum or need more time to read.
Juliusz:
is that a must implementation?
Alan:
it's optional; you list what you support in your handshake; you would
not need to implement it
Costin:
i like the mechanism but don't know which problem it's solves; just
load balancing with TLS. Given a stronger key because not send in
clear. Maybe a bit better protection but does not solve real problem
Alan:
problem is decoupling the token from key
Costin:
left the key in limbo. why not given you token and given you key as
well.
Alan:
it says i give you the token and you can get key as well. we don't
have option space to signal both at once; I'd love to do that otherwise
Philipp Richter from TUB:
signal which kind of key material is used
Alan:
make the assumption that the app is mptcp aware and the app knows
which key to use
Wouter Cloetens:
Means when accepting the connection the server has to provide it
Alan:
can provide it later, only need token. need to wait for new subflow
until key is available
Wouter:
if app needs to be aware what you do with load balancers or proxies?
Don't know which protocol is in there. mptcp is fully in kernel but
with this you need transition to user space
Alan:
yes, it's a noted restriction for these scenarios. make it simple by
not describing what the app should do. useful for TLS scenarios wheres
it's easy because there could be new app in future
Wouter:
How do you consider app interface?
Alan:
need to look at, e.g. which direction would the key be pushed or would
the application be queried?
Wouter:
kernel-only possible?
Alan:
can't see why not, but document does not constrain it, so it could be
used like this
Christoph:
different methods how to react to this... ???
Costin:
Two parts for load balancing: inappropriate for https or data packets
where load balancing can be stateless. for token load balancer must
remember where to first send the token.
Olivier:
we will not solve loadbalancing problem now, but maybe document all
issues from existing stacks for next meeting.
Costin:
Terminate connection which is easy
Phil:
Olivier, you have contacts to get this info
Olivier:
can start doc and need input
Alan:
isn't this what christoph's doc was?
Oliver:
would be good to summarize all and then figure out how to solve the
problem
Christoph:
update existing doc
Vladimir Olteanu:
load balancer can know token before?
Alan:
can't choose token
Vladimir:
load balancer can generate token and send it to server
Alan:
It's overhead
Costin:
overhead is not big but problem is when server has a collision; have
evaluated it and it's a fair point
Phil:
probably not ready for hum because had another discussion but asking
anyway
Hum:
- yes: this should be added to bis: very few hums
- no: more hums
- more time to think about it: quite a few hums, possibly more
Need more discussion
Phil:
discussion was useful and raised new ideas and proposal to write doc is
good and it's great that we have more work now
--------------------------------------------------------------------------
3: Multipath TCP Address Advertisement - Fabien Duchene
Rolf:
Is it likely that only part is load balanced in real life?
Fabien:
yes, private addresses
Julius:
in ipv6 there is a number of addresses per client
Rolf:
question was if some are load balanced and some not
Julius:
yes
Alan:
Echo bit, like that; no-join bit, like it; and backup bit for ADD_ADDR,
like it. All three are good and why not add all of them. but community?
Fabien:
could be solved at routing level and you can choose to not advertise
but maximize
Alan:
don't see benefit with community. If you have three addresses you could
just advertise one
Fabien:
We always advertise all right now
Alan:
depends on your policy
Philipp:
I see one relevant usecase in making the configuration of dual-stack
hosts much easier. You don't want to use MPTCP over equivalent v4 and
v6.
Alan:
Not convinced. priority I'm also unconvinced.
Fabien:
implemented priority scheduler but most of time does not matter what
server wants but client. server needs to know what client/smart phone
wants to make smart decisions. just first fill congestion window of
priority subflow and then others. Simpler scheduler implemented that
only send on other interface when first priority is not available
Alan:
still slightly unconvinced but clearer
Rolf:
like priority; could be used for handover. echo option only wants to
know that far end
Fabien:
it's in the draft, if you don't get echo you just use join. so you can
decide to implement it. because otherwise you'll keep retrying when
firewall blocks
Phil (from mic line):
other use case is overflow, do you need an all or nothing flag.
Fabien:
no because can have multiple interfaces and you can start with the best
choice
Phil:
do use cases need that flexibility?
Fabien:
don't know if we need 3 instead of 1 bit but more flexible for future
and 3 bits fit in mp-prior that is only used for the backup
Rolf:
how do you define full for the back-up decision?
Fabien:
look at the window and when the window is full you switch over.
but we can further discuss scheduler. current example was simple to
test it. but you can test others
Rolf:
but window is always full but growing
Fabien:
mean when no data can be send on this interface
Christoph:
only works if server is known. Can we do that for the general case and
define what each subflow means?
Fabien:
left backup bt alone. just higher priority is better. push as much
traffic as possible on highest and when highest becomes temporal
unavailable you take the next one. the higher the more likely you'll
use it
Christoph:
priority could mean even more, e.g. map to wireless or cellular and
associate to interface that is used
Fabien:
yes could put more meaning in
Rolf:
that's implicit because if higher priority is on bad link it will move
over more quickly
wouter:
DSL might have lower capacity and LTE might have better capacity and
then you'll choose the more expensive link
Rolf:
LTE also has much higher delay and needs more time to grow your window
Phil:
draft has 4 proposals that are independent. start discussion on list of
each separately. quite a bit discussion about priority here but less
about the first two. Only heard a bit of support but no discussion.
Author(s), please send separate emails to the list!
Phil:
next meeting Wednesday at tiergarten with 4 talks. if someone else
wants a slot they are welcome. also talk about rechartering.
------------------------------------------------------------------------------------------------------------------------
Meeting : IETF96, Wednesday July 20, 2016, 14:00-15:30
Location : Tiergarten
Chairs : Philip Eardley
Yoshifumi Nishida
AD : Mirja Kühlewind
URL : http://tools.ietf.org/wg/mptcp/
Note Taker: Olivier Bonaventure, Fabien Duchene
------------------------------------------------------------------------------------------------------------------------
1: Introduction - Phil Eardley
- draft-ietf-mptcp-experience submitted to AD
- draft-ietf-mptcp-rfc6824bis works continue, last call as soon as possible
- MPTCP enabled middleboxes : discussion later in charter
- charter : will need to discuss with AD about paragraph on implementation in
the charter
------------------------------------------------------------------------------------------------------------------------
2: Network Assisted MPTCP - Bart Peirens
Phil:
What does the last bullet on the slide with the plain mode option means?
Bart:
In the SYN segment, you can put either the source or the destination as
plain mode option. Explanation of use cases based on slide 9. Embed
destination address to steer traffic towards HAG or embed original
source address to send the address of the source so that that HAG is
aware of it.
Rao:
Changes since last IETF. Why bounding a TCP connection to a single UDP
flow. Would like to be able to carry traffic for the same system, not
on a port basis.
Med:
Hybrid access there is no limitation of the port usage. Don't want
additional demultiplexing. Your use case is different since you want to
minimize the number of TCP connections.
Med:
Slide on comment#2 might want to inject plain mode in each packet for
your use case, but not for plain mode option.
Rao:
wording needs to be changed.
Med:
use case is different, would require to send the plain mode option in
each packet, but this is outside the scope of our drafts. We could
discuss this in another draft.
Bart:
We will specify the plain mode option and it could be reused in other
use cases, the same option can be used for other solutions
Margaret Cullen:
Slide on comment 1: You want GRE and the two modes you run MPTCP. Load
share UDP traffic, TCP connection end-to-end. I'm working on a
considerations draft and would like input. There is another mobile
solutions that could be compared. This gives new criteria to add to the
comparison document.
Bart:
We can work on that
Alan Ford:
Is there anything MPTCP specific in this proposal ?
Margaret:
the part specific is that you use subflows
Alan Ford:
transparent mode and plain mode option. plain mode indicates that the
traffic is towards a target.
Wim henderickx:
We want to use this option to tell that if a flow originates from a
client, we should not do anything from the flow. Option serves as a
signal to indicate that we are in proxy mode.
Bart:
indicator and based on the length it can indicate the transparent or
plain mode with the length of the option
Wim:
Indicates whether a flow originates from the host or the HCPE. Merge in
one draft where the plain mode option supports different modes of
deployment. We are going to merge the draft.
Phil:
Could have a simpler explanation of the different pieces and explain
how they fit in MPTCP WG.
Wim:
Could explain how to use the options in different modes.
Alan:
I see what we are trying to get. I would caution against wrapping a lot
of stuff that is generic into an MPTCP protocol specific stuff.
Margaret:
Trying to guess what the merged draft looks like. Within each
deployment mode, will the impact on MTU be constant.
Bart:
Optionally up to two options in the SYN. No MTU impact.
Margaret:
For UDP traffic, what happens.
Bart:
Length of options depends on use case.
Margaret:
If you don't put data in SYN, there is no MTU impact. UDP is
encapsulated. How will end nodes understand MTU
Rolf:
Concentrator is a heavy duty middlebox. Not a rela option because it is
placed in the data. What happens if this information leaks if it does
not work.
Lars:
Slide 9 : QUIC will deploy before a home gateway that does this. Is it
a little too late ?
Med:
About UDP, this is detailed in the plain mode draft. There is no
tunneling, but swapping. Plain is only in the SYN. We are in managed
networks and can increase MTU. We have specified the fragmentation for
the different cases.
------------------------------------------------------------------------------------------------------------------------
3: Socket API for MPTCP - Olivier Bonaventure
Rao:
IETF don't do API...
Olivier:
There is SCTP, QUIC,... Idea to have a common API
Alan:
In first iteration of WG, cannot specify API.
If RFC cannot provide all specs needed, maybe not sufficient, should be
an update of RFC...
Tommy Pauly:
Lessons here should be recommendations, should have guidances.
For path management, having user space managing all PM is very tricky,
propose a common management
Lawrence David:
Protocol is multipath, with same problems as others (like QUIC).
Need to make the API more generic for all, with no POSIX binding.
Olivier:
What's important is to get feedback from application developers.
Based on this, can iterate (requirements,...) that can be extended to
other protocols after. Where it goes at the end, TBD.
Alan:
Link with RFC
Olivier:
With current RFC, found some corner cases.
Alan:
should be an update to rfc6897.
Wouter:
Socket API of SCTP is similar. Why is it different from SCTP?
Olivier:
Implementation = Baseline for discussion
Wouter:
Did you looked to SCTP API?
Olivier:
Not tried because SCTP has also some issues, prefer to start from
scratch. If looks like SCTP at the end or not, would be a lesson.
------------------------------------------------------------------------------------------------------------------------
4: NFSv4.1 - Chuck Lever
Med:
Need other transports than TCP?
Chuck:
might need
Rao: ...
Chuck: ...
Rao:
looking at database applications needing this.
Olivier:
got feedback from user of dfs, using lo interface, with MPTCP to
advertise address. With Socket API, can do better.
Chuck:
Need to populate info somehow.
Rao: ...
------------------------------------------------------------------------------------------------------------------------
5: LISA - Runa Barik
Michael:
Reduces the burst, ok for shared bottleneck, but not always for not
shared, and results seems not so different.
------------------------------------------------------------------------------------------------------------------------
6: Rechartering discussion
Lars:
NFS discussion might be interesting for MPTCP application for special
needs. But not because it's multipath it's good to deploy on operators.
Med:
Disagree on second point. Interesting the work of proxy to provide
guidelines for those people. Can continue experimental since exp. RFC.
Can be used for various usecases. Interesting for the management stuff
to recharter.
Bart:
Idea to compare drafts
Olivier:
Disagree, idea to have end-to-end MPTCP, but difficult because of
Middleboxes. Having multiple address on a same interface is difficult
today, ability to react quickly to network is a advantage of MPTCP, and
should be standardized in IETF.
Wim:
In favor of proxy, to make sure CP and concentrators have
interoperabilities. But seems to have a lot of interest with lot of
authors.
Lars:
Why not having a BOF, because not a transport area.
Margaret:
Agree with Lars, MPTCP can be interesting for this, but proxy and so on
is here a strange location to standardize here.
Rolf: ...
Margaret:
Discussed at bar BOF, interesting to get everything together somewhere.
Phil:
idea to group multiple paths solutions somewhere
Margaret:
MPTCP, net approaches, lot of tradeoffs, would standardize more than
one solution, where all is informed.
Costin:
If need to change MPTCP, do it here.
Mirja:
idea to document how to use multipath solution, can document here, but
not here for operational guidance.
Olivier:
seems to have support for the API, should it be chartered?
Phil:
no time now, but probably on Mailing LIst.