Subject: [multipathtcp] WG Review: Recharter of Multipath TCP (mptcp)

From: IESG Secretary <[email-masked]>
Date: Tue, 15 May 2012 11:22:49 -0700

A modified charter has been submitted for the Multipath TCP (mptcp) 
working group in the Transport Area of the IETF.  The IESG has not made 
any determination as yet.  The modified charter is provided below for 
informational purposes only.  Please send your comments to the IESG 
mailing list ([email-masked]) by Tuesday, May 22, 2012.

Multipath TCP (mptcp)
----------------------------------------------------------
Status: Active Working Group
Last updated: 2012-05-10

Chairs:
    Philip Eardley <[email-masked]>
    Yoshifumi Nishida <[email-masked]>

Transport Area Directors:
    Wesley Eddy <[email-masked]>
    Martin Stiemerling <[email-masked]>

Transport Area Advisor:
    Wesley Eddy <[email-masked]>

Mailing List: 
 Address:	[email-masked]
 To Subscribe:	https://www.ietf.org/mailman/listinfo/multipathtcp
 Archive:	http://www.ietf.org/mail-archive/web/multipathtcp/

Description of Working Group:

The Multipath TCP (MPTCP) working group develops mechanisms that add the
capability of simultaneously using multiple paths to a regular TCP
session.  Key goals for MPTCP are: to be deployable and usable without
significant changes to existing Internet infrastructure; to be usable by
unmodified applications; and to be stable and congestion-safe over the
wide range of existing Internet paths, including NAT interactions.  MPTCP
assumes that both peers are modified and that one or both peers have
multiple addresses, which often results in different network paths that
are at least partially divergent (however, note there is no guarantee
that the paths are divergent at all).

In its initial charter the WG produced experimental or informational
documents that defined:

a. An architectural framework for congestion-dependent multipath
transport protocols. It describes the motivations and the general
approach that should be followed to enable congestion-dependent
multipath transport.

b. A security threat analysis for multipath TCP.

c. A coupled multipath-aware congestion control algorithm. This
algorithm is the multipath equivalent of SACK/NewReno congestion
control.

d. Extensions to current TCP to support multi-addressed multipath TCP.
This covers all on-the-wire changes required to create a two-ended MPTCP
solution using multiple IP addresses at one or both ends. It includes a
basic security solution.                                      

e. Application Interface Considerations. It summarises the impact that
MPTCP may have on applications, such as changes in performance.  Also,
it describes an optional, basic application interface for MPTCP-aware
applications that provides access to multipath address information and a
level of control equivalent to regular TCP.

The working group now re-charters to progress various aspects of MPTCP.

The primary 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 (item d above), incorporating experience from (for
example) implementations, interoperability events, experiments, usage
scenarios, protocol corner cases, and feedback from TCPM.  There already
exists a reference Linux implementation and other implementation and
experimental activity is on-going and will continue during 2012, with
the objective of progressing the protocol to Standards Track during
2013.

The working group will document implementation advice. The current
documents have several points where an implementer may benefit from
guidance, for example about heuristics such as buffer sizing, or from
advice about alternative implementations such as bump-in-the-stack.

The working group will also explore and document results with several
of the proposed use cases for MPTCP in more detail, to ensure that
MPTCP works well in practice and that operational experiences and
issues are understood and captured.  Likely use cases are to offload
traffic from 3G to WiFi, and to manage traffic within a data centre.
Another scenario is to enable, without changing the MPTCP protocol,
operation of a single-homed, MPTCP end host on a campus network that has
multiple providers.

Finally, the working group will explore whether an MPTCP-aware
middlebox would be useful, where at least one end host is MPTCP-enabled.
For example, potentially helping MPTCPÕs incremental deployment by
allowing only one end host to be MPTCP-enabled and the middlebox acts as
an MPTCP proxy for the other end host, which runs TCP; and potentially
helping some mobility scenarios, where the middlebox acts as an anchor
between two MPTCP-enabled hosts. The working group will detail what real
problems an MPTCP-enabled middlebox might solve, how it would impact the
Multipath TCP architecture (RFC6182), what proxy approach might be
justified as compared against alternative solutions to the problems, and
the likely feasibility of solving the technical and security issues.

Goals and Milestones:

Dec 2012  Consensus on what high-level changes are needed to the
current MPTCP Experimental document in order to progress it on the
standards track

April 2013  Implementation advice (Informational) to IESG

August 2013 Use cases (Informational) to IESG

Dec 2013 MPTCP-enabled middleboxes (Informational) to IESG

Dec 2013  MPTCP standards track protocol to IESG

Jan 2014 Re-charter or close

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 May 2012 21:56:41 +0100

Hi,

I am struggling with the MPTCP recharter and wonder whether you can help me.

Firstly, it seems to me that MPTCP is effectively inserting a small session layer into the stack between the conventional transport layer and the normal top-of-layer (presumably the sockets API). I understand why this is convenient to the application used, as it is, to attaching to a socket when it wants to send data, but I am not sure that "hiding" this function is the best approach. But anyway, that is probably an aside and is a decision long since made by the WG.

I am worried that "multi-path" name may be a misnomer. AFAICS, there is no certain way to keep the two TCP sessions on different paths through the network. So "multi-session" might be a better name, and would provide more clarity to the application that uses the feature.

Clearly, there are some significant consequences to not keeping the sessions on different paths, although I understand that there may still be many benefits to running multiple parallel sessions. And, of course, ECMP implementations stand a better chance of meaningfully demultiplexing the data onto different flows if different sessions are used. But still, it seems that MPTCP is less likely to take advantage of available network resources than might initially appear to be the case from its name.
                    
How meaningful is MPTCP without MPTCP-aware load balancing routers in the network? This would seem to be key to getting good use out of the available resources by putting the multiple sessions into different buckets. Are router vendors demonstrating interest in joining in the experiment?

Indeed, what can you tell me about the take-up of this experiment so far? Obviously, there are a number of papers I can find by searching the InterWeb; these demonstrate the theoretical viability of the work, and I have read the notes on implementation and testing in the proposed charter. Has the experimentation been conducted on large scale deployed networks with live traffic?

Has anyone put any thought into the risks associated with open deployment? It is fair enough that "legacy" routers will not know the difference, but do we know that there are no other risks or exposures? Doesn't MPTCP result in an increase in the number of sessions in the network? How does that impact on processes running on. in the network?

Can you also tell me about the "hurry". The proposed charter suggests that experimentation is "ongoing" in 2012. The protocol spec is on its way to the IESG for consideration as an Experimental RFC. Normally it would seem precipitous to start work on Standards Track documents so soon. Is there a need or a strong push for this? I guess a "need" would be represented by statements from the industry that a Standards Track RFC is essential for some reason, or maybe a request from another SDO for something they can reference. A "strong push" might come from implementers building product, or from service providers / operators who need to offer "fat-pipe" services and want to make better use of their network resources. In short, who wants MPTCP?

We (the IETF) do not have an established process for progressing from Experimental to the Standards Track (compare with advancement on the Standards Track) and I am NOT about to propose one or to impose hurdles for that sort of change. Sometimes it is blatantly obvious that it is time to make the change - I would cite PIM and the work in MANET as good examples: real implementations and deployments existed, lessons had be learned, and we were ready for real-time. In other cases it is less obvious and it is helpful to put together some sort of summary of experimental discoveries, tests undertaken, and deployments erm deployed. This might be a short I-D that could be published as an RFC for the historic record. [To be clear, I am not requiring this in the
case of MPTCP, but it would certainly have helped me work out whether it really is the right time to start work on Standards Track documents.]

Thanks for your patience reading this, and for any explanations you can offer.

Adrian
> -----Original Message-----
> From: [email-masked] [mailto:ietf-announce-
> [email-masked]] On Behalf Of IESG Secretary
> Sent: 15 May 2012 19:23
> To: IETF Announcement List
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: WG Review: Recharter of Multipath TCP (mptcp)
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 21 May 2012 01:11:34 -0700

Hello Adrian,

Thanks for the feedbacks.
We've discussed the "multi-path" naming from time to time, but there
weren't strong opinions to change it yet.
"Multi-session" might be better name for some people, but I'm afraid others
might  misunderstand that MPTCP allows multiple data streams in a single
flow.

IMO, I tend to think "path" in transport layer as a logical path which is
not necessarily mapped to real network topologies. Multiple logical paths
can be mapped to a single path in real networks, but it doesn't break
MPTCP's concept at all.

