Re: [Int-area] MPT Network Layer Multipath Library (draft-lencse-tsvwg-mpt-00.txt)

[Gabor Lencse <[e-mail]>]

Dear David,

Thank you very much for your answer. Please find my answers inline.

On 7/25/2017 8:03 PM, David Schinazi wrote:
> Hi Gabor,
>
> I don't think the problem space is quite as simple:
>
> 1) Many content providers will return different DNS results based on 
> where you're querying from. For this reason you need to perform DNS 
> and your transport protocol on the same interface to be efficient.

You are completely right. Unfortunately the deployment scenarios are 
completely missing from the draft. I plan to include them into version 
"-01".

As for the current examples, I would call the applicable scenario as 
"MPT service provider scenario", which is the following:
- The client side MPT server is executed on my laptop (or smartphone).
- The service provider side MPT server is executed by an "MPT service 
provider". (*)
- An MPT tunnel is set up between the two above MPT servers using all 
the available paths (WiFi, LTE)
- Client software (in our case Meetecho, Skype, Viber, etc.) uses the 
tunnel IP for all communication (both for sending DNS queries and VoIP 
data).

(*) In my case it would be an MPT server at NAIST. In general, there are 
two conditions:
(1) it should be close to the client
(2) it should have high speed Internet connection

Of course, what I can achieve is not as good as if I would sit in my 
room at NAIST and use the Gigabit Ethernet connection, but the 
reliability of the solution is better than that of using WiFi only, and 
the price of the solution is less than that of using LTE only.

In general, an "MPT service provider" can be an independent provider or 
some ISPs also may provide this service. Multipath resilience and 
throughput aggregation apply only to the section between the two MPT 
servers. This is the most problematic part by means of unreliability and 
cost.


Other possible scenarios would include MPT servers at data center sites 
interconnected by several independent high speed paths...

> 2) Congestion properties can differ greatly per link, for that reason 
> you'll need to have separate per-link congestion control to avoid 
> starving one link or risking congestion collapse on the other.

Yes, this is another issue, which has not been addressed yet. I add this 
also to the "ToDo" list.

> For these reasons, transport-layer solutions like MPTCP or MPQUIC are 
> preferable: you perform DNS on your favorite link and connect there, 
> the server provides you with extra addresses and the client host can 
> then open up different paths via link selection or source address 
> selection.

The problem with this solution is that MPTCP provides only TCP. Its 
retransmission mechanism is probably disadvantageous for real-time 
traffic. (Sometimes loss may be better than very long delay, which 
applies for all the following data.)

> Don't get me wrong, in general I'm a very big proponent of using IP as 
> our narrow waist to allow innovation at the above and below layers. 
> However, in this case I don't think you can build a safe and efficient 
> solution exclusively at the IP layer, because what you're trying to 
> improve is transport-layer performance (again the only motivation I 
> see in the draft is "throughput" and "resilience" [Abstract] which I 
> don't see as main goals for a networking stack, latency is still the 
> first priority [1].

Whereas I agree with the main message of [1], I would say that Delay, 
Throughput and Resilience (or Reliability) are all important and none of 
them may be neglected. (Since the time when we used modems, there was a 
huge development in the transmission rates, and it has its results: 
currently about 75% of the Internet traffic is video and it is 
increasing. -- I could not dream of video calling of my wife from Japan 
to Hungary without this development.)

> You may have solved these issues, but I couldn't find that in the 
> draft. For example, in draft-lencse-tsvwg-mpt-00 section 5.2, you 
> mention that "(E.g. WiFi is used for Torrent traffic and LTE is used 
> for VoIP calls.)" without specifying how the IP layer can 
> differentiate these various types of traffic.

Section 5.2 is still "Under construction".

Our idea is that the usual 5-tuple (source IP address, source port 
number, destination IP address, destination port number, and protocol 
number (TCP or UDP)) could be used for the identification of the flows. 
(Yes, this method uses more than just IP layer header information. 
Perhaps calling MPT as "Network Layer Multipath" solution is 
questionable. By calling MPT so, we would like to emphasize that we use 
a tunnel IP layer over which both TCP or UDP may be used.) But the 
details are missing. (E.g. how to describe the flows, how they can be 
efficiently identified, etc.)

> And when it comes to per-packet mappings, sending a percentage of 
> packets on various links and then adding delay to reorder at the MPT 
> server will add buffer bloat to match the worst link.

