Subject: [multipathtcp] Draft agenda for Stockholm BoF

From: Mark Handley <[email-masked]>
Date: Wed, 1 Jul 2009 23:24:54 +0100

Folks,

We're rapidly approaching the Stockholm IETF, so here's our first
attempt at an agenda for the BoF.  Please let us know if there's
something we have missed.  We'll circulate a list of drafts and
reading material after the I-D submission deadline.

Cheers,
Mark and Scott

Draft Agenda, Multipath TCP BOF

Chairs: Mark Handley, Scott Brim

Introduction: Scope, Intention, Process
Scott Brim
5 minutes

Multipath TCP:  Goals and Background
Mark Handley
25 minutes

Multipath TCP Protocol Design
Alan Ford
25 minutes

Linked Congestion Control
Costin Raiciu
20 minutes

Rethinking the Transport Layer and Impact on Multipath TCP
Janardhan Iyengar and Bryan Ford
10 minutes

Technology Discussion
Led by Mark Handley
15 minutes

Charter Discussion
Led by Scott Brim
20 minutes

---

From: Scott Brim <[email-masked]>
Date: Fri, 03 Jul 2009 14:23:56 -0400

> Introduction: Scope, Intention, Process

Since we have very little free time in the BOF agenda, I wanted to do
scope and logistics bashing on the mailing list if possible.

Take a look at the BOF description at
<http://trac.tools.ietf.org/area/tsv/trac/wiki/MpTcpBofDescription>.
The goal of this BOF is to evaluate support for a working group to
develop multipath TCP.  The working group would focus on multipath TCP
protocol development, including API extensions.

We expect that research on multipath transport and transport in general
will continue in parallel, and may affect this WG, but they will not be
done in this WG.  A working group needs a clear initial focus on a few
tasks.  Later on, after actually accomplishing something, it can open up
and do a little more broad multitasking.  In particular this leaves out
SCTP, for which I apologize, but I hope you agree with the need for focus.

Also, during the presentations we will try to stick to clarifying
questions only.  After all the presentations are done, we can have a
general discussion on the issues led by Mark.

If you have any comments with any of this, please let the list know.

Thanks ... Scott

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 06 Jul 2009 14:06:42 +0200

Hi,

I would like to point out that from my perspective one of the biggest
goal of the BOF is to discuss the really high level questions that you
can't trust a future WG to sort out. Thus details in the protocol
proposals are maybe not relevant unless they really results in such
diverse protocol results or have significant difference in how they
impact the network.

So, as Scott writes considering the description and commenting already
know on what you think are question is really helpful.

I do hope that we will see a charter proposal more than one week prior
to the IETF meeting.

Cheers

Magnus

Scott Brim skrev:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
> 

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Randall Stewart <[email-masked]>
Date: Sat, 18 Jul 2009 09:35:47 -0400

Magnus/Scott:

I have long wanted to write a post to this mailing list but
have never had the time to read through all the threads and
drafts here... just too many other things to do... sorry... I guess
I never will so before this becomes a wg I think I better say
my 2 cents...

I must say some of the topics intrigue me, such as:
   "We don't need to detect shared bottlenecks"...

