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. 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. 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. 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]. 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. 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. 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 <http://www.stuartcheshire.org/rants/latency.html> Thanks, David Schinazi > On Jul 25, 2017, at 08:59, Gabor Lencse <[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] > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
