Re: [Banana] Reaching Consensus on Problem Statement

[Mingui Zhang <[e-mail]>]

Hi Brian,

Please see my comments inline below.

> -----Original Message-----
> From: Banana [mailto:[e-mail]] On Behalf Of Brian Trammell
> Sent: Friday, February 03, 2017 6:09 PM
> To: Mingui Zhang
> Cc: Michael Menth; [e-mail]
> Subject: Re: [Banana] Reaching Consensus on Problem Statement
> 
> hi Mingui, Michael, all,
> 
> inline below...
> 
> > On 03 Feb 2017, at 10:40, Mingui Zhang <[e-mail]> wrote:
> >
> > Hi Michael,
> >
> >> -----Original Message-----
> >> From: Banana [mailto:[e-mail]] On Behalf Of Michael
> >> Menth
> >> Sent: Friday, February 03, 2017 2:53 AM
> >> To: [e-mail]
> >> Subject: Re: [Banana] Reaching Consensus on Problem Statement
> >>
> >> Dear Margaret,
> >>
> >> thanks a lot for your initiative!
> >>
> >> The scope may depend on where the load balancer and recomination
> >> point are located. In the network similar to
> >> draft-zhang-gre-tunnel-bonding-01.txt (GRE Tunnel Bonding) or MPTCP-Proxy,
> or on the endpoints like pure MPTCP?
> >> Probably focus is on the first, but the text doesn't say so, yet.
> >
> > According to my understanding, the scope might as well be applicable to the
> network with MPTCP-Proxy. And surely, it does not include the network with
> pure MPTCP endpoints.
> >
> >> I can imagine that the load balancing option (per-packet or per-flow)
> >> may be minor. Both may be justified for performance reasons depending
> >> on networking conditions. Therefore, I wouldn't rule out per-flow
> >> load balancing but a priority on per-packet may be reasonable to start with.
> >
> > But there are solutions for per-flow load sharing already. Think about the
> widely used and standardized hashing methods. I think it’s non-necessary to
> mention per-flow load sharing issue in the problem statement. Otherwise, the
> problem statement would look like encouraging reinventing something.
> 
> Speaking personally, no Seoul-BoF-chair or other hats on:
> 
> Let me slightly restate the question here. Will a BANANA-balanced network with
> two links to the Internet with available downstream data rates A and B (such that
> A >= B) will ever need to support a single flow with a sustained data rate > A?

Yes, this is needed. 

> 
> If not, we can take existing work on per-flow load balancing off the self. If so, we
> need to invent something.

Here, do you mean "per-packet" rather than "existing work on per-flow"? Sorry, I am confused since "a single flow with data rate > A" can only be achieved through per-packet load splitting. 
Michael and I had no doubt that per-packet is necessary in the first place. We were actually arguing whether per-flow should be additionally included in the problem statement. 

> 
> In scenarios where there is no dominant flow, or where A >> B, the extra
> complexity of splitting flows across links is not worth the additional complexity.
> However, in scenarios where one flow dominates, i.e., the majority of the data
> rate demand is covered by a single flow, and where rates A and B are relatively
> comparable, per-flow load balancing leaves a lot of available bandwidth on the
> table, and the complexity tradeoff becomes more worth it.

After I read up to here, I understand you are describing why BANANA need to "split" flows in addition to per-flow load balancing. Then we are on the same page. 

By the way, the formulation of the scenario is awesome.

Thanks,
Mingui


> 
> So for me this question reduces to which scenario is more common.
> 
> Cheers,
> 
> Brian