Subject: [multipathtcp] Re-chartering MPTCP Issue #1: Standards track protocol

From: <[email-masked]>
Date: Tue, 3 Apr 2012 11:36:56 +0100

#1 of a series of emails to try and reach consensus about the re-charter.

1.       Protocol doc from Experimental to Standards track.
The first goal of the working group is to create a bis version of the protocol document on the Standards track. This develops the current Experimental document, http://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-multiaddressed/ incorporating experience from implementations, interoperability events, experiments and use cases. There already exists a reference Linux implementation and other implementation and experiment activity is on-going and will continue during 2012, with the objective of progressing the protocol to standards track during 2013.

We did a 'hum' during the WG meeting on Friday and there was full consensus on this item - so we're now checking the consensus on the mailing list.

thanks

---

From: <[email-masked]>
Date: Tue, 3 Apr 2012 15:32:34 +0100

(personal comment)
There was some discussion about looking at a 'simple implementation' version of MPTCP. It wasn't quite clear to me what was proposed here, but I personally think we should continue to have a single MPTCP protocol (no MPTCP-lite). But an important part of the implementations and experiments mentioned below is to check whether the current capabilities are the right ones in real usage cases, and whether there are any corner cases that need solving. There's also the Informational work on implementations & advice, which would cover things that don't change the protocol.

Best wishes
phil

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 03 April 2012 11:37
To: [email-masked]
Subject: [multipathtcp] Re-chartering MPTCP Issue #1: Standards track protocol

thanks

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 4 Apr 2012 09:34:05 +0200

> The first goal of the working group is to create a bis 
> version of the protocol document on the Standards track. This 
> develops the current Experimental document, 
> http://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-multiaddressed
> / incorporating experience from implementations, 
> interoperability events, experiments and use cases. There 
> already exists a reference Linux implementation and other 
> implementation and experiment activity is on-going and will 
> continue during 2012, with the objective of progressing the 
> protocol to standards track during 2013.
> 
>  
> 
> We did a 'hum' during the WG meeting on Friday and there was 
> full consensus on this item - so we're now checking the 
> consensus on the mailing list. 

For PS, I think that the consumption of 12 byte TCP option space in the initial SYN (MP_CAPABLE) requires careful thinking and reasoning. If MPTCP becomes the default in all connections (which is what we probably want, right?), we really don't have much option space left for further TCP innovation. And, unfortunately, TCPM doesn't have a solution to the option problem right now.

Just a thought: Maybe a PS MPTCP follow-up could have some complementary operation mode with less SYN option space consumption for environments where the multiple interfaces are not so likely (e. g., non-wireless). Disclaimer: I don't know whether this is doable (e. g., an additional MP_CAPABLE type with late negotiation of keys?), and if so, at what cost, and anyway I don't think that this must be sorted out right now.

I am really fine with going towards PS, but I think that the bar for consuming 12 bytes SYN option space in a PS should be high.

Michael

---

From: Daniel Migault <[email-masked]>
Date: Wed, 4 Apr 2012 09:40:29 +0200

