[AusNOG] Apple starting to mainstream Multipath TCP

[Mark Smith]

As mentioned in the first article, Apple have been using MPTCP for Siri
since iOS 7, which happened to be released about a week after I presented
that presentation at AusNOG 2013. So Apple have nearly 4 years of real
world experience with it.

RPF isn't an issue.The correct source address is chosen for outbound MPTCP
subflows (which look like TCP connections to pass through middleboxes) to
pass any upstream RPF filters.


On 11 Jun. 2017 19:21, "John Edwards" <jaedwards at gmail.com> wrote:

> With mobile devices limited to something like 20dBm of aggregate output on
> all radios (including Bluetooth and NFC) for SAR purposes, there are a
> number of reasons why multipath at layer 3 may continue to be esoteric,
> just like SCTP.
>
> Better to put all of your output power into the lowest frequency channel
> on a network today.
>
> Massive MIMO arrangements will be most practical in an asymmetric
> arrangement, due to physical size of antennas and the way MRC calculations
> will affect battery life.
>
> Wifi has issues with clients and aps having different power outputs, which
> can be solved by back-channelling on more reliable channels. In Australia
> we are allowed up to 4W on wifi, whereas mobile networks are limited to 2W
> without EME analysis and community consultation.
>
> All of this points to a future where clients use  multiple receive radios
> and a limited transmit capability.
>
> An effective multipath capability in this environment will need to
> leverage a single upstream interface to coordinate multiple downstream
> interfaces.
>
> A network independent multipath will need to tolerate control protocols
> being sent from the wrong interface - something NOGs in the past have put a
> lot of effort into preventing with reverse path filtering!
>
> John
>
>
>
>
>
>
> Sent from my iPhone
> > On 11 Jun 2017, at 1:09 pm, Mark Smith <markzzzsmith at gmail.com> wrote:
> >
> >> On 11 June 2017 at 11:21, Paul Holmanskikh <ausnog at pkholm.com> wrote:
> >> Hi,
> >>
> >> Problem that it is only for TCP.  It  will not help you with UDP and
> QUIC.
> >> So solutions like Cisco iWAN are still relevant.
> >>
> >>
> >
> > https://datatracker.ietf.org/wg/quic/charter/
> >
> > "The QUIC working group will provide a standards-track specification for
> > a UDP-based, stream-multiplexing, encrypted transport protocol, based
> > on pre-standardization implementation and deployment experience, ...
> >
> >
> > Key goals for QUIC are:
> >
> > - Minimizing connection establishment and overall transport latency
> > for applications, starting with HTTP/2;
> > - Providing multiplexing without head-of-line blocking;
> > - Requiring only changes to path endpoints to enable deployment;
> > - *** Enabling multipath *** and forward error correction extensions; and
> > - Providing always-secure transport, using TLS 1.3 by default."
> > _______________________________________________
> > AusNOG mailing list
> > AusNOG at lists.ausnog.net
> > http://lists.ausnog.net/mailman/listinfo/ausnog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20170611/5a6ba1de/attachment.html>