Subject: Re: [appsdir] [apps-discuss] AD Fail - MPTCP API

From: SM <[email-masked]>
Date: Wed, 14 Nov 2012 14:53:29 -0800

At 13:48 14-11-2012, Pete Resnick wrote:
>If I were a good AD, I'd have been monitoring this all along and 
>would have given a long heads up, before IETF Last Call. If I were a 
>good AD, I would have asked for an Apps Directorate review. Now, 
>Last Call complete and less than 19 hours before an IESG Telechat, I 
>come to you, head hung in shame. Bad Pete.

Apologies to Pete for not catching this.

Claudio, Enrico, Vijay, or anyone else, could you please take a quick 
look at this and comment?

Thanks,
-sm

>https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ is on 
>tomorrow's telechat. I love MPTCP and think it is exactly the right 
>way to deal with multiple interfaces, but some of the stuff in this 
>particular document makes me nervous. Unfortunately, I have not 
>written any code to a sockets API in too long. I have already bugged 
>two people for comments (thanks Chris and Cyrus), but I wouldn't 
>mind more people looking at this document. It's only Informational, 
>but I am quite sure people will start coding this stuff. I'm 
>personally more worried about the legacy API interactions (see 
>section 4.2.2 in particular), but if you have thoughts on the new 
>APIs as well, they would be welcome.
>
>I'm going to be writing up my comments, but at this point I'm not 
>planning on asking to DISCUSS it. But if anyone has concerns where 
>you think, "Holy crap! You can't let people start coding that, even 
>if it is just experimental!", you've got not much time to let me know.
>
>Begging your forgiveness,
>
>pr
>
>--
>Pete Resnick<http://www.qualcomm.com/~presnick/>
>Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Nov 2012 14:59:07 -0800

I'll look at it this evening.

On Wed, Nov 14, 2012 at 2:53 PM, SM <[email-masked]> wrote:

>> If I were a good AD, I'd have been monitoring this all along and would
>> have given a long heads up, before IETF Last Call. If I were a good AD, I
>> would have asked for an Apps Directorate review. Now, Last Call complete
>> and less than 19 hours before an IESG Telechat, I come to you, head hung in
>> shame. Bad Pete.
>>
>
> Claudio, Enrico, Vijay, or anyone else, could you please take a quick look
> at this and comment?
>
> Thanks,
> -sm
>
>
>  https://datatracker.ietf.org/**doc/draft-ietf-mptcp-api/<https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/>is on tomorrow's telechat. I love MPTCP and think it is exactly the right
>> particular document makes me nervous. Unfortunately, I have not written any
>> code to a sockets API in too long. I have already bugged two people for
>> comments (thanks Chris and Cyrus), but I wouldn't mind more people looking
>> at this document. It's only Informational, but I am quite sure people will
>> start coding this stuff. I'm personally more worried about the legacy API
>> interactions (see section 4.2.2 in particular), but if you have thoughts on
>> the new APIs as well, they would be welcome.
>>
>> planning on asking to DISCUSS it. But if anyone has concerns where you
>> think, "Holy crap! You can't let people start coding that, even if it is
>> just experimental!", you've got not much time to let me know.
>>
>> Pete Resnick<http://www.qualcomm.**com/~presnick/<http://www.qualcomm.com/~presnick/>
>> >
> ______________________________**_________________
> appsdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/appsdir<https://www.ietf.org/mailman/listinfo/appsdir>
>

---

From: Pete Resnick <[email-masked]>
Date: Wed, 14 Nov 2012 21:38:52 -0600

On 11/14/12 4:53 PM, SM wrote:
>> good AD, I would have asked for an Apps Directorate review. Now, Last 
>> Call complete and less than 19 hours before an IESG Telechat, I come 
>> to you, head hung in shame. Bad Pete.
>

No apology necessary. I didn't catch it either (obviously).

Thanks.

pr

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 15 Nov 2012 08:34:45 +0100 (CET)

On Wed, 14 Nov 2012, SM wrote:

>> If I were a good AD, I'd have been monitoring this all along and would have 
>> given a long heads up, before IETF Last Call. If I were a good AD, I would 
>> have asked for an Apps Directorate review. Now, Last Call complete and less 
>> than 19 hours before an IESG Telechat, I come to you, head hung in shame. 
>> Bad Pete.
>
> Claudio, Enrico, Vijay, or anyone else, could you please take a quick look at 
> this and comment?

OK, will to today!

>
> Thanks,
> -sm
>
>> https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ is on tomorrow's 
>> telechat. I love MPTCP and think it is exactly the right way to deal with 
>> multiple interfaces, but some of the stuff in this particular document 
>> makes me nervous. Unfortunately, I have not written any code to a sockets 
>> API in too long. I have already bugged two people for comments (thanks 
>> Chris and Cyrus), but I wouldn't mind more people looking at this document. 
>> It's only Informational, but I am quite sure people will start coding this 
>> stuff. I'm personally more worried about the legacy API interactions (see 
>> section 4.2.2 in particular), but if you have thoughts on the new APIs as 
>> well, they would be welcome.
>> 
>> I'm going to be writing up my comments, but at this point I'm not planning 
>> on asking to DISCUSS it. But if anyone has concerns where you think, "Holy 
>> crap! You can't let people start coding that, even if it is just 
>> experimental!", you've got not much time to let me know.
>> 
> _______________________________________________
> appsdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/appsdir
>

------------------------------------------------------------------------------
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: Claudio Allocchio <[email-masked]>
Date: Fri, 16 Nov 2012 00:25:02 +0100 (CET)

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