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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
