Subject: [multipathtcp] Multipath API - Service Type

From: "Ford, Alan" <[email-masked]>
Date: Fri, 12 Nov 2010 05:40:27 -0000

Hi all,

Over the last few IETFs, we've had various discussions about the
desirable scope of a Multipath TCP API. After Anaheim, the mood seemed
very much against putting advanced options in the API and we should
concentrate on maintaining the same level of functionality as regular
TCP.

However, we've since continued to have interesting discussions about how
the changing service model of MPTCP may affect applications, and thus we
may want to encourage some selection of this as a fundamental feature.
In a corridor discussion yesterday, for example, we discussed the issue
of consistency of bandwidth (not traditional jitter in the sense of
packet inter-arrival time). This is a new QoS metric, different from
traditional latency/bw/jitter, and could be targetted at video streaming
codecs, for example, and is something that is partially under the
control of MPTCP.

Ultimately the scope of the API is the choice of implementers, but we
may wish to promote relevant aspects from the extended API appendix to
the main body of the document. In particular, we would be looking at
presenting an optional QoS request:
* Maximise bandwidth
* Minimise latency
* Minimise jitter
* Minimise bandwidth jitter
* Maximise reliability (i.e. duplicate traffic on two paths)

Unlike IPv4 ToS, for example, these would be mutually exclusive in
MPTCP, and controlled by the end host, so we lose many of the problems
associated with greedy applications choosing the "best" service.

We had proposed:
   1.  High bandwidth
   2.  Low latency and jitter stability
   3.  High reliability
In the API. However, in my list above I've started to break down
stability (item 2) since that comes in various forms, which while it may
be abtractable for some applications, is very relevant for many
applications (real-time audio/video in particular).

I realise this could very quickly get excessively complicated, however
it seems important we provide a service that will not cause problems for
application authors. What do people think?

Cheers,
Alan

---

From: Andreas Ripke <[email-masked]>
Date: Fri, 12 Nov 2010 07:43:55 +0000

Hi,

I just wonder... when these options are mutually
exclusive and both end hosts employ different
ones for the same connection, does it bite? Or
is it necessary / more beneficial to advertise
the option to the peer?

Best,

	Andreas

---

From: Javier Ubillos <[email-masked]>
Date: Fri, 19 Nov 2010 10:45:38 +0100

> * Maximise reliability (i.e. duplicate traffic on two paths)

I got a few too, which may be a simple case of local policy (or maybe
not).
E.g. preferring certain interfaces, choosing _not_ to multi-path, but
allow for a smooth switch to some other interface.
I remember Lars Eggert mentioned that someone, somewhere, was looking at
switching interfaces depending on the data/Ah ratio. (something I
personally think is a killer-feature :)

// Javier

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp