Subject: [Banana] Slides from BANANA Meeting @ IETF95

From: <[email-masked]>
Date: Wed, 20 Jul 2016 14:46:39 +0000

Hi,

Please find attached the slides I presented during the BANANA meeting at IETF95 (Buenos Aires). The deck covers our (real world) deployment as well as the solution and the reasons for choosing this solution.

best regards

Nic

---

From: Michael Menth <[email-masked]>
Date: Thu, 21 Jul 2016 20:15:57 +0200

Hi,

please find attached my slides.

Best wishes,

Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Fri, 22 Jul 2016 04:20:24 +0000

Attached the slides on MP-TCP

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 26 Jul 2016 02:42:36 +0000

Hi Wim,

In slide # 6, we can see the HAG needs to support MPTCP stack. So, whether are Network Processors required to implement the MPTCP stack? If not, how does the NP of the HAG participate in forwarding MPTCP packets? The proposal is named as network assisted MPTCP. I guess it would be different from simply moving a MPTCP-enabled host from the edge into the core? 

Thanks,
Mingui

> -----Original Message-----
> From: Banana [mailto:[email-masked]] On Behalf Of Henderickx, Wim
> (Nokia - BE)
> Sent: Friday, July 22, 2016 12:20 PM
> To: Michael Menth; [email-masked]
> Subject: Re: [Banana] Slides
> 
> On 21/07/16 20:15, "Banana on behalf of Michael Menth"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> >
> >Hi,
> >

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Tue, 26 Jul 2016 04:02:54 +0000

There are several implementations x86, NP, etc. The implementation is a proxy as defined which has some additional aspects to deal with from a normal host MPTCP, but this is the reason to do this work

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 26 Jul 2016 07:48:26 +0000

Since HAG is a position deep in the core of the operator's network. Any add-on function should be treated very carefully since the same node needs to handle a huge volume of traffic which also includes non-Hybrid Access traffic. I have no doubt some light-weight additional aspects could be developed, I concern how the MPTCP stack itself is going to be implemented. 

Thanks,
Mingui