My feeling about milestone is we're just trying to not be lazy. As we've
finished spec designs for experimental RFCs and have done some
investigations for the potential risks in deployment and we've seen several
implementing projects are running actively.
Although I'm not sure they can be "strong push", MPTCP is getting some
attentions from several communities.
Based on these things,  I'm not very sure if making a effort to produce a
standard for two years from now is very hasty thing.

I understand we will need really strong push when we publish a standard,
but not very sure if we need it now.

Regards,
--
Yoshifumi Nishida

On Fri, May 18, 2012 at 1:56 PM, Adrian Farrel <[email-masked]> wrote:

> Firstly, it seems to me that MPTCP is effectively inserting a small
> session layer into the stack between the conventional transport layer and
> the normal top-of-layer (presumably the sockets API). I understand why this
> is convenient to the application used, as it is, to attaching to a socket
> when it wants to send data, but I am not sure that "hiding" this function
> is the best approach. But anyway, that is probably an aside and is a
> decision long since made by the WG.
>
> I am worried that "multi-path" name may be a misnomer. AFAICS, there is no
> certain way to keep the two TCP sessions on different paths through the
> network. So "multi-session" might be a better name, and would provide more
> clarity to the application that uses the feature.
>
> Clearly, there are some significant consequences to not keeping the
> sessions on different paths, although I understand that there may still be
> many benefits to running multiple parallel sessions. And, of course, ECMP
> implementations stand a better chance of meaningfully demultiplexing the
> data onto different flows if different sessions are used. But still, it
> seems that MPTCP is less likely to take advantage of available network
> resources than might initially appear to be the case from its name.
>
> How meaningful is MPTCP without MPTCP-aware load balancing routers in the
> network? This would seem to be key to getting good use out of the available
> resources by putting the multiple sessions into different buckets. Are
> router vendors demonstrating interest in joining in the experiment?
>
> Indeed, what can you tell me about the take-up of this experiment so far?
> Obviously, there are a number of papers I can find by searching the
> InterWeb; these demonstrate the theoretical viability of the work, and I
> have read the notes on implementation and testing in the proposed charter.
> Has the experimentation been conducted on large scale deployed networks
> with live traffic?
>
> Has anyone put any thought into the risks associated with open deployment?
> It is fair enough that "legacy" routers will not know the difference, but
> do we know that there are no other risks or exposures? Doesn't MPTCP result
> in an increase in the number of sessions in the network? How does that
> impact on processes running on. in the network?
>
> Can you also tell me about the "hurry". The proposed charter suggests that
> experimentation is "ongoing" in 2012. The protocol spec is on its way to
> the IESG for consideration as an Experimental RFC. Normally it would seem
> precipitous to start work on Standards Track documents so soon. Is there a
> need or a strong push for this? I guess a "need" would be represented by
> statements from the industry that a Standards Track RFC is essential for
> some reason, or maybe a request from another SDO for something they can
> reference. A "strong push" might come from implementers building product,
> or from service providers / operators who need to offer "fat-pipe" services
> and want to make better use of their network resources. In short, who wants
> MPTCP?
>
> We (the IETF) do not have an established process for progressing from
> Experimental to the Standards Track (compare with advancement on the
> Standards Track) and I am NOT about to propose one or to impose hurdles for
> that sort of change. Sometimes it is blatantly obvious that it is time to
> make the change - I would cite PIM and the work in MANET as good examples:
> real implementations and deployments existed, lessons had be learned, and
> we were ready for real-time. In other cases it is less obvious and it is
> helpful to put together some sort of summary of experimental discoveries,
> tests undertaken, and deployments erm deployed. This might be a short I-D
> that could be published as an RFC for the historic record. [To be clear, I
> am not requiring this in the
> case of MPTCP, but it would certainly have helped me work out whether it
> really is the right time to start work on Standards Track documents.]
>

---

From: <[email-masked]>
Date: Mon, 21 May 2012 10:23:06 +0100

Adrian,

thanks for your comments

On the "hiding" question - you're right, this was decided long ago - before chartering we agreed that it should look like TCP, as far as posible, to applications and the network in order to help ease deployability

