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

From: Claudio Allocchio <[email-masked]> (by way of S Moonesamy <[email-masked]>)
Date: Thu, 15 Nov 2012 15:32:50 -0800

Hello all,

I have been selected as the Applications Area Directorate co-reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-mptcp-api-06
Title: MPTCP Application Interface Considerations
Reviewer: Claudio Allocchio
Review Date: November 15th 2012
IETF Last Call Date: n/a
IESG Telechat Date: November 15th2012

Summary: Given the arelady given comments on the apps-discuss ML on 
many parts of this informaiton documents (and I agree with them) I 
focused my review on the effects that MPTCP can have on esisting 
applications and deployment. I think the doument is anyhow very well 
written and ready for
publication. However there a few minor issues that shall be fixed.

Major Issues:

none.

Minor Issues:

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".

In the same 3.1.2 section, again there are some application (already 
now) they deeply rely for correct functiong on an accurate estimate 
of RTT (for example those dealing with audio echo cancellation, or 
those triggering large scale instrumentation synchronization (for 
example EVLBI radio telescopes). Thus it not just "new" applications, 
but what my happen to existing applications shall be mentioned.

in 3.2.1:

"An MPTCP implementation can learn the rate of MPTCP connection
    attempt successes or failures to particular hosts or networks, and on
    particular interfaces, and could therefore learn heuristics of when
    and when not to use MPTCP."

Well... are we sure this is a good suggestion? If it is a suggestion, 
then, what happens when network condition changes dynamically (for 
example because an application running as a client on a mobile host 
is moving about?)

A.2.  MPTCP Usage Scenarios and Application Requirements

There are also application which requires bulk data traffic (in the 
range 1G and above) AND anre higly interactive, thus ask for low 
latency and jitter. What should be the choice in this (already 
existing) case? SOm guidance should be added also for them.

Nits:

3.1.  Performance Impact  --> Effects on Performanc

5.2. "This can be implicit in many cases, since
           MPTCP must BE disabled by the use of binding to a specific
           address.   ^^^"

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 25 Nov 2012 23:22:09 +0100

Claudio,

Thanks for your feedback! Please find my comments below, marked by [MSC].

Michael

________________________________________
Von: Claudio Allocchio [[email-masked]]
Gesendet: Freitag, 16. November 2012 00:32
An: [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: APPSDIR review of draft-ietf-mptcp-api-06

Hello all,

Major Issues:

none.

Minor Issues:

3.1.2.  Delay

[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.

[MSC] I agree that such applications exist, and we therefore have put a warning sign in the draft that MPTCP may not be their first choice. But, again, I think that an application can only strongly rely on stable RTT etc. in a controlled environment. I am not sure what a better wording would be.

in 3.2.1:

[MSC] Well, mobility can break all heuristics. This is a problem for many TCP extensions, and this omment is thus not specific to MPTCP. We could add some statement that such heuristics can always fail. I don't think that we can specify such heuristics.

[MSC] This is the appendix. The section already mentions more or less that applications may require "High bandwidth", "Low latency and jitter stability", and "High reliability" in parallel. REQ8 somehow tries to address this. But it would be premature to nail down this problem further - apparently, there is no consensus in the working group on how to address such questions. Thus, I don't think that we should significantly extend the appendix on that.

Nits:

[MSC] Thanks!

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Nov 2012 11:33:01 -0500

>> 3.1.2.  Delay
>>
>>     Since burstiness is commonplace on the Internet
>>     consider this in future development.
>>
> [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