I am supporting this item (#1).

If MPTCP-lite  makes the host using TCP with a single interface and MPTCP
when using Multiple Interfaces, then I think it should be documented at
least for interoperability between implementations.

BR
Daniel

On Tue, Apr 3, 2012 at 12:36 PM, <[email-masked]> wrote:

> #1 of a series of emails to try and reach consensus about the re-charter.*
> ***
>
> ** **
>
> **1.       **Protocol doc from Experimental to Standards track.****
>
> The first goal of the working group is to create a bis version of the
> protocol document on the Standards track. This develops the current
> Experimental document,
> http://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-multiaddressed/incorporating experience from implementations, interoperability events,
> experiments and use cases. There already exists a reference Linux
> implementation and other implementation and experiment activity is on-going
> and will continue during 2012, with the objective of progressing the
> protocol to standards track during 2013.****
>
> ** **
>
> We did a ‘hum’ during the WG meeting on Friday and there was full
> consensus on this item – so we’re now checking the consensus on the mailing
> list. ****
>
> ** **
>
> thanks****
>
> ** **
>
> ** **
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 4 Apr 2012 08:42:30 +0000

> 1.       Protocol doc from Experimental to Standards track.

support

Lars

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 04 Apr 2012 10:49:34 +0200

> 1.       Protocol doc from Experimental to Standards track.

Support

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 4 Apr 2012 08:32:09 -0500

I am in support of #1.

Georg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 03, 2012 6:37 AM
To: [email-masked]
Subject: [multipathtcp] Re-chartering MPTCP Issue #1: Standards track protocol

thanks

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 4 Apr 2012 08:51:39 -0500

All,

I think Michael raises a valid point.

In this context: I think the WG should be open to further discussions and eventual modifications of the present MTPCP design. This may include not-yet-addressed corner cases or issues brought up by Michael.

I don't think the WG needs a special charter item for this if there is agreement that such minor adjustments can still be made.

Regards,
Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scharf, Michael (Michael)
Sent: Wednesday, April 04, 2012 3:34 AM
To: [email-masked]; [email-masked]
Subject: Re: [multipathtcp] Re-chartering MPTCP Issue #1: Standards track protocol

Michael

---

From: John Leslie <[email-masked]>
Date: Wed, 4 Apr 2012 13:59:58 -0400

> 1.       Protocol doc from Experimental to Standards track.

   While this feels a trifle premature today, it _will_ take more than
six months, by which time it should be mature.

   (Translation: I support.)

--
John Leslie <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Wed, 4 Apr 2012 14:16:17 -0400

Scharf, Michael (Michael) <[email-masked]> wrote:
> 
> For PS, I think that the consumption of 12 byte TCP option space in the
> initial SYN (MP_CAPABLE) requires careful thinking and reasoning.

   No more so than any 12 other bytes, IMHO.

   Which is to say, I don't think _we_ should try to solve the option-space
issue -- I think TCPM should. It's somewhat like having a dozen WGs all
trying to solve NAT-traversal.

>... And, unfortunately, TCPM doesn't have a solution to the option problem
> right now.

   I will commit my efforts to working on this in TCPM.

> I am really fine with going towards PS, but I think that the bar for
> consuming 12 bytes SYN option space in a PS should be high.

   I don't agree it needs to be any higher for PS than Experimental...

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 4 Apr 2012 21:19:35 +0200

> > For PS, I think that the consumption of 12 byte TCP option space in 
> > the initial SYN (MP_CAPABLE) requires careful thinking and 
> reasoning.
> 
>    Which is to say, I don't think _we_ should try to solve 
> the option-space issue -- I think TCPM should. It's somewhat 
> like having a dozen WGs all trying to solve NAT-traversal.

The TCPM mailing list archive is full of discussions on the interoperability and backward-compatibility issues of TCP option space extension in SYNs. Just asking TCPM for more option space doesn't solve any of those technical issues.

Compared to that, some fine-tuning of the initial MPTCP negotiation when moving to PS could be a lower hanging fruit.

Michael

---

From: Lukasz Budzisz <[email-masked]>
Date: Thu, 05 Apr 2012 09:29:53 +0200

> 1.Protocol doc from Experimental to Standards track.
>

Support.

BR,
Lukasz

---

From: John Leslie <[email-masked]>
Date: Sat, 7 Apr 2012 09:35:20 -0400

It finally occurred to me, after reading stuff about RTC congestion,
that there's a potential in MPTCP to maintain one path as lower latency,
not filling the buffer as TCP congestion-control tends to do.

   I'm not even sure this helps very much; but there's a common case
where the principal latency issue is in the customer uplink: thus MPTCP
may be in a position to have a positive effect on latency.

   I have nothing to propose in the way of charter text yet -- this even
feels like more of a research issue -- but the idea seem worth sharing.

   IP telephone is the obvious beneficiary of this sort of thing, but
there's a whole lot of conferencing work that might benefit even more...

---

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

FWIW, the following draft (which was discussed briefly in TCPM) is an
attempt to revive discussions on the TCP option space issue.

http://tools.ietf.org/html/draft-ananth-tcpm-tcpoptext-00

There could be other ways to scavenge TCP option space (I am sure, left
out a few thoughts that came to my mind), but none of the "solutions" is
a clear winner.  At least my belief is that if there are some guidelines
established, we could still converge on a single method with some
caveats. 

Please post your thoughts on the TCPM mailing list. MPTCP is clearly one
important use case for extending TCP option space.

-Anantha

> From: [email-masked] [mailto:multipathtcp-
> [email-masked]] On Behalf Of John Leslie
> Sent: Wednesday, April 04, 2012 11:16 AM
> To: Scharf, Michael (Michael)
> Cc: [email-masked]
> Subject: Re: [multipathtcp] Re-chartering MPTCP Issue #1:
> Standardstrack protocol
> 
reasoning.
>    Which is to say, I don't think _we_ should try to solve the option-
> space issue -- I think TCPM should. It's somewhat like having a dozen
> WGs all trying to solve NAT-traversal.
> 
> >... And, unfortunately, TCPM doesn't have a solution to the option
> >problem  right now.
>