on the different paths - the WG has assumed that MPTCP's multiple paths are identified by the end host using different addresses. yes, this means that the paths can be overlapping - the congestion control algorithm is designed to work "safely" even if this is true (ie not get more than single path tcp would over the bottleneck link, whilst having at least the same throughput). if the end host has interfaces to different ISPs (eg 3G, WiFi) then the paths are likely to be disjoint (except perhaps near the other end).
we've also had some discussion about other ways that the paths might be identified - and (normal) ECMP could be used here (again, no guarantee that paths are disjoint)
neither of these approaches needs "MPTCP-aware load balancing routers in the network".

some examples of experiments to date
https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp - large scale experiments to test potential impact of middleboxes on mptcp

http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p266.pdf "Improving Datacenter Performance and Robustness with Multipath TCP" - extensive simulations plus experiemtns on EC2

there's also a paper from Louvain, accepted for Sigcomm Cellnet, experiments about "Exploring Mobile/WiFi Handover with Multipath TCP" [don't think this is public yet, but olivier can probably send off-list [email-masked]]

Georg Hampel (Alcatel-Lucent) has also been doing an implementation and mobility experiments - see slides eg http://tools.ietf.org/agenda/83/slides/slides-83-mptcp-5.pdf

so although there's been quite a bit of experiments, I'm not sure this yet meets your "experimentation .. conducted on large scale deployed networks with live traffic"

I expect that further experiments and experience over the next year will suggest some tweaks to the current protocol.

<<Doesn't MPTCP result in an increase in the number of sessions in the network? How does that impact on processes running on. in the network?>>
mptcp is designed to look like tcp. today end end hosts create many tcp sessions - which has impacted processes in the network. i don't think mptcp changes the scale of this issue.
but I agree that one of the aims of further experiments should be to identify if there are unexpected effects on 'things in the network'

As regards what "push" there is, I believe that the Louvain guys are now concentrating on trying to get it into the Linux mainline. also, a couple of meetings ago Oracle said they were about to start work on Solaris. swinburne is now working on freeBSD http://caia.swin.edu.au/urp/newtcp/mptcp/

best wishes,
phil

________________________________
From: Yoshifumi Nishida [[email-masked]]
Sent: 21 May 2012 09:11
To: [email-masked]
Cc: [email-masked]; Eardley,PL,Philip,DUB8 R; [email-masked]
Subject: Re: WG Review: Recharter of Multipath TCP (mptcp)

Hello Adrian,

Thanks for the feedbacks.
We've discussed the "multi-path" naming from time to time, but there weren't strong opinions to change it yet.
"Multi-session" might be better name for some people, but I'm afraid others might  misunderstand that MPTCP allows multiple data streams in a single flow.

IMO, I tend to think "path" in transport layer as a logical path which is not necessarily mapped to real network topologies. Multiple logical paths can be mapped to a single path in real networks, but it doesn't break MPTCP's concept at all.

My feeling about milestone is we're just trying to not be lazy. As we've finished spec designs for experimental RFCs and have done some investigations for the potential risks in deployment and we've seen several implementing projects are running actively.
Although I'm not sure they can be "strong push", MPTCP is getting some attentions from several communities.
Based on these things,  I'm not very sure if making a effort to produce a standard for two years from now is very hasty thing.

I understand we will need really strong push when we publish a standard, but not very sure if we need it now.

Regards,
--
Yoshifumi Nishida

On Fri, May 18, 2012 at 1:56 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Adrian
> From: [email-masked]<mailto:[email-masked]> [mailto:ietf-announce-<mailto:ietf-announce->
> [email-masked]<mailto:[email-masked]>] On Behalf Of IESG Secretary
> Sent: 15 May 2012 19:23
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> mailing list ([email-masked]<mailto:[email-masked]>) by Tuesday, May 22, 2012.
>
> Multipath TCP (mptcp)
>     Philip Eardley <[email-masked]<mailto:[email-masked]>>
>     Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>
>
>     Wesley Eddy <[email-masked]<mailto:[email-masked]>>
>     Martin Stiemerling <[email-masked]<mailto:[email-masked]>>
>
> Transport Area Advisor:
>     Wesley Eddy <[email-masked]<mailto:[email-masked]>>
>
> Mailing List:
>  Address:     [email-masked]<mailto:[email-masked]>

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 21 May 2012 12:23:36 +0200

Adrian,
> Firstly, it seems to me that MPTCP is effectively inserting a small session layer into the stack between the conventional transport layer and the normal top-of-layer (presumably the sockets API). I understand why this is convenient to the application used, as it is, to attaching to a socket when it wants to send data, but I am not sure that "hiding" this function is the best approach. 

