Subject: Re: [Banana] I-D Action: draft-boucadair-mptcp-plain-mode-00.txt

From: <[email-masked]>
Date: Tue, 13 Oct 2015 15:13:00 +0000

Hi Mingui,

Thank you for sharing the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mingui Zhang [mailto:[email-masked]]
> Envoyé : jeudi 24 septembre 2015 09:32
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Cc : JACQUENET Christian IMT/OLN
> Objet : RE: I-D Action: draft-boucadair-mptcp-plain-mode-00.txt
> 
> Hi Med,
> 
> Thanks for the sharing.
> 
> The draft details the addressing issue which is definitely an important
> issue that falls in the problem space of the bonding service. In
> particular, the solution for NAT-pass-through issue is described. It
> assumes the tunneling techniques cannot support NAT-pass-through between
> the CPE and the Concentrator. This document addresses that issue. I guess
> this is the major motivation for proposing the "plain" mode. 

[Med] Yes. Other goals are get rid of the encapsulation overhead and reuse the same solution for UDP-based traffic. The plain mode allows to easily reuse service functions (e.g., DPI) that are deployed at the network side without requiring any update to those to support the encap scheme. 

Here, I would
> like to add another way to solve the same issue: the tunnel encapsulated
> packet can be wrapped with a UDP header, which forms a tunnel-over-UDP. By
> doing that, NAT-pass-through can be addressed as well.

[Med] That's another option, indeed. Beside the encapsulation overhead, there may be some side effects if intermediate functions are needed to be invoked (e.g., TCP acceleration engine). 

> 
> Traffic distribution issue is another important issue for the bonding
> service. This had ever been discussed on the list. I know MPTCP can well
> support flow based traffic distribution. However, I remember it was
> mentioned somewhere that MPTCP can be adapted to support per-packet load
> sharing among the multipaths. Will this direction be considered?

[Med] The per-packet distribution is not excluded by this draft. We do think that the load distribution logic can even be separated from the actual mechanism used to transport data over multiple paths, but I must admit this is out of scope of this draft.

> 
> A clarification questions: from Figure 1, it is clear that one peer of the
> MPTCP proxy will be deployed on the CPE. What is not clear to me is where
> the other end is to be deployed? Will the L4 capable Concentrator be
> deployed on physical routers or servers?

[Med] The concentrator can be on physical routers, dedicated servers, etc. This is really deployment-specific. 

> 
> Thanks,
> Mingui
> 
> > -----Original Message-----
> > From: Banana [mailto:[email-masked]] On Behalf Of
> > [email-masked]
> > Sent: Tuesday, September 22, 2015 3:55 PM
> > To: [email-masked]
> > Cc: JACQUENET Christian IMT/OLN
> > Subject: [Banana] TR: I-D Action: draft-boucadair-mptcp-plain-mode-
> 00.txt
> >
> > Dear all,
> >
> > We submitted this I-D to discuss a proposal that aims to get rid of the
> > encapsulation when aggregating multiple network attachments.
> >
> > Comments are more than welcome.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : I-D-Announce [mailto:[email-masked]] De la part de
> > > [email-masked] Envoyé : lundi 21 septembre 2015 15:31 À :
> > > [email-masked] Objet : I-D Action:
> > > draft-boucadair-mptcp-plain-mode-00.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > >
> > >
> > >         Title           : An MPTCP Option for Network-Assisted MPTCP
> > > Deployments: Plain Transport Mode
> > >         Authors         : Mohamed Boucadair
> > >                           Christian Jacquenet
> > > 	Filename        : draft-boucadair-mptcp-plain-mode-00.txt
> > > 	Pages           : 12
> > > 	Date            : 2015-09-21
> > >
> > > Abstract:
> > >    One of the promising deployment scenarios for Multipath TCP (MPTCP)
> > >    is to enable a Customer Premises Equipment (CPE) that is connected
> to
> > >    multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of
> its
> > >    network attachments.  Because of the lack of MPTCP support at the
> > >    server side, some service providers now consider a "network-
> assisted
> > >    mode" that relies upon the activation of a dedicated function
> called
> > >    MPTCP Concentrator.  This document focuses on a deployment scheme
> > >    where the identity of the MPTCP Concentrator(s) is explicitly
> > >    configured on connected hosts.
> > >
> > >    This document specifies an MPTCP option that is used to get rid of
> an
> > >    encapsulation scheme between the CPE and the MPTCP Concentrator.
> > >
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/
> > >
> > > There's also a htmlized version available at:
> > > https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-00
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
> > > tools.ietf.org.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > _______________________________________________
> > > I-D-Announce mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > _______________________________________________
> > Banana mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/banana

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 14 Oct 2015 08:12:04 +0000