> From: Henderickx, Wim (Nokia - BE) [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2016 12:03 PM
> To: Mingui Zhang; Michael Menth; [email-masked]
> There are several implementations x86, NP, etc. The implementation is a proxy as
> defined which has some additional aspects to deal with from a normal host
> MPTCP, but this is the reason to do this work
> 
> 
> 
> 
> >In slide # 6, we can see the HAG needs to support MPTCP stack. So, whether
> are Network Processors required to implement the MPTCP stack? If not, how
> does the NP of the HAG participate in forwarding MPTCP packets? The proposal
> is named as network assisted MPTCP. I guess it would be different from simply
> moving a MPTCP-enabled host from the edge into the core?
> >
> >Thanks,
> >Mingui
> >
> >> From: Banana [mailto:[email-masked]] On Behalf Of
> >> Henderickx, Wim (Nokia - BE)

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 26 Jul 2016 09:54:46 +0200

Hello,

> Since HAG is a position deep in the core of the operator's network. Any add-on function should be treated very carefully since the same node needs to handle a huge volume of traffic which also incl…

The paper referenced below describes one implementation of an MPTCP/TCP 
proxy that is similar to the plain-mode draft

http://inl.info.ucl.ac.be/publications/multipath-middlebox

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.

---

From: <[email-masked]>
Date: Tue, 26 Jul 2016 07:59:19 +0000

Hi Mingui,

I do not get your concern, MPTCP stack (actually MPTCP option) is already implemented and available on Linux. Actually, the HAG is only require to support MPTCP option. Hybrid access does not require specific forwarding operation. If the HAG is "on the path", packets are natively routed via the HAG (a.k.a. transparent mode) and you don't need to rely on additional mechanism.

If operator's routing plan does not allow transparent mode, you need to "force" traffic via the HAG. You can use either:

-  SOCKS proxy
- enable tunnels between HCPE and HAG
- the plain mode option

Using Linux (which TCP stack is now updated with MPTCP option) and one the two first method, you can easily configured a Linux based hybrid access system... without any specific development... i.e. using MPTCP and SOCKS/tunnels are orthogonal problems, no link is required between these mechanisms.

Pierrick

> -----Message d'origine-----
> De : Banana [mailto:[email-masked]] De la part de Mingui Zhang
> Envoyé : mardi 26 juillet 2016 09:48
> À : Henderickx, Wim (Nokia - BE); Michael Menth; [email-masked]
> Objet : Re: [Banana] Slides
> 
> Since HAG is a position deep in the core of the operator's network. Any add-on
> function should be treated very carefully since the same node needs to handle a
> huge volume of traffic which also includes non-Hybrid Access traffic. I have no
> doubt some light-weight additional aspects could be developed, I concern how the
> MPTCP stack itself is going to be implemented.
> 
> Thanks,
> Mingui
> 
> > There are several implementations x86, NP, etc. The implementation is
> > a proxy as defined which has some additional aspects to deal with from
> > a normal host MPTCP, but this is the reason to do this work
> >
> >
> >
> >
> > are Network Processors required to implement the MPTCP stack? If not,
> > how does the NP of the HAG participate in forwarding MPTCP packets?
> > The proposal is named as network assisted MPTCP. I guess it would be
> > different from simply moving a MPTCP-enabled host from the edge into the
> core?
> > >
> > >Thanks,
> > >Mingui
> > >
> _______________________________________________
> Banana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/banana

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Tue, 26 Jul 2016 08:00:42 +0000

Hi Mingui, 

Please see inline.

Cheers,
Med

> Since HAG is a position deep in the core of the operator's network. Any
> add-on function should be treated very carefully since the same node needs
> to handle a huge volume of traffic which also includes non-Hybrid Access
> traffic. 

[Med] This observation applies for any aggregation proposal. Note, the explicit provisioning of MPTCP concentrators allow to select the traffic that will be intercepted by a concentrator...which can be on-path or off-path. The location of the concentrator is deployment-specific.  

I have no doubt some light-weight additional aspects could be
> developed, I concern how the MPTCP stack itself is going to be
> implemented.

[Med] There are some optimization features that can be considered for the aggregation case (e.g., disable checksum). Those features are implementation- and deployment-specific. 

> how

---

From: SungHoon Seo <[email-masked]>
Date: Tue, 26 Jul 2016 08:39:30 +0000

Hi~ Mingui,

In addition to Pierrick's opinion:

In case that mobile operator's routing plan doesn't allow transparent mode, i.e., on-path deployment model, SOCKS proxy deployment model works quite well as an off-path way but it brings a certain burden on initial session establishment stage. Furthermore, tunneling between HCP and HAG model occurs capsulation overhead which degrades aggregation throughput.

Korea Telecom lunched commercial LTE and WiFi aggregation service, called "GiGA LTE" from June 2015, which is based on the SOCKS proxy implementation. In order to diminish initial session latency, we have been investigated how to enhance the feature, and found the plain-mode option is the best way to use mptcp protocol as a sole aggregation protocol without out-of-band singling (e.g. SOCKS and/or L2/L3 tunneling). It also gives a benefit to operators, device and handset vendors as well since implementation complexity is less than the other two options.

Regards,
SungHoon

--
SungHoon Seo, Ph.D.
Institute of Convergence Technology
Korea Telecom

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, July 26, 2016 4:59 PM
To: Mingui Zhang; Henderickx, Wim (Nokia - BE); Michael Menth; [email-masked]
Subject: Re: [Banana] Slides

Hi Mingui,

-  SOCKS proxy

Pierrick

> De : Banana [mailto:[email-masked]] De la part de Mingui
> Zhang Envoyé : mardi 26 juillet 2016 09:48 À : Henderickx, Wim (Nokia
> - BE); Michael Menth; [email-masked] Objet : Re: [Banana] Slides
>
> Since HAG is a position deep in the core of the operator's network.
> Any add-on function should be treated very carefully since the same
> node needs to handle a huge volume of traffic which also includes
> non-Hybrid Access traffic. I have no doubt some light-weight
> additional aspects could be developed, I concern how the MPTCP stack itself is going to be implemented.
>
> Thanks,
> Mingui
>
> > There are several implementations x86, NP, etc. The implementation
> > is a proxy as defined which has some additional aspects to deal with
> > from a normal host MPTCP, but this is the reason to do this work
> >
> >
> >
> >
> > are Network Processors required to implement the MPTCP stack? If
> > not, how does the NP of the HAG participate in forwarding MPTCP packets?

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.

이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately.

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 27 Jul 2016 09:08:59 +0000

Hi SungHoon, Pierrick,

I know MPTCP is good at flow & congestion control and it would be nice if we can make use of it. But flow & congestion control is not the whole story. Before the MPTCP stack can be executed upon L4 packets, the HAG needs to do packet _decapsulation_ in order to get the L4 packets. After the MPTCP functions were executed, the HAG needs to do packet _encapsulation_ again since the HAG is the proxy rather than the destination. In order to realize Hybrid Access, several other enabling functions (encapsulation/decapsulation/demultiplexing/forwarding, etc) are also needed. I am afraid a box with these functions and which has to handle tens of thousands of users can only be a high-end router. I don't think the flow & congestion control mechanism which used to be an end-system function can be implemented by this high-end router.

You mentioned "you need to "force" traffic via the HAG ". Thanks for the clarification. It seems viable to place another box with MPTCP stack along with this high-end router to handle the hybrid access traffic for the sake of flow&congestion control.
 
Thanks,
Mingui

> From: SungHoon Seo [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2016 4:40 PM
> To: Mingui Zhang
> Cc: [email-masked]; Henderickx, Wim (Nokia - BE); Michael Menth;
> [email-masked]
> Subject: RE: [Banana] Slides
> 
> Hi~ Mingui,
> 
> In case that mobile operator's routing plan doesn't allow transparent mode, i.e.,
> on-path deployment model, SOCKS proxy deployment model works quite well as
> an off-path way but it brings a certain burden on initial session establishment
> stage. Furthermore, tunneling between HCP and HAG model occurs capsulation
> overhead which degrades aggregation throughput.
> 
> Korea Telecom lunched commercial LTE and WiFi aggregation service, called
> "GiGA LTE" from June 2015, which is based on the SOCKS proxy implementation.
> In order to diminish initial session latency, we have been investigated how to
> enhance the feature, and found the plain-mode option is the best way to use
> mptcp protocol as a sole aggregation protocol without out-of-band singling (e.g.
> SOCKS and/or L2/L3 tunneling). It also gives a benefit to operators, device and
> handset vendors as well since implementation complexity is less than the other
> two options.
> 
> Regards,
> SungHoon
> 
> 
> --
> SungHoon Seo, Ph.D.
> [email-masked]
> I do not get your concern, MPTCP stack (actually MPTCP option) is already
> implemented and available on Linux. Actually, the HAG is only require to support
> MPTCP option. Hybrid access does not require specific forwarding operation. If
> the HAG is "on the path", packets are natively routed via the HAG (a.k.a.
> transparent mode) and you don't need to rely on additional mechanism.
> 
> Using Linux (which TCP stack is now updated with MPTCP option) and one the
> two first method, you can easily configured a Linux based hybrid access system...
> without any specific development... i.e. using MPTCP and SOCKS/tunnels are
> orthogonal problems, no link is required between these mechanisms.
> 
> 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.
> 이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나
> 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에
> 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사
> 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된
> 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기
> 바랍니다.
> This E-mail may contain confidential information and/or copyright material. This
> email is intended for the use of the addressee only. If you receive this email by
> mistake, please either delete it without reproducing, distributing or retaining
> copies thereof or notify the sender immediately.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 27 Jul 2016 18:46:03 +0000

Mingui - I dont understand the technical issue here? If the requirement is for certain functional capability (say, MPTCP Proxy), operating on a user plane traffic and on "tens of thousands" of sessions, then may be it may be hosted on a high-end router that can handle such flows. Note that functions such as DPI is supported on these boxes and this is just another requirement with a different scale implications. We cannot say such functions requiring flow control cannot be implemented on a high-end router. This cannot be more CPU intensive than a crpyto function; May be the router has a service card, or is designed to handle that function.

Sri

Sent from my iPad

> On Jul 27, 2016, at 2:09 AM, Mingui Zhang <[email-masked]> wrote:
> 
> Hi SungHoon, Pierrick,
>

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Wed, 27 Jul 2016 18:57:20 +0000

I agree with you Sri. This has been implemented in routers, server, etc.

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 28 Jul 2016 09:06:29 +0000

Hi, 

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.

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. If the TCP-over-TCP issue exists, will retransmission function of the MPTCP stack be waived from the MPTCP proxy? Since a compact function set would also facilitate network-based implementations.

Thanks,
Mingui

> From: Banana [mailto:[email-masked]] On Behalf Of Sri Gundavelli
> (sgundave)
> Sent: Thursday, July 28, 2016 2:46 AM
> To: Mingui Zhang
> Cc: SungHoon Seo; [email-masked]; Henderickx, Wim (Nokia - BE);
> [email-masked]; Michael Menth
> Mingui - I dont understand the technical issue here? If the requirement is for
> certain functional capability (say, MPTCP Proxy), operating on a user plane traffic
> and on "tens of thousands" of sessions, then may be it may be hosted on a
> high-end router that can handle such flows. Note that functions such as DPI is
> supported on these boxes and this is just another requirement with a different
> scale implications. We cannot say such functions requiring flow control cannot be
> implemented on a high-end router. This cannot be more CPU intensive than a
> crpyto function; May be the router has a service card, or is designed to handle
> that function.
> 
> Sri
> 
> 
> Sent from my iPad
> 
> > I know MPTCP is good at flow & congestion control and it would be nice if we
> can make use of it. But flow & congestion control is not the whole story. Before
> the MPTCP stack can be executed upon L4 packets, the HAG needs to do packet
> _decapsulation_ in order to get the L4 packets. After the MPTCP functions were
> executed, the HAG needs to do packet _encapsulation_ again since the HAG is
> the proxy rather than the destination. In order to realize Hybrid Access, several
> other enabling functions
> (encapsulation/decapsulation/demultiplexing/forwarding, etc) are also needed. I
> am afraid a box with these functions and which has to handle tens of thousands
> of users can only be a high-end router. I don't think the flow & congestion control
> mechanism which used to be an end-system function can be implemented by
> this high-end router.
> >
> > You mentioned "you need to "force" traffic via the HAG ". Thanks for the
> clarification. It seems viable to place another box with MPTCP stack along with
> this high-end router to handle the hybrid access traffic for the sake of
> flow&congestion control.
> >
> > Thanks,
> > Mingui
> >
> >> Cc: [email-masked]; Henderickx, Wim (Nokia - BE); Michael
> >> Menth; [email-masked]
> >> In case that mobile operator's routing plan doesn't allow transparent
> >> mode, i.e., on-path deployment model, SOCKS proxy deployment model
> >> works quite well as an off-path way but it brings a certain burden on
> >> initial session establishment stage. Furthermore, tunneling between
> >> HCP and HAG model occurs capsulation overhead which degrades aggregation
> throughput.
> >>
> >> Korea Telecom lunched commercial LTE and WiFi aggregation service,
> >> called "GiGA LTE" from June 2015, which is based on the SOCKS proxy
> implementation.
> >> In order to diminish initial session latency, we have been
> >> investigated how to enhance the feature, and found the plain-mode
> >> option is the best way to use mptcp protocol as a sole aggregation protocol
> without out-of-band singling (e.g.
> >> SOCKS and/or L2/L3 tunneling). It also gives a benefit to operators,
> >> device and handset vendors as well since implementation complexity is
> >> less than the other two options.
> >>
> >> Regards,
> >> SungHoon
> >>
> >>
> >> --
> >> SungHoon Seo, Ph.D.
> >> I do not get your concern, MPTCP stack (actually MPTCP option) is
> >> already implemented and available on Linux. Actually, the HAG is only
> >> require to support MPTCP option. Hybrid access does not require
> >> specific forwarding operation. If the HAG is "on the path", packets are natively
> routed via the HAG (a.k.a.
> >> If operator's routing plan does not allow transparent mode, you need to
> "force"
> >> traffic via the HAG. You can use either:
> >>
> >> -  SOCKS proxy
> >> Using Linux (which TCP stack is now updated with MPTCP option) and
> >> one the two first method, you can easily configured a Linux based hybrid
> access system...
> >> without any specific development... i.e. using MPTCP and
> >> SOCKS/tunnels are orthogonal problems, no link is required between these
> mechanisms.
> >>
> >> Pierrick
> >>
> >>
> >>
> >>> additional aspects could be developed, I concern how the MPTCP stack
> >>> itself is
> >> going to be implemented.
> >>>
> >>> Thanks,
> >>> Mingui
> >>>
> >>>> is a proxy as defined which has some additional aspects to deal
> >>>> with from a normal host MPTCP, but this is the reason to do this
> >>>> work
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> The proposal is named as network assisted MPTCP. I guess it would
> >>>> be different from simply moving a MPTCP-enabled host from the edge
> >>>> into the
> >>> core?
> >>>>>
> >>>>> Thanks,
> >>>>> Mingui
> >>>>>
> >> 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.
> 포함된 정보의 전부 또는 일부를 무단으로 제3자에게
> >> 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본
> 메일이 잘못 전송된 경우, 발신인 또는 당사에
> >> 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
> >> This E-mail may contain confidential information and/or copyright
> >> material. This email is intended for the use of the addressee only.
> >> If you receive this email by mistake, please either delete it without
> >> reproducing, distributing or retaining copies thereof or notify the sender
> immediately.

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 28 Jul 2016 11:20:07 +0200

Hello,
> 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

--

---

From: <[email-masked]>
Date: Thu, 28 Jul 2016 09:51:52 +0000

> 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);
> > 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.
> 
> The MPTCP retransmission mechanisms are required to cope with congestion and
> failures on the DSL/LTE links
> 
> I don't expect that an implementation that relies only on packet rewriting would
> work
> 
> 
> Olivier
> 
> 
> --
>

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 29 Jul 2016 06:29:51 +0000

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

> 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
> > À : 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,
> > >
> > 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.
> 
> > 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.
> > >
> > 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.
> >
> > 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
> > > If the TCP-over-TCP issue exists, will retransmission function of
> > > the MPTCP
> > stack be waived from the MPTCP proxy?
> >
> > The MPTCP retransmission mechanisms are required to cope with
> > congestion and failures on the DSL/LTE links
> >
> > 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.
> > 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.
>

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Fri, 29 Jul 2016 19:14:40 +0000

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. 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

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 1 Aug 2016 06:50:51 +0000

Hi,

> 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
> 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. 

> 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. 

Thanks,
Mingui

> >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
> >
> >> Cc: SungHoon Seo; Henderickx, Wim (Nokia - BE); [email-masked];
> >> Michael Menth
> >> > 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,
> >> > >
> >> > 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
> >> 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.
> >>
> >> > issues rather than TSV-area issues. We can analyze whether they
> >> > should be implemented by the NP or service cards or standalone boxes.
> >> > >
> >> > 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
> >> > 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.
> >>
> >>