Shared bottlenecks is the only reason the FreeBSD version of SCTP does  
not
have CMT (Jana's work... i.e. multipath-sctp) turned on by default.
So yes these are interesting questions. Questions that I would like
to see the answers too. These questions do need a broader answer
then what would be done in this BOF/WG... but the deployable
work of this WG would definitely be dependent on the answers
to those questions IMO.

Now, as far as multi-path TCP goes, I really don't understand it.
To me the IETF is doing the same thing it did with NAT and IPV6.

Here about 10 years ago we standardize a new transport protocol (SCTP)
it has three principle features beyond what TCP offers:
  - multi-homing (and with Jana's work multi-path)
  - multi-streaming (to get rid of head of line blocking)
  - message boundary preservation.

And in fact we just finished another one to replace
UDP, DCCP adding congestion control to that protocol.

In both of these cases we did the architecturally "right" thing and  
just went
ahead and built a new protocol to do what we wanted to do.

So what happens a bit later... we decide that we need
to get the multi-path/homing feature and hack it into TCP.

So I pose the question why? The answer, proponents will say, is that
really SCTP and DCCP are not deployable due to NAT. After
all you have to get every vendor to change all the NAT and F/W  
implementations
to deal with SCTP and DCCP. This is just an impossible task and it rules
out any other transport ever being built....  (I disagree.. but  
Jonathan and
others have made this point).

Maybe we should expand the charter a bit and add multi-streaming to this
work as well? After all this is another issue with TCP as well.. and  
in fact
one more obvious to the user.... (take a look at Preethi's work on web
traffic and multi-streaming if you doubt me) and as long as were at it  
lets go ahead and
get some message boundaries applied .. we did a half job of that in  
RDDP with
their framing RFC's... lets make that more useable to the TCP
programmer.. That way, in the end, we will have cannibalized SCTP and  
morphed
TCP into something else...

It probably would have been easier just to re-use protocol ID 6 but hey
we can hack it together... it will be a mess... it won't be as efficient
as doing it right (see Jana's original work if you dis-believe me).. but
at least we kept those NAT's happy... ;-(

Just like V6 we will once again let the tail (NAT) wag the dog  
(Transport Protocols).
With V6 it was time pressures, now its just this "embedded" base of  
NAT's...

R

>> If you have any comments with any of this, please let the list know.

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 18 Jul 2009 16:28:51 +0200

> - message boundary preservation.

It also has:

- a dumb keepalive mechanism on the additional address pairs that  
generates unnecessary traffic
- a complex chunk structure that is much harder to implement with low  
overhead
- a checksum that is expensive to calculate in software
- no provisions for migration from TCP to SCTP

The multipath that is currently in SCTP assumes the use of different  
addresses on both sides to make the packets flow over different paths.  
While that is certainly a useful approach, it's not the only one.

As such, even in a world without NAT SCTP wouldn't be a very good way  
to deploy multipath transport across the internet. Which isn't  
surprising, because it wasn't designed for that.

---

From: Randall Stewart <[email-masked]>
Date: Sat, 18 Jul 2009 11:32:50 -0400

> generates unnecessary traffic

Which is completely configurable by the user if they want it or not..  
very similar
in some respects to TCP-KeepAlive. Only real difference is that SCTP  
is on
by default and TCP is off by default.

> - a complex chunk structure that is much harder to implement with  
> low overhead

I won't argue implementation issues... I have seen TCP stacks that are
rather obtuse as well ;-)

> - a checksum that is expensive to calculate in software

And there is now hardware that does it (just like TCP).. and by the
way this is also a feature since data corruption is often an issue and
TCP will often let bad data through that passes its weak checksum.

> - no provisions for migration from TCP to SCTP

Thats strange you say this, since with 1 minor change one can
move to SCTP from TCP i.e.

instead of

sd = socket(AF_INET, SOCK_STREAM, 0);

you do

sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP);

I don't know how much easier you can make it.. unless you want
it transparent .. and that was done too by Ryan Bickhart at the Univ  
of Delaware as
well..

Completely redesigning a protocol to do things it was not intended calls
for a new protocol, not hacking up an existing one..

As Joe used to say in the RDDP debates... protocol ID 6 is taken  
choose another one ;-)

R

> addresses on both sides to make the packets flow over different  
> paths. While that is certainly a useful approach, it's not the only  
> one.
>
> As such, even in a world without NAT SCTP wouldn't be a very good  
> way to deploy multipath transport across the internet. Which isn't

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 18 Jul 2009 17:50:13 +0200

On 18 jul 2009, at 17:32, Randall Stewart wrote:

[...]

I'd be happy to argue the individual points, but the conclusion is  
plain and simple: the tradeoffs that SCTP makes are different than the  
ones TCP makes, which renders it a non-starter for many purposes.

> move to SCTP from TCP i.e.

You're missing the point. Which is that if a client wants to talk to a  
server, the client has no way of knowing if the server uses TCP or  
SCTP. (Of course if the client did know it still wouldn't know if  
there was a middlebox that breaks SCTP in the middle.)

