Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mptcp-api-06

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 15 Dec 2012 17:54:10 -0800

Hello Barry,

As stated in our charter, we're thinking about working on the following
documents.

   Apr 2013 - Implementation advice (Informational) to IESG
   Aug 2013 - Use-cases and operational experiences (Informational) to IESG

I think these docs might be able to address your points.
In my feeling, it might be better to work on application considerations
with some more implementation experiences.
Thanks,
--
Yoshifumi Nishida

On Mon, Nov 26, 2012 at 8:33 AM, Barry Leiba <[email-masked]>
wrote:
>
> >> 3.1.2.  Delay
> >>
> >>     Since burstiness is commonplace on the Internet
> >>     today, it is unlikely that applications will suffer from such an
> >>     impact on the traffic profile, but application authors may wish to
> >>     consider this in future development.
> >>
> >> well, even it is true the burstiness is common on most of the
> >> Internet, this is not the case in many other circumstances, and there
> >> are, maybe a few, applications which do expect the jitter to be low
> >> and the packet delivery rate to be stable to work correctly (being
> >> the developer of one of them... "LOLA - Low latency A/V system" I did
> >> expericend already a number of cases where MPTCP did a disaster work
> >> just because of its presence on multiple parallel 10G links). Thus I
> >> would at least be not to optimistic in the above sentence. It is just
> >> not for future work. I just suggest changing it reportig that "this
> >> might be a problem" instead of "it is unlikely".
> >
> > [MSC] I don't know the details of the measurement you refer to, but it
is
> > certainly important to distinguish between the protocol in general and
the
> > behavior of an implementation, which is possibly work-in-progress. I do
> > agree that if a specific application does not need the additional
bandwidth
> > by multipath and if it is very latency sensitive, the use of MPTCP
could be
> > worse than use of standard TCP, in particular if the sender's scheduler
is
> > not optimal. At least in theory, in such an application-limited
scenario it
> > would make sense if the MPTCP scheduler mainly used the subflow with
> > smallest delay, i. e., jitter should be similar to a single-path TCP
connection.
> > With a reasonable scheduler in the sender, I think that the scenario you
> > mention is indeed "unlikely". Anyway, I think that the scenario you
describe
> > refers to a mostly controlled environment without congestion etc. In the
> > general Internet, an application does have to deal with jitter etc.
>
> ...etc...
>
> This and the related discussions seem to highlight that this document
> really has two pieces:
>
> 1. Considerations for using MPTCP with various applications and types
> of applications, independent of the API.
>
> 2. Definition of a basic API, and considerations specific to the API.
>
> It's possible (likely, maybe) that these should have been separate
> documents.  I'm not sure whether it's too late to tease them apart,
> but I see some significant value in a document that just lays out (1)
> by itself.  The discussion above fits into that: there's nothing about
> this that has anything to do with the API; it's considerations of
> whether MPTCP is, in general, advantageous, detrimental, or neutral
> for any particular application use case... and that's important.
>
> It becomes something of a problem when this document has some, but
> insufficient, discussion about this, as in this case.  It's easy to
> say that applications in general have to deal with burstiness on the
> Internet, so adding a bit more probably won't hurt... but, as Claudio
> points out, that might not be true for all application types, and
> further discussion of this is warranted.  The oversimplified statement
> might be OK for this document, or it might be problematic if it's
> taken as a valid statement to apply to all Internet applications.  And
> there are other points in this document that fall into this category.
>
> What should we do about that?  I've looked at the other MPTCP
> documents, and we have a very cursory section in RFC 6182 (MPTCP
> Architecture), "6.1  Interactions with Applications".  Should there be
> another document that goes into more detail about application
> considerations for MPTCP?  And what do we do with those issues in this
> document in the meantime?  Leave them as they are?  Pull them out
> altogether?  Change them to indicate that more work needs to be done
> on application considerations?
>
> Barry, Applications AD