<div dir="auto"><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><span style="color:rgb(51,51,51);font-family:"open sans","helvetica neue",arial;font-size:14px;text-align:justify;background-color:rgb(255,255,255)"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 Jun. 2017 19:21, "John Edwards" <<a href="mailto:jaedwards@gmail.com" target="_blank">jaedwards@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Better to put all of your output power into the lowest frequency channel on a network today.<br>
<br>
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.<br>
<br>
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.<br>
<br>
All of this points to a future where clients use  multiple receive radios and a limited transmit capability.<br>
<br>
An effective multipath capability in this environment will need to leverage a single upstream interface to coordinate multiple downstream interfaces.<br>
<br>
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!<br>
<br>
John<br>
<br>
<br>
<br>
<br>
<br>
<br>
Sent from my iPhone<br>
> On 11 Jun 2017, at 1:09 pm, Mark Smith <<a href="mailto:markzzzsmith@gmail.com">markzzzsmith@gmail.com</a>> wrote:<br>
><br>
>> On 11 June 2017 at 11:21, Paul Holmanskikh <<a href="mailto:ausnog@pkholm.com">ausnog@pkholm.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>> Problem that it is only for TCP.  It  will not help you with UDP and QUIC.<br>
>> So solutions like Cisco iWAN are still relevant.<br>
>><br>
>><br>
><br>
> <a href="https://datatracker.ietf.org/wg/quic/charter/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/<wbr>wg/quic/charter/</a><br>
><br>
> "The QUIC working group will provide a standards-track specification for<br>
> a UDP-based, stream-multiplexing, encrypted transport protocol, based<br>
> on pre-standardization implementation and deployment experience, ...<br>
><br>
><br>
> Key goals for QUIC are:<br>
><br>
> - Minimizing connection establishment and overall transport latency<br>
> for applications, starting with HTTP/2;<br>
> - Providing multiplexing without head-of-line blocking;<br>
> - Requiring only changes to path endpoints to enable deployment;<br>
> - *** Enabling multipath *** and forward error correction extensions; and<br>
> - Providing always-secure transport, using TLS 1.3 by default."<br>
> ______________________________<wbr>_________________<br>
> AusNOG mailing list<br>
> <a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
> <a href="http://lists.ausnog.net/mailman/listinfo/ausnog" rel="noreferrer" target="_blank">http://lists.ausnog.net/<wbr>mailman/listinfo/ausnog</a><br>
</blockquote></div></div>