Subject: [multipathtcp] Draft MPTCP WG meeting minutes

From: <[email-masked]>
Date: Sat, 7 Apr 2012 11:47:38 +0100

here are the draft mptcp minutes from the paris meeting. please send any corrections.

there's at least one mistake, as there's one name missing (I should know who you are, sorry) - someone who made a couple of comments, one a question about WAN optimisation

ps the audio recording isnt yet available - the computer is mid atlantic!

many thanks to Iljitsch for his detailed notes

Thanks
Phil
====

MPTCP session

Chairs: Yoshifumi Nishida (not present) and Philip Eardley

Iljitsch van Beijnum taking notes, Tim Shepard monitoring jabber.

Phil:
Include -mptcp- in your drafts.
State your name at the mics.
Note well.
- Doing well on initial milestones: 3 RFCs finished. (See chair slides.)
- Main thing today: as we finished our charter, recharter.

== API & Protocol update ==
Alan Ford with update on what happened to API and proto documents.

API:
- WGLC closed with good comments from John Leslie and Joe Touch.
New security considerations. (See slides.)

Proto:
WGLC finished
Some changes: fast close (like TCP RST) and various clarifications, see slides.
Next steps: chairs, please clarify.

Phil:
WG chairs need to shepherd. A few minor comments already sent about API. Proto is more substantial doc and yet to be done.

== Rechartering ==

Phil:

See Phil's slides.
Still work to be done, so recharter rather than close down.
After discussion on the list we want to hear further comments here.
Yoshifumi and I will work on a proposal for the IESG.
First topic: move from experimental to standards track, requires implementations.
Second topic: add functionality as experimental, only suggestion now proxy functionality, nothing else. Need comments, do we need more?
Third topic: some informational documents such as use cases and applicability. In particular the mobility case, offloading traffic from 3G to Wi-Fi and optimization for when only one path is available (at a time). People have been looking at MPTCP in datacenters, for IPv4-IPv6 transition.
Again, Phil's slides.
We have quite a bit of time for this discussion, so please speak up.

Georg Hampel:
Strong use case for traffic offload, want to use mobility.
MPTCP supports mobility but not optimized for it.
Single path operation.
Simpler implementations.
If we want proxy, can be simple with single path restriction.

Alan Ford:
Do support that in general.
Just need to be careful implementing optimization so we don't lose compatibility with full implementation.

Łukasz Budzisz:
Active multiple interfaces can drain battery

Georg:
Yes, interoperability is important.

Lars Eggert:
Why is MPTCP complex?
Not convinced we need to do anything on a simpler implementation.

Costin:
Agree with Lars on that one.
Can have option cover one segment or multiple, could do one option cover multiple segments in single case, just an issue with the checksum.
Don't think wire format needs to change.

Georg:
There are issues along these lines.
Don't know how it behaves with large delay variations.
SACK
Don't want to solve these right now, but potentially revisit design.
Overhead for mobility (important for mobile operators), often don't get a second path before the session is over.

Phil:
Are you envisioning protocol changes?

Georg:
Minor changes, but I don't want to solve them right now, we need more discussion in the wg.

Phil:
What I don't want to happen is MPTCP-full vs MPTCP-light.

Georg:
Doesn't always make sense to forbid inferring subflow ACK from data ACK.
Maybe some minor changes.

Lars:
I remain unconvinced, TCP is a general purpose protocol, not optimized for anything, MPTCP should be the same, I don't see the complexity.

Costin Raiciu:
Wireless is evolving very rapidly. Not convinced that in 5 years energy problem will be the same. Optimizing for 5 or 10 years in the future seems premature.