> for a new protocol, not hacking up an existing one..

In the case of the one-ended multipath TCP that seems a rather curious  
remark as it interoperates with unmodified TCP implementations at the  
other end, that hardly suggests a protocol number change is in order.

---

From: Michael Tüxen <[email-masked]>
Date: Sat, 18 Jul 2009 19:29:38 +0200

> - no provisions for migration from TCP to SCTP
Are you talking here about the API level or the network level?
Does multi-path TCP provide the same server as TCP: a byte stream
where each byte is delivered exactly once to the user at the receiving  
side
in the same sequence as sent by the user at the sending side?

---

From: Mark Handley <[email-masked]>
Date: Mon, 20 Jul 2009 10:28:22 +0100

On Sat, Jul 18, 2009 at 6:29 PM, Michael
Tüxen<[email-masked]> wrote:
> where each byte is delivered exactly once to the user at the receiving side

Yes.  The intent is for unmodified apps to just work better.

This does not preclude API extensions to allow new apps to have more
control, especially over latency, but it must be the case that no
existing TCP application needs to be changed.

 - Mark

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 20 Jul 2009 13:40:42 +0200

> existing TCP application needs to be changed.
Hi Mark,
thanks for the answer.
So you will have multiple "paths" below a single TCP socket, right?
The MTCP stack below distributes the data over multiple paths and
the receiver sides puts everything in the correct order and delivers
is to a single socket. Right?

Best regards
Michael

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Jul 2009 14:25:21 +0200

> is to a single socket. Right?

No, apparently you missed the part in the draft where it explains that  
the application is now required to handle the data in the order it is  
received from the network.

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 20 Jul 2009 14:56:40 +0200

On Jul 20, 2009, at 2:25 PM, Iljitsch van Beijnum wrote:

> No, apparently you missed the part in the draft where it explains  
> that the application is now required to handle the data in the order  
> it is received from the network.
>
Well, I still need to read it... So sorry for the dump question.
But this means that the application gets a service different from
the service TCP is providing and therefore needs to be modified.
This is contradicts with what Mark said. Or am I missing something?

Best regards
Michael

---

From: Costin Raiciu <[email-masked]>
Date: Mon, 20 Jul 2009 14:00:21 +0100

Hi,

I assume Iljitsch was joking; Mark gave the straight answer: the  
application still get in-order, byte-addressed, reliable delivery.
Costin

On 20 Jul 2009, at 13:56, Michael Tüxen wrote:

>> that the application is now required to handle the data in the  
>> order it is received from the network.
>>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Jul 2009 15:00:43 +0200

> This is contradicts with what Mark said. Or am I missing something?

Yes, the sarcasm.  :-)

As Mark wrote, the point is that for applications, it's still TCP as  
usual. In the one-ended approach this goes so far that even to the  
receiving TCP it's TCP as usual, except that packets will be reordered  
somewhat more than usual.

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 20 Jul 2009 15:04:04 +0200

On Jul 20, 2009, at 3:00 PM, Iljitsch van Beijnum wrote:

> receiving TCP it's TCP as usual, except that packets will be  
> reordered somewhat more than usual.
OK, thanks.

Best regards
Michael

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 21 Jul 2009 11:04:46 +0100

Hi,

We've revised the two-ended multipath TCP draft (current version is  
01)  to include comments we've received on this mailing list. The  
main changes from the previous version are:
- addition of a size field to the data sequence number, to protect  
against middleboxes that fragment and reassemble TCP segments
- convergence on a single proposal to do address management, that is  
based on "add address/remove address" tcp options.

We've also created an additional document on design decisions for  
multipath TCP: this briefly explains why we multipath TCP looks as it  
does today.
Despite a large solution space, real-world requirements have steered  
the design of the protocol to something really specific and narrow;  
we believe there are few alternative designs that meet the same  
requirements, but are of course more than willing to hear your  
thoughts and proposals.

Both docs are referenced from the multipath wiki page: http:// 
trac.tools.ietf.org/area/tsv/trac/wiki/MultipathTcp

See you at the IETF,
Costin