The main advantage of this approach is that existing applications do not
have to be modified. SCTP took a different approach by changing the
protocol number in the IP header and the socket API. This made SCTP very
difficult to be deployed. MPTCP can be incrementally deployed.

> But anyway, that is probably an aside and is a decision long since made by the WG.

> I am worried that "multi-path" name may be a misnomer. 

I tend to agree. A few weeks ago, I discussed with a routing researcher
who saw Multipath TCP as a way to "virtualise" a TCP connection. In
fact, Multipath TCP decouples a TCP connection from its IP endpoints. In
the 1970s, the designers of TCP/IP chose to couple TCP and IP by
introducing the pseudo-header in the checksum computation. In this long
term, this proved to be a bad design decision that forces TCP
connections to be reset every time a host changes its IP address.

> AFAICS, there is no certain way to keep the two TCP sessions on different paths through the network. 

Agreed, there is no guarantee that two TCP connections between the same
IP addresses will follow a different path. In many networks, this is
likely. When one of the endpoints uses different IP adresses (e.g. an
IPv4 and an IPv6 address or a WiFi and a 3G interface), then the TCP
connections use different paths.

>So "multi-session" might be a better name, and would provide more clarity to the application that uses the feature.

Maybe, but I'm not sure that changing the name is necessary.

> How meaningful is MPTCP without MPTCP-aware load balancing routers in the network? This would seem to be key to getting good use out of the available resources by putting the multiple sessions into…

Note that MPTCP does not require any MPTCP-awareness in the network.
MPTCP was designed with existing networks in mind and can exploit
current paths or fallback to regular TCP when strange middleboxes interfere.

See "Is it still possible to extend TCP" presented at IMC and available
from http://www.micchie.net/publications.html

Two interesting case studies :

- a host with IPv4 and IPv6 can open a TCP connection over IPv4 and
learn through MPTCP that the server also supports IPv6 and use both IPv4
and IPv6 to retrieve data over a single MPTCP conenction
- a smartphone with WiFi and 3G interfaces can use Multipath TCP to
switch from WiFi to 3G when WiFi fails and the opposite.

See
http://inl.info.ucl.ac.be/publications/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp

A video of the smartphone case study is available at
http://mptcp.info.ucl.ac.be

> Indeed, what can you tell me about the take-up of this experiment so far? Obviously, there are a number of papers I can find by searching the InterWeb; these demonstrate the theoretical viability o…

The Linux kernel implementation is available from the website above. We
have conducted successful experiments in labs, through two 3G providers,
through several ADSL providers and are using MPTCP over the global Internet.

> Has anyone put any thought into the risks associated with open deployment? It is fair enough that "legacy" routers will not know the difference, but do we know that there are no other risks or exposures? Doesn't MPTCP result in an increase in the number of sessions in the network?

This is a function on how the MPTCP implementation is configured. A web
client can open a large number of TCP connections. An MPTCP
implementation can open one or more TCP subflows per MPTCP connection.
Smartphones could open a single TCP subflow and use it mainly for
handover. Servers could use more subflows depending on the network
conditions.

> How does that impact on processes running on. in the network?
> 

We have seen a growing interest in using Multipath TCP to support
3G/WiFi offload and the Linux implementation supports this. Georg Hampl
is also working on another implementation for this environment.

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

---

From: John Leslie <[email-masked]>
Date: Mon, 21 May 2012 08:43:59 -0400

> I am struggling with the MPTCP recharter and wonder whether you can help me.

   I'd be happy to try...

> session layer into the stack between the conventional transport layer
> and the normal top-of-layer (presumably the sockets API).

   I guess that's one way to think of it... Myself, I think of TCP as
a "transport" layer; and MPTCP is careful to look exactly like a transport
layer to the network and almost-exactly like a transport layer to the
endpoints, with some magic so that the network may see more than one
connection matching the single logical connection of the endpoints.

> I understand why this is convenient to the application used, as it is,
> to attaching to a socket when it wants to send data, but I am not sure
> that "hiding" this function is the best approach.

   "Hiding" from the network is, alas, essential. (And it's really none
of its business, anyway!)

   "Hiding" from the application layer is not essential; and I fully
expect that as time progresses, there will be less of it.