(??)
No issue with optimizing. (I'm an ISP.) Next question is what happens to non-MP people.
It's good if we could say we're working on this overhead.

Costin:
Now worst case 2% overhead, 20 bytes in every packet.

Scot Brim:
Let's just delete the word optimize.
Charter should say consider these cases, it should work well.

Alan Ford:
Agree.
We've seen this is of interest to people, should look at what we can do here, maybe or maybe not protocol changes, document and derive solutions as appropriate.

Phil:
We'll recraft the words as per Scot.
Any other points about the charter?

Rolf Winter:
I've implemented our single path i-d, doesn't require new code, significant enough use case for the charter.

Lars:
(reference to slides)
Yes, definitely standards track.
Want people actually doing use cases, not just theory.
Implementations yes
Experiments could be independent stream.

Teco Boot:
Another use case: combining for instance proxy function with VPN tunnel.

Jim Martin:
Could consider broadband access perspective. For instance, IPTV. Those applications currently use concurrent TCP flows.

Iljitsch:
I think you're barking up the wrong tree here, you need SCTP.

Jim:
Maybe, but I think there could be synergies here.

Łukasz:
- Multiple proxies on the path, signalling between them. Offload traffic on uplink

Randall Stewart:
SCTP does both multipath and multistream.

Georg:
We're proposing a concept on an anchor signaling between network nodes that support MPTCP in some way.

Lars:
My definition of a proxy: entity that terminates regular TCP and MPTCP and relays between the two.

Scott:
Make sure description is generic

Georg:
Then we have a problem!
Both ends canspeak MPTCP but anchor supports them

Phil:
See about this on the list, don't want to obfuscate things though.

Alan Ford:
Know vaguely where we want to go but need to discover this along the way.

Randall Stewart:
Anytime you terminate and reconnect a TCP session there are at least 3 patents, main one from MIT. So beware.

Costin:
I agree that we shouldn't go with a proxy that must terminate, because if the server supports it the proxy can get out of the way, the charter shouldn't disallow this.

Consensus calls:
See Phil's proposal slide.

First hum: do we want a standards track document?
Consensus (all) in favour.

Scot:
I would like to add alternative congestion control. Mat Mathis' new thing impacts MPTCP.

Rolf:
For DHCP options we need to state that we want it to get DHC to do it.

Phil:
Pull out stuff that needs to be discussed on the list separately and then come up with a charter proposal.

== Implementations ==

Phil:
Does anyone have news about implementations? Solaris, FreeBSD?

Costin:
Intel is changing Android.

Lars:
Grenville Armitage has gotten a (Cisco?) grant to implement this in (Free)BSD.

Christoph Paasch on Linux kernel implementation

See slides. Skype recorded demo

Georg:
Is this all implementation (and not design)?

Christoph:
Yes.

Costin Raiciu on MPTCP receive buffer management

See slides.

Mirja:
So this is ignoring MPTCP's congestion control?

Costin:
Yes, but only when receive buffer limited so cc not working properly

Georg:
Set receive buffers for different subflows?

Costin:
No, single one per connection, just who gets to use it.

Christoph:
This is steady state, right? How fast does MPTCP adjust?

Costin:
So what if your receive window varies wildly?

Iljitsch:
Are these measurements or simulations?

Costin:
Measurements except for one case where it's stated that that is a simulation.

Iljitsch:
I disagree with your assumptions.
Maximum buffer size is determined by transmissions to far away places, so for instance 160 ms to get to California, this would make the comparison 170 vs 360 ms rather than 10 and 200. Even in cases where the maximum buffer isn't needed this still means that a bigger maximum is available.
With MPTCP you're no longer talking about simple RTTs as data ACKs can come in over the other path. I don't think it makes a difference for your results but important to keep in mind when modeling MPTCP behavior.

Costin:
This case is easier

Georg Hampel on MPTCP lower layer implementation and measurements

See slides.

Bump in the stack. Trials with corporate wifi and 3G

Christoph:
Don't you have trouble with payload modifying or coalescing middleboxes?

Georg:
If you do make before break you don't have such problems.

Olivier Bonaventure through jabber:
Is this available?

Georg:
Not yet.

Georg on MPTCP proxies and anchors

See slides.

Costin:
Considering my presentation, what needs to be done?

(??):
Have you compared the WAN optimisation solutions that exist today?

Phil:
Sorry we've run out of time

Łukasz Budzisz on transparent performance enhancing proxy:

See slides

Teco Boot:
How is a single TCP flow merged, I think think this packet won't get there.

Łukasz:
You can control how the packets are routed in the backbone network, this is single homed MPTCP.

Lars:
This left me very confused, we shouldn't do this in the new charter.

Rolf:
I don't understand the motivation. Why not deploy on the endhosts and leave the network alone?
Use port numbers and ECMP for multiple paths.

Costin:
Load adaptive routing is the holy grail. I don't think we can do this in the network.

Phil:
We've run out of time, thanks everyone for your great work and interest.
Blue sheets...

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 11 Apr 2012 02:53:07 -0700

Sorry about the delay.  I did make the comments on WAN optimization.  Since this topic was about MPTCP proxies, I was asking whether a comparison has been made with existing WAN optimization solutions prevailing in the industry. Once you terminate TCP, it looks exactly like a PEP (eg, WAN optimization proxy)

-Anantha

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, April 07, 2012 3:48 AM
To: [email-masked]; [email-masked]
Subject: [multipathtcp] Draft MPTCP WG meeting minutes

Thanks
Phil
====

MPTCP session

Phil:

API:

Proto:
WGLC finished

Phil: 

== Rechartering ==

Phil:

See Phil's slides.

Georg Hampel:

Alan Ford:

Łukasz Budzisz:

Georg:

Lars Eggert:
Why is MPTCP complex?

Costin:

Georg:

Phil:

Georg:

Phil:

Georg:

Lars:

Costin Raiciu:

(??)

Costin:

Scot Brim:

Alan Ford:
Agree.

Phil:

Rolf Winter:

Lars:
(reference to slides)

Teco Boot:

Jim Martin:

Iljitsch:

Jim:

Łukasz:

Randall Stewart:

Georg:

Lars:

Scott:

Georg:
Then we have a problem!

Phil:

Alan Ford:

Randall Stewart:

Costin:

Consensus calls:

Scot:

Rolf:

Phil:

== Implementations ==

Phil:

Costin:

Lars:

Georg:

Christoph: 
Yes.

See slides.

Mirja:

Costin:

Georg:

Costin:

Christoph:

Costin:

Iljitsch:

Costin:

Iljitsch:

Costin:
This case is easier

See slides.

Christoph:

Georg:

Georg:
Not yet.

See slides.

Costin:

(??):

Phil:

See slides

Teco Boot:

Łukasz:

Lars:

Rolf:

Costin:

Phil: