Subject: [multipathtcp] On the payload vs. options debate

From: Janardhan Iyengar <[email-masked]>
Date: Sat, 20 Mar 2010 01:16:27 -0400 (EDT)

Hi all,

[Thank you Costin, for your detailed analysis of the choices.]

There are clearly pros and cons for both options and for payload, and it may be naturally tempting to go with the path of least resistance, whichever one that may end up being.  But I think that the answer to this question can potentially have an impact on more than simply MPTCP.

The key insight in MPTCP's design draws from past experience in transport work: that the network-facing side (including middleboxes as part of the network) and the application-facing sides of the transport should remain backward-compatible.  While the application-facing side of the transport, or new transport services, can be different and can be deployed according to application-demand, the network-facing side of any new transport protocol *must* be backward-compatible for *any* reasonable deployment of the new transport---there is practically no incentive for middlebox-manufacturers to support new formats.

This matters for the following reason: new application demands should drive new transport services, but in designing MPTCP, we are finally re-drafting TCP as not an end-to-end transport protocol (which it really isn't anymore), but as a "channel protocol" of sorts, to simply get through the network without performance penalties.  MPTCP recognizes the fact that TCP is (almost) necessary to simply provide reachability through the Internet.  In some ways, TCP has been relegated to "ossified-minion" status, and smarts need to be built on top of this minion.

MPTCP signalling inside of the TCP payload is essentially, and appropriately, encapsulation; it is a recognition of the fact that we *need* a "flow protocol"---TCP---to get through the network, and our smarts---the end-to-end layer---should reside above it.

So, my higher-order bit is this: we have interest around the table in getting MPTCP implemented and deployed, and the chances of it actually happening seem reasonable.  Given the high vendor interest in MPTCP, there may actually be some room for vision here: if we design MPTCP in such a way that its design and implementation in various operating systems opens up the door for other extant and newer transports to "plug-in" later, we may have paved a way for designing, implementing and deploying newer transports.

MPTCP signalling in the TCP payload (with optimizations using options for possibly DATA-ACKS) aligns well with this vision, and so I will argue for payload instead of options.  The design that we come up with and subsequent implementations will be first examples of an end-to-end protocol running truly on top of "minion-TCP", and will serve as starting points for other end-to-end protocols.

Thoughts?
- jana

-- 
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 20 Mar 2010 20:45:25 +0000

Jana,

What you say is a nice way of thinking about it. Aside from all the 
practical issues about fitting in with the past, we ought to do this 
properly for the future too. However,...

<DEVIL'S_ADVOCATE>
Just because MPTCP is 'above' minion TCP, doesn't mean it has to have 
it's own formal layerspace for its headers. It's sometimes useful to 
have a heap of related headers rather than a stack.

The structural questions that would clinch it for me would be:

1) Would this higher MPTCP layer ever be able to run over a non-TCP 
transport with a clean separation between them and no common functions?

The worrying functions are (at least) congestion control, flow 
control & integrity checking.

- MPTCP *replaces* CC & FC, rather than adds on top of them. OK, 
maybe we could argue CC&FC should be a sub-layer of the transport (as 
you do), and TCP just didn't recognise that soon enough. However, 
there's a lot of nice coupling up of parts of the CC algo and the 
reliability function etc.

- And you don't want to be doing checksumming twice, so if you 
protect the TCP headers and payload together in the TCP header, then 
you have to worry about handing off the MPTCP payload to another 
process (strictly might be on another processor - could that make 
sense?) and losing integrity because MPTCP doesn't do its own checksum.

2) Can one envisage a need for a TCP sub-flow to deliver an opaque 
encrypted payload to a separate MPTCP process in a separate security 
partition run by a separate security principle? Or possibly on a 
separate machine (e.g. across a data centre)?

If there are functions that cross both layers 
(inter-layer-processing), then there's not really an argument for 
formally layering them.
</DEVIL'S_ADVOCATE>

That doesn't mean there aren't pragmatic reasons for putting MPTCP in 
the TCP payload (e.g. lack of TCP option space). I'm just pointing 
out that layering isn't inherently beautiful for it's own sake, esp 
if we need a heap of quite inter-related functions.

Bob

At 19:00 20/03/2010, [email-masked] wrote:
>Content-Transfer-Encoding: 7bit
>From:
>Precedence: list
>MIME-Version: 1.0
>To: [email-masked]
>Date: Sat, 20 Mar 2010 01:16:27 -0400 (EDT)
>Message-ID: <319198815.1787961269062187509.JavaMail.root@zimbe2>
>Content-Type: text/plain; charset=utf-8
>Subject: [multipathtcp] On the payload vs. options debate
>Message: 1
>
>Hi all,
>
>There are clearly pros and cons for both options and for payload, 
>and it may be naturally tempting to go with the path of least 
>resistance, whichever one that may end up being.  But I think that 
>the answer to this question can potentially have an impact on more 
>than simply MPTCP.
>
>The key insight in MPTCP's design draws from past experience in 
>transport work: that the network-facing side (including middleboxes 
>as part of the network) and the application-facing sides of the 
>transport should remain backward-compatible.  While the 
>application-facing side of the transport, or new transport services, 
>can be different and can be deployed according to 
>application-demand, the network-facing side of any new transport 
>protocol *must* be backward-compatible for *any* reasonable 
>deployment of the new transport---there is practically no incentive 
>for middlebox-manufacturers to support new formats.
>
>This matters for the following reason: new application demands 
>should drive new transport services, but in designing MPTCP, we are 
>finally re-drafting TCP as not an end-to-end transport protocol 
>(which it really isn't anymore), but as a "channel protocol" of 
>sorts, to simply get through the network without performance 
>penalties.  MPTCP recognizes the fact that TCP is (almost) necessary 
>to simply provide reachability through the Internet.  In some ways, 
>TCP has been relegated to "ossified-minion" status, and smarts need 
>to be built on top of this minion.
>
>MPTCP signalling inside of the TCP payload is essentially, and 
>appropriately, encapsulation; it is a recognition of the fact that 
>we *need* a "flow protocol"---TCP---to get through the network, and 
>our smarts---the end-to-end layer---should reside above it.
>
>So, my higher-order bit is this: we have interest around the table 
>in getting MPTCP implemented and deployed, and the chances of it 
>actually happening seem reasonable.  Given the high vendor interest 
>in MPTCP, there may actually be some room for vision here: if we 
>design MPTCP in such a way that its design and implementation in 
>various operating systems opens up the door for other extant and 
>newer transports to "plug-in" later, we may have paved a way for 
>designing, implementing and deploying newer transports.
>
>MPTCP signalling in the TCP payload (with optimizations using 
>options for possibly DATA-ACKS) aligns well with this vision, and so 
>I will argue for payload instead of options.  The design that we 
>come up with and subsequent implementations will be first examples 
>of an end-to-end protocol running truly on top of "minion-TCP", and 
>will serve as starting points for other end-to-end protocols.
>
>Thoughts?
>- jana

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design