Subject: Re: [Banana] mix up the tunnel based and the MPTCP-proxy based?//RE: Slides

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Mon, 1 Aug 2016 19:15:59 +0000

On 01/08/16 08:50, "Banana on behalf of Mingui Zhang" <[email-masked] on behalf of [email-masked]> wrote:

>Hi,
>
>> -----Original Message-----
>> From: Henderickx, Wim (Nokia - BE) [mailto:[email-masked]]
>> Sent: Saturday, July 30, 2016 3:15 AM
>> To: Mingui Zhang; [email-masked]; Olivier Bonaventure; Sri Gundavelli
>> (sgundave)
>> Cc: SungHoon Seo; [email-masked]; Michael Menth
>> Subject: Re: [Banana] Slides
>> 
>> If you loose a packet an retransmit you have to buffer at the HAG as will and you
>> end up with state, so lets put all the items on the table.
>
>[Mingui] At least, we should not bother with retransmitting a UDP packet.

WH> it should be a customer policy to decide what people expect
> 
>
>> With MPTCP we have the
>> ability to hold back the server rather than being overloaded and getting out of
>> buffers. This is a huge advantage
>
>[Mingui] To me, MPTCP proxies seem like accelerators we could employ for a TCP session (plus a load balancer among TCP sessions :)). I do not doubt its effect. We are talking about its scalability. Besides the scalability issue, let's touch another issue: how to glue different parts of the Hybrid Access arch together? Let us think about the way to make the tunnel techniques handle the non-TCP traffic while let MPTCP proxy handle TCP traffic.

WH> some people’s perspective don’t line up with yours it seems
> 
>
>Thanks,
>Mingui
>
>
>
>> 
>> 
>> 
>> 
>> On 29/07/16 08:29, "Mingui Zhang" <[email-masked]> wrote:
>> 
>> >Hi Pierrick,
>> >
>> >Compared to traditional networks, the additional work (packet reordering) of
>> the updated GRE based implementation takes place at the egress. Due to the
>> disparity of uploading and downloading speed, HAG as the egress just needs to
>> handle the uploading traffic with a relatively much lower speed. The scalability is
>> fine.
>> >
>> >When MPTCP proxy is to be implemented, the HAG as the ingress for the
>> downloading traffic needs to put on a considerable amount of overhead as well.
>> That time, the scalability becomes an issue. That's why I thought it's difficult to
>> make service cards on the high-end router implement the MPTCP stack.
>> >
>> >Thanks,
>> >Mingui
>> >
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:[email-masked]]
>> >> Sent: Thursday, July 28, 2016 5:52 PM
>> >> To: Olivier Bonaventure; Mingui Zhang; Sri Gundavelli (sgundave)
>> >> Cc: SungHoon Seo; Henderickx, Wim (Nokia - BE); [email-masked];
>> >> Michael Menth
>> >> Subject: RE: [Banana] Slides
>> >>
>> >>
>> >>
>> >> > -----Message d'origine-----
>> >> > De : Olivier Bonaventure [mailto:[email-masked]]
>> >> > Envoyé : jeudi 28 juillet 2016 11:20 À : Mingui Zhang; Sri
>> >> > Gundavelli (sgundave) Cc : SungHoon Seo; SEITE Pierrick IMT/OLN;
>> >> > Henderickx, Wim (Nokia - BE); [email-masked]; Michael Menth Objet
>> >> > : Re: [Banana] Slides
>> >> >
>> >> > Hello,
>> >> > >
>> >> > > Sri - We were talking about the scalability issue. At least, we
>> >> > > agreed Network
>> >> > Processors will not take on the MPTCP function. As for the way to
>> >> > use service cards, I would say MPTCP proxy is different from the
>> >> > crypto function since it also consumes a considerable amount of
>> >> > memory. It would be helpful if any MPTCP implementer can quantify
>> >> > the requirements (memory & CPU cost, number of such
>> >> > cards) assuming certain service card type is used for the scale of
>> >> > tens of thousands of sessions. Then we can judge carefully.
>> >> > >
>> >>
>> >> I'm not sure that such analysis can do better than
>> >> guesstimate...Anyway... I guess you have such analysis for the
>> >> "updated-GRE" based implementation, right? If yes, do not hesitate to share.
>> >>
>> >> > > Besides the capabilities promised by MPTCP proxy, let's pay
>> >> > > attention to other
>> >> > parts of the Hybrid Access architecture. Some of them are INT-area
>> >> > issues rather than TSV-area issues. We can analyze whether they
>> >> > should be implemented by the NP or service cards or standalone boxes.
>> >> > >
>> >> > > I have a confusion about the plain-mode MPTCP proxy. Olivier told
>> >> > > me the
>> >> > transparent-mode does not suffer from TCP-over-TCP issue. Then what
>> >> > about the plain-mode? From the text of the plain-mode draft, I can
>> >> > see the user's TCP session is converted into a MPTCP session rather
>> >> > than
>> >> terminated.
>> >> >
>> >> > I don't expect that it would be possible to efficiently implement
>> >> > the plain-mode option and support all the issues with
>> >> > retransmission without terminating TCP connections on the proxies.
>> >> > For me, both plain-mode and transparent mode rely on TCP proxies
>> >> > that terminate TCP connections. A naive implementation might try to
>> >> > rewrite TCP packets without terminating the connections, but it
>> >> > would have problems to support all
>> >> the recovery mechanisms that exist in TCP correctly.
>> >> >
>> >> > > If the TCP-over-TCP issue exists, will retransmission function of
>> >> > > the MPTCP
>> >> > stack be waived from the MPTCP proxy?
>> >> >
>> >> > The TCP over TCP issues does not exist since connections are terminated.
>> >> > The MPTCP retransmission mechanisms are required to cope with
>> >> > congestion and failures on the DSL/LTE links
>> >> >
>> >> > > Since a compact function set would also facilitate network-based
>> >> > implementations.
>> >> >
>> >> > I don't expect that an implementation that relies only on packet
>> >> > rewriting would work
>> >> >
>> >> >
>> >> > Olivier
>> >> >
>> >> >
>> >> > --
>> >> >
>> >> > ------------------------------
>> >> > DISCLAIMER.
>> >> > This email and any files transmitted with it are confidential and
>> >> > intended solely for the use of the individual or entity to whom
>> >> > they are
>> >> addressed.
>> >> > If you have received this email in error please notify the system manager.
>> >> > This message contains confidential information and is intended only
>> >> > for the individual named. If you are not the named addressee you
>> >> > should not disseminate, distribute or copy this e-mail. Please
>> >> > notify the sender immediately by e-mail if you have received this
>> >> > e-mail by mistake and delete this e-mail from your system. If you
>> >> > are not the intended recipient you are notified that disclosing,
>> >> > copying, distributing or taking any action in reliance on the
>> >> > contents of this information is strictly prohibited.
>> >>
>> >>
>> _____________________________________________________________
>> >>
>> ____________________________________________________________
>> >>
>> >> Ce message et ses pieces jointes peuvent contenir des informations
>> >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> >> exploites ou copies sans autorisation. Si vous avez recu ce message
>> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>> >> que les pieces jointes. Les messages electroniques etant susceptibles
>> >> d'alteration, Orange decline toute responsabilite si ce message a ete altere,
>> deforme ou falsifie. Merci.
>> >>
>> >> This message and its attachments may contain confidential or
>> >> privileged information that may be protected by law; they should not
>> >> be distributed, used or copied without authorisation.
>> >> If you have received this email in error, please notify the sender
>> >> and delete this message and its attachments.
>> >> As emails may be altered, Orange is not liable for messages that have
>> >> been modified, changed or falsified.
>> >> Thank you.
>> >
>_______________________________________________
>Banana mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/banana

---

From: <[email-masked]>
Date: Wed, 3 Aug 2016 07:47:57 +0000

Hi Mingui,

<snip>
Let
> us think about the way to make the tunnel techniques handle the non-TCP traffic
> while let MPTCP proxy handle TCP traffic.
> 
> Thanks,
> Mingui
> 
> 
</snip>

For sure, you can do that, but it's an (your) implementation choice, you don't need standardization, i.e. specific protocol, to set up tunnels and configuring routing policy...

Pierrick

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 4 Aug 2016 03:41:48 +0000

Hi Pierrick,

> For sure, you can do that, but it's an (your) implementation choice, you don't
> need standardization, i.e. specific protocol, to set up tunnels and configuring
> routing policy...

I respectfully disagree. Those tunnels are not individual tunnels, they are bonded, they do intersect. Think about the reordering function and the multiplexing/demultiplexing of heterogeneous links. Not to mention the setup/measurement/removal of the bonded tunnels.

Assume the tunnel based and proxy based are mixed up. Can we leverage the control messages to exchange any option of MPTCP? If a certain field is required in data packets, shall we extend the tunnel header? Do we want to let non-TCP traffic or control messages to carry the ACK for MPTCP? All of these issues are standardization related.

Thanks,
Mingui

> Sent: Wednesday, August 03, 2016 3:48 PM
> To: Mingui Zhang; Henderickx, Wim (Nokia - BE); Olivier Bonaventure; Sri
> Gundavelli (sgundave)
> Subject: RE: mix up the tunnel based and the MPTCP-proxy based?//RE: [Banana]
> Slides
> 
> Hi Mingui,
> 
> 
> 
> <snip>
> Let
> > us think about the way to make the tunnel techniques handle the
> > non-TCP traffic while let MPTCP proxy handle TCP traffic.
> >
> > Thanks,
> > Mingui
> >
> >
> </snip>
> 
> For sure, you can do that, but it's an (your) implementation choice, you don't
> need standardization, i.e. specific protocol, to set up tunnels and configuring
> routing policy...
> 
> Pierrick
> 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 4 Aug 2016 03:57:27 +0000

Mingui, 

On 8/3/16, 8:41 PM, "Mingui Zhang" <[email-masked]> wrote:

>I respectfully disagree. Those tunnels are not individual tunnels, they
>are bonded, they do intersect. Think about the reordering function and
>the multiplexing/demultiplexing of heterogeneous links. Not to mention
>the setup/measurement/removal of the bonded tunnels.
>
>Assume the tunnel based and proxy based are mixed up. Can we leverage the
>control messages to exchange any option of MPTCP? If a certain field is
>required in data packets, shall we extend the tunnel header? Do we want
>to let non-TCP traffic or control messages to carry the ACK for MPTCP?
>All of these issues are standardization related.

Its not clear to me what you want to standardize? Reordering function,
packet distribution logic or path measurement techniques are different
tools in the solution deck. A hybrid access solution can use any of these
approaches based on configuration. Taking path measurements alone, I can
use RSSI/SNR or other radio specific parameters for L2 path and other
techniques for L3 paths. I do not think a standards spec is helping me
here.

Sri 

>>exploites ou
>> If you have received this email in error, please notify the sender and
>>delete this
>> message and its attachments.

---

From: <[email-masked]>
Date: Thu, 4 Aug 2016 08:26:27 +0000

Hi,

> De : Sri Gundavelli (sgundave) [mailto:[email-masked]]
> Envoyé : jeudi 4 août 2016 05:57
> À : Mingui Zhang; SEITE Pierrick IMT/OLN; Henderickx, Wim (Nokia - BE); Olivier
> Bonaventure
> Cc : SungHoon Seo; [email-masked]; Michael Menth
> Objet : Re: mix up the tunnel based and the MPTCP-proxy based?//RE: [Banana]
> Slides
> 
> Mingui,
> 
> >> For sure, you can do that, but it's an (your) implementation choice,
> >>you don't  need standardization, i.e. specific protocol, to set up
> >>tunnels and configuring  routing policy...
> >
> >are bonded, they do intersect.Think about the reordering function and
> >the multiplexing/demultiplexing of heterogeneous links. 

Actually, all these operations are supported by  the bonding module, which leaves the tunnel individuals.... Here, the Linux bonding driver is a good reference IMHO

Not to mention
> >the setup/measurement/removal of the bonded tunnels.

Well, tunnel management solutions already exist ... this is actually the basic of the IP mobility protocols.

> >Assume the tunnel based and proxy based are mixed up. Can we leverage
> >the control messages to exchange any option of MPTCP? If a certain
> >field is required in data packets, shall we extend the tunnel header?
> >Do we want to let non-TCP traffic or control messages to carry the ACK for
> MPTCP?

No sure to understand ... what you call MPTCP ACK are TCP SYN ACK/ACK...
> 
> Its not clear to me what you want to standardize? Reordering function, packet
> distribution logic or path measurement techniques are different tools in the solution
> deck. A hybrid access solution can use any of these approaches based on
> configuration. Taking path measurements alone, I can use RSSI/SNR or other radio
> specific parameters for L2 path and other techniques for L3 paths. I do not think a
> standards spec is helping me here.
> 
> 

100% inline with Sri.

> >> To: Mingui Zhang; Henderickx, Wim (Nokia - BE); Olivier Bonaventure;
> >>Sri  Gundavelli (sgundave)
> >> For sure, you can do that, but it's an (your) implementation choice,
> >>you don't  need standardization, i.e. specific protocol, to set up
> >>tunnels and configuring  routing policy...
> >>
> >> Pierrick
> >>
> >>que les pieces jointes.
> >>Les messages