Hi Med,

Please see my responses inline below.

Thanks,
Mingui

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, October 13, 2015 11:13 PM
> To: Mingui Zhang; [email-masked]
> Subject: RE: I-D Action: draft-boucadair-mptcp-plain-mode-00.txt
> 
> Hi Mingui,
> 
> > De : Mingui Zhang [mailto:[email-masked]] Envoyé : jeudi 24
> > septembre 2015 09:32 À : BOUCADAIR Mohamed IMT/OLN;
> [email-masked] Cc
> > : JACQUENET Christian IMT/OLN Objet : RE: I-D Action:
> > The draft details the addressing issue which is definitely an
> > important issue that falls in the problem space of the bonding
> > service. In particular, the solution for NAT-pass-through issue is
> > described. It assumes the tunneling techniques cannot support
> > NAT-pass-through between the CPE and the Concentrator. This document
> > addresses that issue. I guess this is the major motivation for proposing the
> "plain" mode.
> 
> [Med] Yes. Other goals are get rid of the encapsulation overhead and reuse the
> same solution for UDP-based traffic. The plain mode allows to easily reuse
> service functions (e.g., DPI) that are deployed at the network side without
> requiring any update to those to support the encap scheme.

[Mingui] I guess this kind of reuse is feasible given that the end systems are changed a little bit: in draft-boucadair-mptcp-dhc-01, it reads

   "This document focuses on the explicit deployment
   scheme where the identity of the MPTCP Concentrator(s) is explicitly
   configured on connected hosts."

> 
> Here, I would
> > like to add another way to solve the same issue: the tunnel
> > encapsulated packet can be wrapped with a UDP header, which forms a
> > tunnel-over-UDP. By doing that, NAT-pass-through can be addressed as well.
> 
> [Med] That's another option, indeed. Beside the encapsulation overhead, there
> may be some side effects if intermediate functions are needed to be invoked
> (e.g., TCP acceleration engine).

[Mingui] Yes, there would be some gaps. If an intermediate function becomes clearly required, it need be integrated into the overlay model.

The bonding service is sometimes regarded as a pure load-balance-among-multipaths use case so it's natural to have the idea of reusing MPTCP which is designed to handle this use case. However, I doubt the traditional load-balance-among-multipaths use case does not fully match the bonding service. MPTCP has to be adapted.

Customers of the bonding service would discriminate the heterogeneous connections. For example, the alternative connection would not be used unless the primary connection is saturated; some application types need be recognized by the bonding devices and be transported only on a primary connection; load generated by home users usually contains sparse applications types, therefore per-packet load distribution is required to achieve a fine-grained load distribution on the multiple connections. There is no flow to be managed. 

I agree the flow & congestion control functions developed in MPTCP could be reused in the bonding service architecture. The question is whether it's feasible to integrated those necessary functions _into_ the tunnel? We've already seen that the Point-to-Point Tunneling Protocol (PPTP) [RFC2637] has integrated quite some of them, right? 

> > service. This had ever been discussed on the list. I know MPTCP can
> > well support flow based traffic distribution. However, I remember it
> > was mentioned somewhere that MPTCP can be adapted to support
> > per-packet load sharing among the multipaths. Will this direction be
> considered?
> 
> [Med] The per-packet distribution is not excluded by this draft. We do think that
> the load distribution logic can even be separated from the actual mechanism
> used to transport data over multiple paths, but I must admit this is out of scope
> of this draft.

[Mingui] Thanks for the clarification. For home users, the per-packet load distribution is desired so I hope it would be covered in some other drafts. 

> 
> >
> > A clarification questions: from Figure 1, it is clear that one peer of
> > the MPTCP proxy will be deployed on the CPE. What is not clear to me
> > is where the other end is to be deployed? Will the L4 capable
> > Concentrator be deployed on physical routers or servers?
> 
> > > We submitted this I-D to discuss a proposal that aims to get rid of
> > > the encapsulation when aggregating multiple network attachments.
> > >
> > > > De : I-D-Announce [mailto:[email-masked]] De la
> > > > part de [email-masked] Envoyé : lundi 21 septembre 2015 15:31
> À :

---

From: <[email-masked]>
Date: Fri, 16 Oct 2015 06:43:40 +0000

Hi Mingui,

Please see inline.

Cheers,
Med

> De : Banana [mailto:[email-masked]] De la part de Mingui Zhang
> Envoyé : mercredi 14 octobre 2015 10:12
> Objet : Re: [Banana] I-D Action: draft-boucadair-mptcp-plain-mode-00.txt
> 
> Hi Med,
> 
> [Mingui] I guess this kind of reuse is feasible given that the end systems
> are changed a little bit: in draft-boucadair-mptcp-dhc-01, it reads
> 

[Med] Yes. 

> [Mingui] Yes, there would be some gaps. If an intermediate function
> becomes clearly required, it need be integrated into the overlay model.
> 
> The bonding service is sometimes regarded as a pure load-balance-among-
> multipaths use case so it's natural to have the idea of reusing MPTCP
> which is designed to handle this use case. However, I doubt the
> traditional load-balance-among-multipaths use case does not fully match
> the bonding service. MPTCP has to be adapted.
> 
> Customers of the bonding service would discriminate the heterogeneous
> connections. For example, the alternative connection would not be used
> unless the primary connection is saturated; some application types need be
> recognized by the bonding devices and be transported only on a primary
> connection; load generated by home users usually contains sparse
> applications types, therefore per-packet load distribution is required to
> achieve a fine-grained load distribution on the multiple connections.
> There is no flow to be managed.
> 
> I agree the flow & congestion control functions developed in MPTCP could
> be reused in the bonding service architecture. The question is whether
> it's feasible to integrated those necessary functions _into_ the tunnel?
> We've already seen that the Point-to-Point Tunneling Protocol (PPTP)
> [RFC2637] has integrated quite some of them, right?

[Med] I hear you. Several strategies to optimize the use of multiple paths can be considered in addition to the ones that were considered so far in MPTCP. This is exactly the reason why I do think there is some value in separating the load distribution logic from the actual transport mechanism. This is particularly valid for the UDP case.

> [Mingui] Thanks for the clarification. For home users, the per-packet load
> distribution is desired so I hope it would be covered in some other
> drafts.
 
[Med] I do see interest too to have those aspects discussed in an I-D.

> > [Med] The concentrator can be on physical routers, dedicated servers,
> etc. This
> > is really deployment-specific.
> >
> > >
> > > Thanks,
> > > Mingui
> > >

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 16 Oct 2015 09:28:25 +0000

Hi Med,

> [Med] I hear you. Several strategies to optimize the use of multiple paths can
> be considered in addition to the ones that were considered so far in MPTCP.
> This is exactly the reason why I do think there is some value in separating the
> load distribution logic from the actual transport mechanism. 

[Mingui] It sounds more and more interesting. That logic would be an essential part for the bonding service arch. 
I think it's worthwhile to agree on a common model where all those necessary parts (load distribution, reordering, congestion control, etc) could be integrated into one system.

>This is particularly
> valid for the UDP case.

[Mingui] I agree. The UDP case will benefit from the integrated load distribution logic extracted from the transport mechanism as well.

Thanks,
Mingui