> I am worried that "multi-path" name may be a misnomer.

   Likewise, a decision long-since-made. Re-naming it at this stage is
not reasonable.

> different paths through the network.

   True, but irrelevant, IMHO. Besides, _all_ names are optimistic!

> So "multi-session" might be a better name, and would provide more

   I don't agree it would be a better name. Multi "path" better expresses
the aim of MPTCP; and (IMHO) it's a better thing to aim for.
   
> sessions on different paths,

   I don't follow... There is no way we could ensure separate paths.
There are too many cases where enterprises have been paying telcos for
separate-path T-1s only to learn they weren't separate at all!

> although I understand that there may still be many benefits to
> running multiple parallel sessions.

   Perhaps the most important benefit is being able to bring up and
take down paths as conditions change.

> ... But still, it seems that MPTCP is less likely to take advantage
> of available network resources than might initially appear to be the
> case from its name.

   That's not a fair criticism. MPTCP will take advantage of network
resorces that _are_ available. There's a chicken-and-egg issue of why
the resources would _be_ available before there's a practical way to
use them.

> How meaningful is MPTCP without MPTCP-aware load balancing routers
> in the network?

   100%

   (I can't quite conceive of anything for such an animal to _do_...)

> This would seem to be key to getting good use out of the available
> resources by putting the multiple sessions into different buckets.

   MPTCP isn't aiming there, if I understand your issue.

   MPTCP is aiming at being able to move traffic over a less-congested
path (or off of a failed path) without requiring application-layer
action. It also holds promise of easing a transition from IPv4 to IPv6.
Bonding "equal" paths really isn't an aim -- that's better done at a
lower layer.

> ... Has the experimentation been conducted on large scale deployed
> networks with live traffic?

   The point, IMHO, is that we're nearing the stage where the "experiment"
can't be backed out. (And this will pretty much happen regardless of what
the IESG may do.) Most of the WG participants are convinced there's been
enough experimenting to show that MPTCP can be safely deployed in the
big-I internet.

> Has anyone put any thought into the risks associated with open

   Yes. (Quite a bit of thought, actually.)

> It is fair enough that "legacy" routers will not know the difference,
> but do we know that there are no other risks or exposures?

   Omniscience isn't a pre-requisite in the IETF. (Not even for IESG
members!)

> Doesn't MPTCP result in an increase in the number of sessions in the
> network? How does that impact on processes running on. in the network?

   I don't understand the question. A network layer, by definition,
doesn't worry about "sessions" -- it moves "packets".

> ... The protocol spec is on its way to the IESG for consideration as
> an Experimental RFC. Normally it would seem precipitous to start work
> on Standards Track documents so soon.

   That's not a helpful norm. Work on Standards Track should _start_
as soon as the experiment wants to run on the big-I internet. It will,
of course, typically take more than a year to finish...

> Is there a need or a strong push for this? I guess a "need" would be
> represented by statements from the industry that a Standards Track
> RFC is essential for some reason, or maybe a request from another SDO
> for something they can reference.

   That's a funny way to define "need" (IMHO).

   There was a time when "Experimental" status meant "Please go away."
That time has passed.

   Now "Experimental" status means "not (necessarily) safe to use on
the big-I internet". It's something we'd like to be able to back out if
it proves dangerous.

   I see a "need" for Standards-track coming as early as we admit the
experiment _won't_ be backed out. And IMHO MPTCP is really-close to
that point. Delaying the start of Standards-track won't delay the point
where we can't back it out -- it will only make it harder to avoid
danger points.

> ... We (the IETF) do not have an established process for progressing
> from Experimental to the Standards Track... Sometimes it is blatantly
> obvious... In other cases it is less obvious and it is helpful to put
> together some sort of summary of experimental discoveries, tests
> undertaken, and deployments erm deployed.

   Those things belong in the revised charter, certainly.

> ... it would certainly have helped me work out whether it really is
> the right time to start work on Standards Track documents.

   (Omniscience isn't a pre-requisite for IESG members.)

   IMHO, trying to "time" the "start" of such work belongs to the
Responsible AD, not the other IESG members; and even the Responsible AD
shouldn't aim to time it very exactly. If there are folks willing to do
the work and a benefit is reasonably likely, it seems to me chartering
such work is entirely proper.

--
John Leslie <[email-masked]>