Our experience shows that it is worth aggregating only the capacity of 
the links with similar speeds and delay. Otherwise it is worth sending 
the traffic through the better link and use the other link as "spinning 
reserve" for resiliency purposes, if the better link fails.

> I may be missing something, but after reading the draft I think this 
> proposal will be harmful to users as it exclusively focuses on 
> throughput at the expense of many other priorities.
> While it's commonly assumed we can solve any problem by introducing an 
> extra level of indirection or IP headers, I don't think tunnels are 
> the solution to all woes.
>
> [1] http://www.stuartcheshire.org/rants/latency.html
>
> Thanks,
> David Schinazi
>

Whereas I try to "defend" our draft, and I hope that our conversation 
will result in a better draft, which will be useful for many people, I 
also admit, that there may be fundamental flaws in our concept, which we 
do not see. I honestly thank you for pointing them out in the past and 
in the future, too. And if the final outcome will be that we shell 
abandon the draft, I will still be grateful to you for saving us 
possibly years spent with something unusable.

So, I really appreciate your reply and wait for further comments from 
you and from anyone else interested in our draft.

Best regards,

Gabor

>
>> On Jul 25, 2017, at 08:59, Gabor Lencse <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Dear INTAREA WG members,
>>
>> I am Gabor Lencse, the first author of a "-00" draft about the MPT 
>> Network Layer Multipath Library: 
>> https://tools.ietf.org/html/draft-lencse-tsvwg-mpt-00
>>
>> It was introduced to the INTAREA WG by our co-author Marius Georgescu 
>> at IETF 99.
>>
>> I would like to elaborate on the feedback we received during the 
>> presentation.
>>
>> Q1 (David, from Apple): What is the motivation, what you are trying 
>> to solve? Why are you trying to use multiple interfaces?
>>
>> A1: Throughput aggregation between two sites. (E.g. between data centers)
>>
>> My answer:
>>
>> The problem to  be solved is the following. Due to the design of the 
>> TCP/IP protocol stack and its socket interface, even if a device has 
>> multiple network interfaces, only one of them can be used for a 
>> communications session. And it is a serious limitation many times!
>>
>> Example: Somebody is remotely participating at an IETF meeting using 
>> Meetecho on his laptop using WiFi connection (to save costs). When he 
>> receives permission to ask a question, the WiFi connection brakes. By 
>> the time he manages to switch over to LTE, it is too late.  -- 
>> According to our tests, MPT can do the switchover seamlessly.
>>
>> How common is this situation? I think many people have smartphones, 
>> with WiFi and LTE, and uses WiFi when available in order to save 
>> costs. Many of them use free video calls (e.g. by Skype, Viber, 
>> WhatsApp, etc.) and would be happy if the free WiFi could be backed 
>> up by seamless switchover to LTE during the calls.
>>
>> There are a number of multi path solutions, which shows that the 
>> problem is real, but I contend that MPT differs from them and MPT can 
>> be more suitable for certain purposes than they for different reasons:
>>
>> - MPTCP [RFC6824] is good, but it is "built together" with TCP. Some 
>> applications, e.g. DNS resolution or RTP use UDP. (They can work well 
>> with MPT.)
>>
>> -  Huawei's GRE Tunnel Bonding Protocol [RFC8157] was designed for 
>> this very purpose, but it uses GRE, which is filtered out in many 
>> networks. (MPT uses GRE-in-UDP, thus MPT behaves as a standard UDP 
>> application in the carrier networks.)
>>
>> - BANANA 
>> https://tools.ietf.org/html/draft-leymann-banana-data-encap-00 aims 
>> to do bandwidth aggregation, but it also uses GRE and not GRE-in-UDP. 
>> And I am not sure if it is able to provide a resilient tunnel (that 
>> is switching over from a given underlying path to another one).
>>
>> - Load Sharing for SCTP 
>> https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-14 is 
>> also a multipath solution, but it is very specific. MPT provides an 
>> IP tunnel, which can be used for any purpose.
>>
>> All in all, I could not find any other solutions that would provide 
>> such flexible, multipurpose IP tunnel (providing both IPv4 and IPv6), 
>> which is both resilient and can aggregate the transmission capacity 
>> of several (even high number of) underlying paths, and which can be 
>> used in any networks, where UDP is carried over either IPv4 or IPv6. 
>> I would be interested in hearing about any similar solutions.
>>
>> And I would like to receive your feedback about MPT. All your 
>> questions, comments, suggestions, etc.
>>
>> Best regards,
>>
>> Gabor
>>
>>
>> _______________________________________________
>> Int-area mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/int-area
>