Subject: [multipathtcp] MPTCP WG meeting - draft minutes

From: <[email-masked]>
Date: Fri, 8 Apr 2011 20:11:49 +0100

Here's a draft of the MPTCP WG minutes for our Prague meeting. Please send corrections as soon as possible

Thanks very much to Olivier for the detailed notes!

Phil & Yoshifumi.

---

* Chairs.

Review milestones

wg doing pretty well

two rfcs published 6181 and 6182

protocol : need reviewers to review the document

implementation available check inl.info.ucl.ac.be/mptcp

* Alan Ford  : Protocol

update of the changes to the protocol

changes to wire format, but no fundamental change, revisions based on
implementation experience

effort to make document more readable for reviewers and implementers

since 02

single option type, which changed all option formats
data level sequence numbers and acks in single option
data fin option decoupled from subflow Fin
security solution discussed in interim meeting
checksum changes

single option

format on slides

data sequence signal

big option, merge of data sequence data ack and data fin all in one

format on slides

F flag similar to FIN flag on TCP

reason for DataFIN : corner case during connection close was possible
with the previous design

connection level fin must be acked before subflow level fin, but
optimisation remains possible

security solution

logic similar to 02
based feedback reduced to 3 packets exchange with no use of payload
sha-1 is specified but there are other bits for crypto agility in the future

see slide for security solution example

MAC truncated on server-client direction but a false server a less
significant security problem than a false client that tries to create a
lot of subflow attempts

other changes

checksum optional
clarified rules on duplicate acks for signalling
appendix on tcp control block data structures

heuristics

not a lot of text on this now
without large scale deployment, difficult to make clear recommendations

where next

document fairly stable

In need of reviewers. We hope to have detailed reviews at this stage

