Subject: [multipathtcp] mptcp-multiaddressed: How long before multipath starts?

From: Bob Briscoe <[email-masked]>
Date: Mon, 31 Jan 2011 17:15:16 +0000

Alan Costin, Mark, or ANOther,

The large majority of TCP flows are very short. If there will only be 
one or two packets to send, there will be no point sending off loads 
of requests to open sub-flows straight after the first 3-way handshake.

So I imagined there would be some advice in one of the MPTCP I-Ds on 
how long a MPTCP should wait until it attempts to open sub-flows.

I can't find this from a quick scan. I would have expected it to be 
in the heuristics section of draft-ietf-mptcp-multiaddressed:
<http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-02#section-3.8>

In general, a TCP stack doesn't know how much data the application 
might eventually want to send. So I guess the basic advice might be 
to wait n_1 RTTs before opening a second subflow, then n_2 RTTs 
before opening a third and so on.

Has anyone done any research on this to find the best tradeoff (ie 
best values of n_1, n_2, etc) between improved performance/resilience 
and wasting signalling packets? I imagine this heuristic would be 
clocked by RTTs, not real-time or bytes, because that would likely be 
the relevant parameter for the signalling tradeoff.

Then, in the API draft, there might be some discussion on whether the 
application can tell the transport how much data it intends to send, 
so the heuristics can be less blind.

Thoughts?

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "SCHARF, Michael" <[email-masked]>
Date: Mon, 31 Jan 2011 18:46:10 +0100

Bob,

> Then, in the API draft, there might be some discussion on 
> whether the application can tell the transport how much data 
> it intends to send, so the heuristics can be less blind.
> 
> Thoughts?

this information would be quite useful for the TCP stack even if it does
not support Multipath TCP. For instance, I thought about exactly such an
API call during my work on fast startup congestion control (Quick-Start
TCP, etc.). I agree very much that this information would be highly
useful, but it is not necessarily an API issue specific to Multipath
TCP.

The key question is whether app developers would ever be able to use
such an API. The simpler alternative is to just observe in the TCP stack
how much data the app actually writes and then to use this information
as input to the heuristics.

Concerning the API spec: draft-ietf-mptcp-api only specifies a minimum
set of API functions. IMHO we could mention this possibility in the
appendix as a potential feature of an advanced API. Also, note that
draft-ietf-mptcp-api already recommends to app developers to avoid many
small write socket calls. The reason for this statement is exactly to
avoid confusing stack-internal heuristics.

Michael

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 31 Jan 2011 18:15:12 +0000

Michael,

At 17:46 31/01/2011, SCHARF, Michael wrote:
>such an API.

The obvious case would be an HTTP server that sends the size of the 
object in the HTTP protocol before it starts sending it. So it would 
not be rocket-science to tell its own stack the same information as 
it already tells the remote end (and the remote end could tell its stack).

>The simpler alternative is to just observe in the TCP stack

Yes. In many cases this would work well (including the Web server 
case above in most regular cases). However, in some cases, the app 
might know that it has more data than it is currently writing to the socket.

>appendix as a potential feature of an advanced API.

As you say, perhaps mention that transfer size might be added more 
generally to the API, and be useful for MPTCP as well as other purposes.

>Also, note that

I noticed that while searching. I think the advice might need to be 
written the other way round - the heuristics would need to take 
account of the possibility of an app developer doing many small write 
socket calls.

My reasoning: MPTCP developers might read an MPTCP spec. But app 
developers won't - at least we cannot rely on it.

Cheers

Bob

---

From: "SCHARF, Michael" <[email-masked]>
Date: Mon, 31 Jan 2011 19:48:59 +0100

Bob, 

> -----Original Message-----
> The obvious case would be an HTTP server that sends the size 
> of the object in the HTTP protocol before it starts sending 
> it. So it would not be rocket-science to tell its own stack 
> the same information as it already tells the remote end (and 
> the remote end could tell its stack).

of course, it is simple for someone familiar with TCP. I actually
implemented exactly this function as proof-of-concept in the lighttpd
HTTP server quite some time ago. In that case, it required less than 20
lines of code in the lighttpd Web server (I don't think that it would be
much more complex in apache). Obviously, in my case the Web server
operated on top of a fast startup Linux stack offering such an API by
means of a new socket option.

But, there are quite a bunch of other apps out there...

> I noticed that while searching. I think the advice might need 
> to be written the other way round - the heuristics would need 
> to take account of the possibility of an app developer doing 
> many small write socket calls.

True, but this advice may not necessarily be in scope of the API draft,
given that it does not address the algorithms at all.

Michael