> Sent: Friday, October 16, 2015 2:44 PM
> Subject: Re: [Banana] I-D Action: draft-boucadair-mptcp-plain-mode-00.txt
> 
> Hi Mingui,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Banana [mailto:[email-masked]] De la part de Mingui
> > Zhang Envoyé : mercredi 14 octobre 2015 10:12 À : BOUCADAIR Mohamed
> > IMT/OLN; [email-masked] Cc : JACQUENET Christian IMT/OLN Objet : Re:
> > [Banana] I-D Action: draft-boucadair-mptcp-plain-mode-00.txt
> >
> > Hi Med,
> >
> > > > De : Mingui Zhang [mailto:[email-masked]] Envoyé : jeudi
> > > > 24 septembre 2015 09:32 À : BOUCADAIR Mohamed IMT/OLN;
> > > [email-masked] Cc
> > > > NAT-pass-through between the CPE and the Concentrator. This
> > > > document addresses that issue. I guess this is the major
> > > > motivation for
> > proposing the
> > > "plain" mode.
> > >
> > [Mingui] I guess this kind of reuse is feasible given that the end
> > systems are changed a little bit: in draft-boucadair-mptcp-dhc-01, it
> > reads
> >
> > > > encapsulated packet can be wrapped with a UDP header, which forms
> > > > a tunnel-over-UDP. By doing that, NAT-pass-through can be
> > > > addressed as
> > well.
> > >
> > > [Med] That's another option, indeed. Beside the encapsulation
> > > overhead,
> > there
> > The bonding service is sometimes regarded as a pure
> > load-balance-among- multipaths use case so it's natural to have the
> > idea of reusing MPTCP which is designed to handle this use case.
> > However, I doubt the traditional load-balance-among-multipaths use
> > case does not fully match the bonding service. MPTCP has to be adapted.
> >
> > unless the primary connection is saturated; some application types
> > need be recognized by the bonding devices and be transported only on a
> > primary connection; load generated by home users usually contains
> > sparse applications types, therefore per-packet load distribution is
> > required to achieve a fine-grained load distribution on the multiple
> connections.
> > I agree the flow & congestion control functions developed in MPTCP
> > could be reused in the bonding service architecture. The question is
> > whether it's feasible to integrated those necessary functions _into_ the
> tunnel?
> [Med] I hear you. Several strategies to optimize the use of multiple paths can
> be considered in addition to the ones that were considered so far in MPTCP.
> This is exactly the reason why I do think there is some value in separating the
> load distribution logic from the actual transport mechanism. This is particularly
> valid for the UDP case.
> 
> >
> > >
> > > >
> > > > Traffic distribution issue is another important issue for the
> > > > bonding service. This had ever been discussed on the list. I know
> > > > MPTCP can well support flow based traffic distribution. However, I
> > > > remember it was mentioned somewhere that MPTCP can be adapted to
> > > > support per-packet load sharing among the multipaths. Will this
> > > > direction be
> > > considered?
> > >
> > > [Med] The per-packet distribution is not excluded by this draft. We
> > > do
> > think that
> > > used to transport data over multiple paths, but I must admit this is
> > > out
> > of scope
> > > of this draft.
> >
> > [Mingui] Thanks for the clarification. For home users, the per-packet
> > load distribution is desired so I hope it would be covered in some
> > other drafts.
> 
> > > > A clarification questions: from Figure 1, it is clear that one
> > > > peer of the MPTCP proxy will be deployed on the CPE. What is not
> > > > clear to me is where the other end is to be deployed? Will the L4
> > > > capable Concentrator be deployed on physical routers or servers?
> > >
> > > > > We submitted this I-D to discuss a proposal that aims to get rid
> > > > > of the encapsulation when aggregating multiple network attachments.
> > > > >
> > > > > > part de [email-masked] Envoyé : lundi 21 septembre
> > > > > > 2015
> > 15:31
> > > À :
> > > > > > A New Internet-Draft is available from the on-line
> > > > > > Internet-Drafts directories.
> > > > > >
> > > > > >
> > > > > >    network attachments.  Because of the lack of MPTCP support
> > > > > > at
> > the
> > > > > > Please note that it may take a couple of minutes from the time
> > > > > > of submission until the htmlized version and diff are
> > > > > > available at tools.ietf.org.
> > > > > >

---

From: <[email-masked]>
Date: Mon, 19 Oct 2015 09:02:01 +0200

Hi,

> [Mingui] It sounds more and more interesting. That logic would be an essential part for the bonding service 
> arch. I think it's worthwhile to agree on a common model where all those necessary parts (load distribution, 
> reordering, congestion control, etc) could be integrated into one system.
I agree. As far as I recall during the Bar BoF in Prague we discussed that it would be a good approach to identify 
those "building blocks" which are common to the existing solutions. Having such a common model/architecture will probably help to identify the necessary parts.

  Best regards

     Nic

