Re: [Banana] Reaching Consensus on Problem Statement

[<[e-mail]>]

Hi,

Von: Banana [mailto:[e-mail]] Im Auftrag von Margaret Cullen
Gesendet: Freitag, 3. Februar 2017 16:46
An: Mirja Kühlewind
Cc: [e-mail]
Betreff: Re: [Banana] Reaching Consensus on Problem Statement


On Feb 3, 2017, at 5:14 AM, Mirja Kühlewind <[e-mail]<mailto:[e-mail]>> wrote:

Hi Margaret,


This is related to point 4 and combining both is the interesting problem from my point of view. If you have multiple flows and multiple interfaces, it's rather easy to simply route/schedule different flows over different links (a la ECMP). The problem comes up if you have a service with one flow that needs more capacity than a single link can provide. The example we’ve been working on is HD video streaming in rural areas where the DSL is limited but LTE is provided and sparely used. In this case you need re-oder buffers and additional signaling between the tunnel endpoints.

This is an interesting way of putting it — that a single flow needs more bandwidth than a single link can provide.  I think I would say, though, that this is useful when a single flow needs _or can benefit from_ more bandwidth than a single link provides, because a solution is also desirable in this area to allow, for example, content downloads to finish more quickly, even if they do not _need_ to finish more quickly in order to be useful.  Does that make sense?

I think for links with smaller bandwidth this is a very valid scenario (e.g. if you do have 4+4 or 6+6 MBit/s). In this case you benefit from the additional bandwidth and it is very likely that we will have services exceeding the bandwidth of a single link (like the HD scenario mentioned above).

Regards

Nic