Re: [multipathtcp] towards a potential work item on two-ended proxy
Alan Ford <alan.ford@gmail.com> Sat, 06 August 2016 20:47 UTC
Return-Path: <alan.ford@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9FD12D147 for <multipathtcp@ietfa.amsl.com>; Sat, 6 Aug 2016 13:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBzWBK4FVSQE for <multipathtcp@ietfa.amsl.com>; Sat, 6 Aug 2016 13:47:47 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D50612B019 for <multipathtcp@ietf.org>; Sat, 6 Aug 2016 13:47:47 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id u134so285788563ywg.3 for <multipathtcp@ietf.org>; Sat, 06 Aug 2016 13:47:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bTr2LtEktYTygPrrWd2m7XFzHka1j27iDltFPy0nFN4=; b=QbtPiwy9erj8z1LDV2IrPUmRKzIBNLaL0buWGljvQb9GnAPA3CQpD2qa+QpDYpq16Y K6aEX/RsZnY7/DRJ2NSFYDNbMIL+3aIuErQARhz7rBauEFb2CnZ//96FJvqrYRDABoe6 aPoHihE4xlzovzlJbI6LW3YX9Le3mcXHmMDh9jjyQo/GKmb66I/pc5OIQAX5KZrWFHsF QrDU0O5RZMyb+PdBNk4khhVzT2qnGQFAbLQ2iyp2v30ysu0XB2qKF0p1zKRzTV/VjwhY uoxygHL0xC3Mm0mUEL6NTHhjNkvB3O0JBf+zkUtNZMPNmCX7eUs6rzm+ctN8N5AMi6ud dqxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bTr2LtEktYTygPrrWd2m7XFzHka1j27iDltFPy0nFN4=; b=jk9q3LcoNDeqCqA9DNsYiV+RLnx/EhBel4phbSSsvNq04OrM31iAyz65kppEkp3Z+h Ni9U5npE2Y5SZn4KqPeAbuU2R4VfgW7IXhD2BAhSPGhDu7EDQzm8PZp+rw9hHUFrvLh8 6iuKkqr8GOppjXOdBD8l7wCaRcwxBGjw6QrTnw4dI1+yLUlruBC5yGMNC7jTse83pyag XHiZEbvcDr0YUb9kIIvezq1EdBpZGLOvcVbCRP9dGNKjD+MUu0mrOAqG5mtUp+KixCDz RkaVoNx4GDvh8tWNdpQJdRKVVWFSgdt3Ou5YR0ywssZhQEqS9ZZ9wycHGZMFzACfzF1d 9OFA==
X-Gm-Message-State: AEkoouvAhjNsTdp1x8LUCilYUIUsby3ITXvLcIrt99hTiePszs1RDYm43Fx3hKEDCaiPWIrY/Z0XHaCdDzeVcQ==
X-Received: by 10.129.115.131 with SMTP id o125mr60179541ywc.99.1470516466771; Sat, 06 Aug 2016 13:47:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.166.146 with HTTP; Sat, 6 Aug 2016 13:47:45 -0700 (PDT)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E023B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net> <9cafc779-502e-cc7f-676c-f6659e207c81@uclouvain.be> <3100ff74-0c7d-1815-03a1-aa4cec36d1e4@oracle.com> <3D8D4118-39CA-46A6-BFBD-026376C02058@nokia.com> <811b2c78-0976-6994-d759-8cac5fa58864@oracle.com> <0084773F-53E5-41A4-A244-430DAF12322A@nokia.com> <E0278B51-F3D8-4762-B597-41959E7BCF12@gmail.com> <08A92759-0446-440B-A76E-2E89518E1336@nokia.com> <F9F23B1F-D802-4971-857F-4BF455EDCF5D@gmail.com> <FCC775C9-EA48-4E7D-A48D-3059C255569A@nokia.com> <4221AE86-54DA-4177-91B5-D1A03C101F71@apple.com> <F6D0E786-4CFC-44F0-8B22-1A3376D92D44@nokia.com> <49C1C516-FE48-4254-B784-9EFC0F430468@apple.com> <E1036C03-C042-4F56-8EFC-A23475BE6233@nokia.com> <2E6A891C-DF7B-4AF0-987F-642FA8D2D052@apple.com> <147FE680-0855-42BF-88BC-78EFDB6110D7@nokia.com> <787AE7BB302AE849A7480A190F8B933008E023B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Alan Ford <alan.ford@gmail.com>
Date: Sat, 06 Aug 2016 21:47:45 +0100
Message-ID: <CAOs_kTZuj+MF7_UJNCk+BL8CzqyLfS-VeaPZD5qeYPJ3cCMsKw@mail.gmail.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Content-Type: multipart/alternative; boundary="001a1149310aa36de905396d4b9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/0TrvTo-0BqW93whIQRav06qdHw0>
Cc: MultiPath TCP - IETF WG <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Aug 2016 20:47:51 -0000
Absolutely, and I'm excited to see MPTCP finding a use in this way :-) My concerns are around pragmatism too: firstly, ensuring any solution does not add complexity or introduce issues in the base MPTCP protocol where it is not required, or for what is a specialist use; and secondly, that you are not limiting functionality of your solution in the future. However, I do not think there is much point continuing this debate until we see the consolidated proxy draft (plain mode + transparent) which was discussed in Berlin - this may well make the goals of this work clearer. Regards, Alan On Friday, 5 August 2016, <mohamed.boucadair@orange.com> wrote: > Re-, > > > > Fully agree with Wim. It is all about a pragmatic solution to an > engineering problem. > > > > Cheers, > > Med > > > > *De :* multipathtcp [mailto:multipathtcp-bounces@ietf.org > <javascript:_e(%7B%7D,'cvml','multipathtcp-bounces@ietf.org');>] *De la > part de* Henderickx, Wim (Nokia - BE) > *Envoyé :* vendredi 5 août 2016 15:33 > *À :* Christoph Paasch > *Cc :* MultiPath TCP - IETF WG > *Objet :* Re: [multipathtcp] towards a potential work item on two-ended > proxy > > > > In-line > > > > *From: *Christoph Paasch <cpaasch@apple.com > <javascript:_e(%7B%7D,'cvml','cpaasch@apple.com');>> on behalf of > Christoph Paasch <cpaasch@apple.com > <javascript:_e(%7B%7D,'cvml','cpaasch@apple.com');>> > *Date: *Friday 5 August 2016 at 08:00 > *To: *Wim Henderickx <wim.henderickx@nokia.com > <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> > *Cc: *Tommy Pauly <tpauly@apple.com > <javascript:_e(%7B%7D,'cvml','tpauly@apple.com');>>, MultiPath TCP - IETF > WG <multipathtcp@ietf.org > <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>> > *Subject: *Re: [multipathtcp] towards a potential work item on two-ended > proxy > > > > Hello, > > > > inline... > > > > On Aug 4, 2016, at 9:23 PM, Henderickx, Wim (Nokia - BE) < > wim.henderickx@nokia.com > <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> wrote: > > > > In-line sorry was on the road yesterday > > > > *From: *Christoph Paasch <cpaasch@apple.com > <javascript:_e(%7B%7D,'cvml','cpaasch@apple.com');>> on behalf of > Christoph Paasch <cpaasch@apple.com > <javascript:_e(%7B%7D,'cvml','cpaasch@apple.com');>> > *Date: *Thursday 4 August 2016 at 06:32 > *To: *Wim Henderickx <wim.henderickx@nokia.com > <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> > *Cc: *Tommy Pauly <tpauly@apple.com > <javascript:_e(%7B%7D,'cvml','tpauly@apple.com');>>, MultiPath TCP - IETF > WG <multipathtcp@ietf.org > <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>> > *Subject: *Re: [multipathtcp] towards a potential work item on two-ended > proxy > > > > Hello, > > > > On Aug 3, 2016, at 9:14 PM, Henderickx, Wim (Nokia - BE) < > wim.henderickx@nokia.com > <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> wrote: > > *From: *<tpauly@apple.com > <javascript:_e(%7B%7D,'cvml','tpauly@apple.com');>> on behalf of Tommy > Pauly <tpauly@apple.com <javascript:_e(%7B%7D,'cvml','tpauly@apple.com');> > > > *Date: *Thursday 4 August 2016 at 02:10 > *To: *Wim Henderickx <wim.henderickx@nokia.com > <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> > *Cc: *Alan Ford <alan.ford@gmail.com > <javascript:_e(%7B%7D,'cvml','alan.ford@gmail.com');>>, " > multipathtcp@ietf.org > <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>" < > multipathtcp@ietf.org > <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>> > *Subject: *Re: [multipathtcp] towards a potential work item on two-ended > proxy > > > > > > On Aug 3, 2016, at 11:58 AM, Henderickx, Wim (Nokia - BE) < > wim.henderickx@nokia.com > <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> wrote: > > > > Alan, in-line > > > > *From: *Alan Ford <alan.ford@gmail.com > <javascript:_e(%7B%7D,'cvml','alan.ford@gmail.com');>> > *Date: *Wednesday 3 August 2016 at 09:20 > *To: *Wim Henderickx <wim.henderickx@nokia.com > <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> > *Cc: *Rao Shoaib <rao.shoaib@oracle.com > <javascript:_e(%7B%7D,'cvml','rao.shoaib@oracle.com');>>, " > multipathtcp@ietf.org > <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>" < > multipathtcp@ietf.org > <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>> > *Subject: *Re: [multipathtcp] towards a potential work item on two-ended > proxy > > > > Hi Wim, all, > > > > Comment inline... > > > > On 2 Aug 2016, at 20:11, Henderickx, Wim (Nokia - BE) < > wim.henderickx@nokia.com > <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> wrote: > > On 02/08/16 15:52, "Alan Ford" <alan.ford@gmail.com > <javascript:_e(%7B%7D,'cvml','alan.ford@gmail.com');>> wrote: > > > I’m trying to distinguish the various use cases; can we confirm this is > correct? > > Transparent Mode > - Source address = real source address > > WH> not always since NAT can be in the path > > - Destination address = real destination address > - Transparent proxies create MPTCP functionality in the stream, adding and > removing the MPTCP headers, mapping seq numa, etc > - Latest proposal is to add an indicator to say “this is proxied” so that > a proxy can intercept it > > WH> indeed or not intercept it based on the indication > > > Plain Mode > - Source address = real source > > WH> could also be NATed in some use cases > > - Destination address = proxy destination address > - Signalling protocol inside indicates real destination address > > WH> or SRC address > > > So - please correct me if this is wrong - but the main difference is that > Plain Mode is targeted towards a proxy server whereas the transparent mode > does not change src/dst addresses? > > WH> the main difference is mainly DST IP is changed to get explicit > routing to the proxy versus being implicit in the transparent case > > > > OK, so my understanding appears correct here. > > WH> yes > > > > The issue I see with a generic proxy bit is that it does not contain any > context about what kind of proxy is being intercepted. You could be sending > in good faith expecting it to be picked up by Proxy from Operator A, but in > fact is picked up by Operator B. > > WH> the network assisted proxy is mainly targeting single > operator/controlled operator use cases to avoid these issues. > > > As I’ve said before, the plain mode option is not MPTCP-specific and is > simple a signal that says “everything that follows is actually targeted for > IP address a.b.c.d” - this is entirely transport-agnostic. If the HAG could > know where to find a proxy (e.g. a well-known anycast address) then > addresses could be rewritten and packets forwarded, with no need for any > MPTCP protocol changes. > > WH> you would still need to know the original destination IP@ that the > application wanted to go to. > > > > Which is the point of the signalling protocol - the proposed “plain mode > option” which is actually carried in the payload. My issue with this is > that this is _not MPTCP-specific_. This is simply a signal above the > transport layer to inform a proxy what the real destination is. > > > > WH> I hear, you and I understand but we have an explicit use case for this > with MPTCP and so far not in any other protocol. Hence I think it is good > to extend MPTCP with this capability and liase with other WG(s) about this. > > > > While you may have a use-case for having proxies work with your MPTCP > solution, it does not directly follow that the MPTCP protocol or WG is the > best place to specify how the proxy works. This really does seem like a > proxy solution that can be made more generic, and at the very least belongs > as a protocol that is run within the MPTCP stream. This is what the SOCKS > protocol does, and there is no reason you can't run SOCKS over MPTCP, or > create a new variant of SOCKS or a similar protocol that you will run on > top of MPTCP for your solution. Indeed, it could be seen as a benefit to > work on the proxying solution independently from MPTCP, since that way it > can be used for other transports. The end result will be the same, and the > architecture will be cleaner. > > > > WH> given the extension is specific in TCP?MPTCP since we carry the > information in a SYN packet it becomes specific to the protocol and hence I > still believe it fits. > > > > The information is actually carried in the payload. So, it is not really > part of TCP/MPTCP. Carrying it in the SYN is just because TCP does not > prevent carrying data in the SYN-segment. > > > > WH> we added it in the payload due to limited option space available in TCP > > > > Other transport mechanisms have other means and can adopt a similar > information element but the way the protocol consumes it is specific and > should be done in the protocol afais. > > > > I disagree that the information is consumed by MPTCP. It is rather > consumed by the application sitting right on top of MPTCP, because this is > the one that is reading the data out of the MPTCP-stream and forwarding it > over to final destination. And MPTCP itself is not really using the > plain-mode option. > > > > If you look at Socks v4, it is actually carrying the exact same > information than the plain-mode option (besides the protocol-field). So, an > implementation could easily put the Socks-client request in the > SYN-payload. The proxy who receives that can then (after connecting to the > final server) reply in the SYN/ACK with the Socks-server option in the > SYN/ACK's payload. And from there on, the data will be forwarded from one > side to the other. > > > > This would be a low-overhead handshake for the proxy without the chatty > overhead of Socks v5. > > > > WH> Latency matters here and people already experienced that additional > signaling messages with its roundtrip degrades QoE. Even adding 2 message > is not the right way to go and hence we want to add the informational > elements in the messages in MPTCP. > > > > I am 100% sure that the way I described it is not adding more latency > compared to the current plain-mode option proposal. Can you please explain, > how my suggestion "degrades QoE" (compared to the plain-mode option) ? > > > > WH10> my understanding is that you propose to add an additional out of > band singling which need to negotiate the capabilities. This means extra > signaling on top of what MPTCP does, so this is where your extra latency > comes from. > > > > As such we need to enhance the information elements in TCP/MPTCP protocol > to indicate that there is some data available that needs to be consumed by > the proxy to operate properly. You need to extend the protocol to provide > this capability in my view. > > The addition of adding a sub flow in MPTCP also provides addressing > information and we need similar information for the MPTCP proxy (do the > proxy or not, src/dst info, etc). > > We carry the data in the SYN due to limited option space but we could > carry it in the option data as well. As such it becomes TCP specific and we > believe it is best to leverage on the TCP framework to extend this > capability. > > > > Wrt. to *"as such it becomes TCP specific" *: Just because one > arbitrarily puts some information in the TCP-option space does not make the > information TCP-specific by design... > > WH10> if 99% of what we need is in the MPTCP stack why should we not use > this. We have multi-path, we get congestion management, re-ordering, etc in > MPTCP and we need this for the hybrid access use case. Our goal is to > extend the capabilities on top of MPTCP since it does not of what we need. > We just need to enhance it with some capabilities specific to the hybrid > access use case and if you don’t need them you can avoid them. > > > > > > > > Let's put MPTCP aside for a moment. > > > > Basically, the network that you are targeting has some characteristics > that make a certain transport protocol more adapt for a certain leg of the > end-to-end path. So, the goal is to enable the use of a special transport > protocol over this leg of the network. > > To do so, the byte-stream that is sent by the application from the > client/server needs to be taken out of TCP and transmitted over this > special transport protocol. Thus, the TCP-connection is being terminated at > the CPE such that the byte-stream can be extracted out of TCP. This > byte-stream is then sent over the specialized transport protocol to the > concentrator on a specific port-number. The concentrator then terminates > the special transport protocol so that it can extract the byte-stream out > of it and sends the byte-stream to the final server over TCP. > > Now, as the concentrator is not always on the IP-path between CPE and > server, the CPE actually needs to use the destination IP-address of the > concentrator in the segments that are using the specialized transport > protocol. So, this is the "plain-mode" that you are addressing. To let the > concentrator send the byte-stream to the final server, the CPE needs to > tell to the concentrator which IP the server has. To do so, the CPE places > this information in the payload of the first segment that it sends to the > concentrator by using the specialized transport protocol. This is exactly > what you are doing with the plain-mode option. > > > > > > As you can see, in the above description of the hybrid access solution, > there is nothing that is specific to MPTCP and nothing specific to the use > of multiple interfaces or hybrid accesses. The sole use of the plain-mode > option is to convey to the concentrator what the IP-address of the server > is. Whether or not to do proxying is simply done by addressing the traffic > to the concentrator by using a the proxy port-number. > > > > So, standardizing this is probably useful. But should not be done as part > of MPTCP, because the plain-mode option is orthogonal to MPTCP. > > > > WH10> I get what you say but if I can re-use 99% of what is in MPTCP why > should I define a new protocol to achieve the same thing. I can add > something to the protocol to achieve the functionality, why should we not > leverage this. This is why we call this an MPTCP proxy. If people don’t > want to use it they don’t have to consume it. If people want to use the > mechanism in another protocol they can. We just want to add this capability > on top of an already existing MPTCP protocol which give us the capabilities > we need. that’s all > > > > > > Cheers, > > Christoph > > >
- Re: [multipathtcp] towards a potential work item … philip.eardley
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Alan Ford
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … philip.eardley
- Re: [multipathtcp] towards a potential work item … Alan Ford
- Re: [multipathtcp] towards a potential work item … Christoph Paasch
- Re: [multipathtcp] towards a potential work item … David Allan I
- Re: [multipathtcp] towards a potential work item … Markus.Brunner3
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Christoph Paasch
- Re: [multipathtcp] towards a potential work item … Markus.Brunner3
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Alan Ford
- Re: [multipathtcp] towards a potential work item … Markus.Brunner3
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Alan Ford
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Christoph Paasch
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Tommy Pauly
- Re: [multipathtcp] towards a potential work item … philip.eardley
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Rao Shoaib
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Ivancic, William D. (GRC-LCA0)
- Re: [multipathtcp] towards a potential work item … philip.eardley
- Re: [multipathtcp] towards a potential work item … Alan Ford
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Christoph Paasch
- Re: [multipathtcp] towards a potential work item … christian.jacquenet
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Yoshifumi Nishida
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Yoshifumi Nishida
- [multipathtcp] towards a potential work item on t… philip.eardley
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Rao Shoaib
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Rao Shoaib
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Rao Shoaib
- Re: [multipathtcp] towards a potential work item … philip.eardley
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Rao Shoaib
- Re: [multipathtcp] towards a potential work item … Olivier Bonaventure
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Olivier Bonaventure