Michael Welzl : I volunteer
[later: instead Michael's colleague, Stein Gjessing, will review]

questions :

nobody in the room

open issues :

lars eggert : don't have feedback, but is there another implementation
besides ucl's implementation? If you are doing an implementation, please
send feedback

* Mark Handley : MPTCP Proxies

Classifies as open issue

doing some work on mptcp as a mobility solution

during the bof, we showed a scenario with a client using 3G and Wifi to
a server to supplement or replace the 3G for better
performance/robustness/battery power

opportunistically use Wifi base stations seemed worth exploring and we
did some simulations

still preliminary, short paper see url on slide

you can get better throughput, better robustness and save battery

could be a key part of a mobility solution

minor problem : cannot depend on servers for mptcp in the future

who will use mptcp in near future ?

Solution

mptcp proxy

idea mobile client and proxy provided by e.g. 3G provider

connect to proxy and proxy connects to server

when mobile moves, uses proxy
server knows nothing about mptcp

not ideal to realy everything through the proxy all the time

can we avoid  proxy all time on path

assume server mp-capable, proxy can learn

Q: Lars Eggert why wouldn't the mobile open connection to both proxy and
server

MH : need to kill state 

Scott Brim : 
cool thing is mobile IP homeagent, winning combination
you want an initial rendez-vous point anyway for privacy
mh : not exactly the same role, it is similar, but proxy would need to
behave differently with normal server and mptcp server

Randall Stewart : there is IPR on this at a former employer, did similar
thing for SCTP

Scott Brim : had no idea this patent covered this, we'll ask later
extremely excited to see this model, you get 3 for 1, grab people who
like mobile ip, don't need route optimisation, get privacy and get
optimisation with mptcp

mh : one thing we need to do is to tell the proxy where to connect to
and you need to do this in the syn

would like to put an address in the syn, but we don't have space for this
principles are easy, but in practice not easy to find the bytes
should we try this on the first path in the protocol spec ?

Adam ? , cisco: you seem to indicate mobility use case, but mptcp could
be a general proxy, in such case all connections will go through the
proxy. If the proxy knows that the server is mptcp capable and it does
not need the flow anymore

mh : it might want to relay data at the beginning of the subflow to
reduce latency

you could do after the syn, but looks difficult

Adam : take it offline

Tim Shepard : mptcp proxy is used for everything and you have a long
term relationship and have state in both ends, why not tunnel the
information to the proxy

mh : gre would not go to nat

Tim : TCP goes through NAT, could tunnel over TCP ?

MH : maybe over UDP ?

Scott : mobile ip

Tim : if you have wifi access point that is causing problem, does mip work

mh : there is nat on all these links

Tim : tunnel

mh : udp makes sense, but don't like udp

Lars Eggert : assuming you could reuse some bits of the source ports,
fragment id,s ..

Alan Ford : data in the syn, wait for discussion in tcpm and work on
spdy in google

Tim Shepard : you know you are talking to a special box and you could
use special acks to discuss with this box, think more evil

MH : Do we want this in the normal spec ?

Scott Brim  : keep separate
Lars Eggert : agree with Scott, don't hold the draft in the wg longer

Tim Shepard : should be ? in the spec to encourage people, only used for
mobile clients than want to use a proxy

Alan Ford : don't know if this will be useful and wireless is uncontrolled

Phil Eardley (chair) : keep it separate but there is interest in the room

* Michael Scharf, API

authors have corrected some minor issues

minor updates

some functions return now both ip addresses and port numbers instead of
only ip addresses

additional entries in the candidate list for an extended api

additional text on approaches like happy eyeballs, mentioned as a
possibility, not mandated, more a heuristic for protocol than an API issue

discussion of comments received from Javier Ubillos, Michael Tuexen

document pretty stable, please provide further feedback

no questions

Phil (chair) : there will be a wg last call after the next revision

* Mark Handley, congestion control

3 reviews received for previous cc draft, mainly wording and interpretation

bytes/packets stacks. draft has been updated to cover both and avoid
rounding errors. packet based version assumes that mss is same on all
paths and draft describes how to handle the case if mss are different.

NSDI2011 paper describes the algo in details and its performance

some results from datacenter simulations see slides
mptcp is good at pushing traffic out of hotspot paths, better than
application level distribution over different tcp connections

measurements on amazon EC2 datacenter where there are multiple paths
running over 24 h

measurements show that when vms are on same machine or host, mptcp same
as tcp

over ecmp paths, mptpcp with 2 or 4 flows gets much better performance,
3x more

coupled congestion control find the available capacity in the datacenter

* Sébastien Barré : demonstration of Linux MPTCP implementation

setup : two servers in a LAN with a programmable router that inserts
delay or losses between the two servers, live demo, servers are running
latest mptcp linux kernel implementation

look at bandwidth when the delay or bandwidth or losses change in realtime

two separate 100 Mbps links

iperf running between the two servers, gets almost 200 Mbps at the
application level

add losses on one path 1%

throughput drops on the affected link but not the other and application
continues to work with reduced bandwidth
coupled congestion control is going away from congested path

same loss for both pass, two subflows get roughly same bandwidth

add delay on one link, one subflow is affected for some time and then
recovers

failure : stop one link, the other is still working and iperf only sees
reduced bandwidth

link comes back, need some time to find the link up due to exponential
backoff

Question :

Tecco Boot why did loss on the blue link caused a reduction in bandwidth
on the green one

Sebastien : related to retransmission that are done on the other flow,
retransmission timeout may cause delays and fill receive buffer

MH : think you are asking a different questions

congstion control is linked between the two subflows and this explains
why we both are equal loss, they get the same performance

loss is modelling congestion

Tim : all point is to move traffic away from congested path

Tecco Boot : I would like to have a solution to react differently to
losses and congestion. Looking for solutions taking traffic from satcom
to 3G to wifi, mptcp could do some job there, you should use reliable link

MH : How do you detect whether the loss is due to congestion or due to
something else ? Without this info, we need to assume that they are
caused by congestion and not by link errors

Georg Hampel, Alcatel :

demo is very nice. What happens if there is a large delay, up to 3 or 5
seconds

Yoshifumi : how do you create loss and delay

Sebastien : tc, artificial

Sebastien set delay to 3 second

strange result

Michael Scharf : like this demo, but independent of mptcp design, did
the same demo with another protocol, could do it with a different protocol

- distribution of live CDs with the implementation

* Sebastien : presentation of guidelines for implementers

implementation status

objective of the document is to explain the choices made in the
implementation and why and also the things that were abandoned

hope to include feedback on other implementations later

besides the real demo, MPTCP implementation is running as well on Nokia
N900 and Nexus who are running Linux

explanation of architecture

explanation of path management

explanation of send queue management
need same mss for all subflows

explanation of receive queue management

* Rolf Winter, autoconfiguring single-homed end-systems to make use of
network multihoming

how to allow single homed host use multipath ?

scenario : dhcp server, gateway with multiple ISPs and DHCP server

mptcp works with multiple addresses, option 1 give multiple ip addresses
to host, but gateway needs to do source routing

solution:

not same thing as multipath proxy

create virtual interface that sends a dhcp request, add to dhcp request
an option that indicates from which range you want the address

mainly configuration tweaking, 20 lines of scripting and running in a
small testbed

other ways to achieve same result are discussed in the slides

is it useful ?

Questions :

? for experiments this is useful if you have a lot of time, but for
normal usage, this is interesting for IPv6, multihoming on a single
homed host with multiple addresses. how does mptcp work in this environment

Rolf: other scenarios are discussed in this document

some discussion on ipv4 versus ipv6

Phil Eardley (chair) : show of hands : a dozen hands

* Rechartering ideas

doing well on our charter

from slide :

How much energy is there ?
Advice on implementation and heuristics ?
Support for singl-homed end systems
applicability and experience
alternative security
alternative congestion control
advanced api
proxy for mobility
other topics

Mark Handley :

intend to spend some time on heuristics section, there is a lot we don't
know, need good ways

Scott Brim : I consider the following topics

applicability and experience
alternative congestion control
advanced api
proxy for mobility

I hope somebody would work on these, I want to work on proxy for mobility

Tim Shepard : there should be a venue to do interop testing if there is
a second implementation. nice to continue with a venue

Phil : default option is to finish charter before the next ietf and
pause while waiting for experiements and usage

Alan Ford : We'll get more feedback as implementations progress

lars Eggert : nobody else is doing an implementation or knows another
implementation ?

bof was extremely popular and few

Sowmini Varadhan from oracle : working on multipath for solaris

Sebastien : a dozen people are helping in debuging and four are
providing patches, others are downloading

merge in main linux tree is too early, need to stabilise and follow the
draft

Lars : be great if more people could contribute

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 14 Apr 2011 21:20:56 -0700

Hello,

After minor revision and reformatting,  I uploaded a draft minute for
prague meeting
on the following URL.

http://www.ietf.org/proceedings/80/minutes/mptcp.txt

We appreciate Olivier for note taking and Luigi for jabber support.
We also would like to thank everyone at the meeting for active discussions.

Thank you so much
--
Yoshifumi & Phil

2011/4/8  <[email-masked]>:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>