> > > > service. In particular, the solution for NAT-pass-through issue 
> > > > is described. It assumes the tunneling techniques cannot support 
> > > [Med] Yes. Other goals are get rid of the encapsulation overhead 
> > > and
> > reuse the
> > > same solution for UDP-based traffic. The plain mode allows to 
> > > easily
> > reuse
> > > service functions (e.g., DPI) that are deployed at the network 
> > > side
> > without
> > systems are changed a little bit: in draft-boucadair-mptcp-dhc-01, 
> > it reads
> >
> > > > encapsulated packet can be wrapped with a UDP header, which 
> > > > forms a tunnel-over-UDP. By doing that, NAT-pass-through can be 
> > > > addressed as
> > well.
> > >
> > > may be some side effects if intermediate functions are needed to 
> > > be
> > invoked
> > Customers of the bonding service would discriminate the 
> > heterogeneous connections. For example, the alternative connection 
> > would not be used unless the primary connection is saturated; some 
> > application types need be recognized by the bonding devices and be 
> > transported only on a primary connection; load generated by home 
> > users usually contains sparse applications types, therefore 
> > per-packet load distribution is required to achieve a fine-grained 
> > load distribution on the multiple
> connections.
> [Med] I hear you. Several strategies to optimize the use of multiple 
> paths can be considered in addition to the ones that were considered so far in MPTCP.
> This is exactly the reason why I do think there is some value in 
> separating the load distribution logic from the actual transport 
> mechanism. This is particularly valid for the UDP case.
> 
> >
> > >
> > > >
> > > > bonding service. This had ever been discussed on the list. I 
> > > > know MPTCP can well support flow based traffic distribution. 
> > > > However, I remember it was mentioned somewhere that MPTCP can be 
> > > > adapted to support per-packet load sharing among the multipaths. 
> > > > Will this direction be
> > > considered?
> > >
> > > [Med] The per-packet distribution is not excluded by this draft. 
> > > We do
> > think that
> > > used to transport data over multiple paths, but I must admit this 
> > > is out
> > of scope
> > > of this draft.
> >
> > [Mingui] Thanks for the clarification. For home users, the 
> > per-packet load distribution is desired so I hope it would be 
> > covered in some other drafts.
> 
> > > > clear to me is where the other end is to be deployed? Will the 
> > > > L4 capable Concentrator be deployed on physical routers or servers?
> > >
> > > > > We submitted this I-D to discuss a proposal that aims to get 
> > > > > rid of the encapsulation when aggregating multiple network attachments.
> > > > >
> > > > > > De : I-D-Announce [mailto:[email-masked]] De 
> > > > > > la part de [email-masked] Envoyé : lundi 21 
> > > > > > septembre
> > > > > > 2015
> > 15:31
> > > À :
> > > > > >    One of the promising deployment scenarios for Multipath 
> > > > > > TCP
> > > (MPTCP)
> > > > > >    network attachments.  Because of the lack of MPTCP 
> > > > > > support at
> > the
> > > > > >    MPTCP Concentrator.  This document focuses on a 
> > > > > > deployment
> > > scheme
> > > > > > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain
> > > > > > -m
> > > > > > ode/
> > > > > >
> > > > > > https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode
> > > > > > -0
> > > > > > 0
> > > > > >
> > > > > >
> > > > > > Please note that it may take a couple of minutes from the 
> > > > > > time of submission until the htmlized version and diff are 
> > > > > > Internet-Draft directories: http://www.ietf.org/shadow.html 
> > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > >

---

From: <[email-masked]>
Date: Mon, 19 Oct 2015 08:54:24 +0000

Hi,

No doubt that agreement on building blocks is a key step for a common system design... I couldn't agree more... But, AFAIK, this is currently discussed in BBF; why not starting from there (i.e. leave system design to BBF and focus on protocols)? 

BR,
Pierrick

