[AusNOG] Apple starting to mainstream Multipath TCP

John Edwards jaedwards at gmail.com
Sun Jun 11 19:21:22 EST 2017


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


More information about the AusNOG mailing list