> De : Banana [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : lundi 19 octobre 2015 09:02
> À : [email-masked]; BOUCADAIR Mohamed IMT/OLN; [email-masked]
> > [Mingui] It sounds more and more interesting. That logic would be an
> > essential part for the bonding service arch. I think it's worthwhile
> > to agree on a common model where all those necessary parts (load distribution,
> I agree. As far as I recall during the Bar BoF in Prague we discussed that it would
> be a good approach to identify those "building blocks" which are common to the
> existing solutions. Having such a common model/architecture will probably help to
> identify the necessary parts.
> 
> 
>   Best regards
> 
>      Nic
> 
> 

_________________________________________________________________________________________________________________________

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: Mon, 19 Oct 2015 09:38:15 +0000

Hi Pierrick,

The classification of the BBF work and IETF work is exact and helpful. I think we are having a promising common view. 

Thanks,
Mingui

> [email-masked]
> Sent: Monday, October 19, 2015 4:54 PM
> To: [email-masked]; Mingui Zhang; BOUCADAIR Mohamed IMT/OLN;
> [email-masked]
> No doubt that agreement on building blocks is a key step for a common system
> design... I couldn't agree more... But, AFAIK, this is currently discussed in BBF;
> why not starting from there (i.e. leave system design to BBF and focus on
> protocols)?
> 
> BR,
> Pierrick
> 
> > [email-masked] Envoyé : lundi 19 octobre 2015 09:02 À :
> > [email-masked]; BOUCADAIR Mohamed IMT/OLN;
> [email-masked] Cc
> > : JACQUENET Christian IMT/OLN Objet : Re: [Banana] I-D Action:
> > I agree. As far as I recall during the Bar BoF in Prague we discussed
> > that it would be a good approach to identify those "building blocks"
> > which are common to the existing solutions. Having such a common
> > model/architecture will probably help to identify the necessary parts.
> >
> >
> >   Best regards
> >
> >      Nic
> >
> >
> > > > Zhang Envoyé : mercredi 14 octobre 2015 10:12 À : BOUCADAIR
> > > > Mohamed IMT/OLN; [email-masked] Cc : JACQUENET Christian
> IMT/OLN Objet : Re:
> > > > > > service. In particular, the solution for NAT-pass-through
> > > > > > issue is described. It assumes the tunneling techniques cannot
> > > > > > support NAT-pass-through between the CPE and the Concentrator.
> > > > > > This document addresses that issue. I guess this is the major
> > > > > > motivation for
> > > > proposing the
> > > > > "plain" mode.
> > > > >
> > > > > > forms a tunnel-over-UDP. By doing that, NAT-pass-through can
> > > > > > be addressed as
> > > > well.
> > > > >
> > > > [Mingui] Yes, there would be some gaps. If an intermediate
> > > > function becomes clearly required, it need be integrated into the overlay
> model.
> > > >
> > > > load-balance-among- multipaths use case so it's natural to have
> > > > the idea of reusing MPTCP which is designed to handle this use case.
> > > > could be reused in the bonding service architecture. The question
> > > > is whether it's feasible to integrated those necessary functions
> > > > _into_ the
> > > tunnel?
> > > > We've already seen that the Point-to-Point Tunneling Protocol
> > > > (PPTP) [RFC2637] has integrated quite some of them, right?
> > >
> > > paths can be considered in addition to the ones that were considered
> > > so far in
> > MPTCP.
> > > > > > However, I remember it was mentioned somewhere that MPTCP can
> > > > > > be adapted to support per-packet load sharing among the multipaths.
> > > > > > Will this direction be
> > > > > considered?
> > > > >
> > > > > the load distribution logic can even be separated from the
> > > > > actual
> > > > mechanism
> > > > > used to transport data over multiple paths, but I must admit
> > > > > this is out
> > > > of scope
> > > > > of this draft.
> > > >
> > > > > > peer of the MPTCP proxy will be deployed on the CPE. What is
> > > > > > not clear to me is where the other end is to be deployed? Will
> > > > > > the
> > > > > > > > -----Message d'origine----- De : I-D-Announce
> > > > > > > > [mailto:[email-masked]] De la part de
> > > > > > > > [email-masked] Envoyé : lundi 21 septembre
> > > > > > > > 2015
> > > > 15:31
> > > > > À :
> > > > > > > >         Title           : An MPTCP Option for
> Network-Assisted
> > > > > MPTCP
> ________________________________________________________________
> _________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 20 Oct 2015 06:15:43 +0000

Hi All,

I think the discussion on-going here leads to the following problem statement draft which we just submitted. Start from the problem statement, we can design the protocols.

Problem Statement: Bandwidth Aggregation for Internet Access

Abstract

   Bandwidth aggregation for Internet access can increase the access
   bandwidth and reliability. It has become a desirable network
   function, especially for those Service Providers who operates
   multiple heterogeneous networks.

   This document describes the issues with bandwidth aggregation for
   Internet access. The required network functions to be supported are
   specified. Several candidate solutions had been considered to support
   bandwidth aggregation for Internet access in IETF. These techniques
   are investigated.

https://tools.ietf.org/html/draft-zhang-banana-problem-statement-00

Questions? Comments?

Mingui

> From: Mingui Zhang
> Sent: Monday, October 19, 2015 5:38 PM
> To: [email-masked]'; [email-masked]; BOUCADAIR
> Mohamed IMT/OLN; [email-masked]
> > No doubt that agreement on building blocks is a key step for a common
> > system design... I couldn't agree more... But, AFAIK, this is
> > currently discussed in BBF; why not starting from there (i.e. leave
> > system design to BBF and focus on protocols)?
> >
> > BR,
> > Pierrick
> >
> > > > [Mingui] It sounds more and more interesting. That logic would be
> > > > an essential part for the bonding service arch. I think it's
> > > > worthwhile to agree on a common model where all those necessary
> > > > parts (load distribution,
> > > I agree. As far as I recall during the Bar BoF in Prague we
> > > discussed that it would be a good approach to identify those "building
> blocks"
> > > > > Mingui Zhang Envoyé : mercredi 14 octobre 2015 10:12 À :
> > > > > BOUCADAIR Mohamed IMT/OLN; [email-masked] Cc : JACQUENET
> > > > > Christian
> > IMT/OLN Objet : Re:
> > > > > > > The draft details the addressing issue which is definitely
> > > > > > > an important issue that falls in the problem space of the
> > > > > > > bonding service. In particular, the solution for
> > > > > > > NAT-pass-through issue is described. It assumes the
> > > > > > > tunneling techniques cannot support NAT-pass-through between the
> CPE and the Concentrator.
> > > > > > > This document addresses that issue. I guess this is the
> > > > > > > major motivation for
> > > > > proposing the
> > > > > > "plain" mode.
> > > > > >
> > > > > > [Med] Yes. Other goals are get rid of the encapsulation
> > > > > > overhead and
> > > > > reuse the
> > > > > [Mingui] I guess this kind of reuse is feasible given that the
> > > > > end systems are changed a little bit: in
> > > > > draft-boucadair-mptcp-dhc-01, it reads
> > > > >
> > > > > > may be some side effects if intermediate functions are needed
> > > > > > to be
> > > > > invoked
> > > > > However, I doubt the traditional load-balance-among-multipaths
> > > > > use case does not fully match the bonding service. MPTCP has to be
> adapted.
> > > > >
> > > > > heterogeneous connections. For example, the alternative
> > > > > connection would not be used unless the primary connection is
> > > > > saturated; some application types need be recognized by the
> > > > > bonding devices and be transported only on a primary connection;
> > > > > load generated by home users usually contains sparse
> > > > > applications types, therefore per-packet load distribution is
> > > > > I agree the flow & congestion control functions developed in
> > > > > MPTCP could be reused in the bonding service architecture. The
> > > > > question is whether it's feasible to integrated those necessary
> > > > > functions _into_ the
> > > > tunnel?
> > > > [Med] I hear you. Several strategies to optimize the use of
> > > > multiple paths can be considered in addition to the ones that were
> > > > considered so far in
> > > MPTCP.
> > > > > > > Traffic distribution issue is another important issue for
> > > > > > > the bonding service. This had ever been discussed on the
> > > > > > > list. I know MPTCP can well support flow based traffic distribution.
> > > > > > > However, I remember it was mentioned somewhere that MPTCP
> > > > > > > can be adapted to support per-packet load sharing among the
> multipaths.
> > > > > > > Will this direction be
> > > > > > considered?
> > > > > >
> > > > > > > A clarification questions: from Figure 1, it is clear that
> > > > > > > one peer of the MPTCP proxy will be deployed on the CPE.
> > > > > > > What is not clear to me is where the other end is to be
> > > > > > > deployed? Will the
> > > > > > > > We submitted this I-D to discuss a proposal that aims to
> > > > > > > > get rid of the encapsulation when aggregating multiple
> > > > > > > > network
> > attachments.
> > > > > > > >
> > > > > > > > >    One of the promising deployment scenarios for
> > > > > > > > > Multipath TCP
> > > > > > (MPTCP)
> > > > > > > > > Please note that it may take a couple of minutes from
> > > > > > > > > the time of submission until the htmlized version and
> > > > > > > > > diff are available at tools.ietf.org.
> > > > > > > > >
> > > > > > > > > I-D-Announce mailing list [email-masked]
> > 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.