Re: [Banana] diff (banana load distribution, next-hop selection of multipath)

Dear Margaret and all,

It's true that we need to exempt end-to-end MPTCP flows from BANANA processing in case the sub-flows of MPTCP are split by BANANA once again. 

I find we exposed a promising item that deserves our effort: we may consider how to integrate end-to-end MPTCP with BANANA. For example, the IP addresses used as tunnel endpoints could be reused by the MPTCP stack hence the address exchanging time introduced by the MPTCP stack could be reduced. I remember this kind of transition strategy was somehow touched upon in the BOF discussion.

BR,
Jing

-----邮件原件-----
发件人: Banana [mailto:banana-bounces@ietf.org] 代表 Margaret Cullen
发送时间: 2017年2月5日 2:28
收件人: Joe Touch
抄送: Mingui Zhang; banana@ietf.org
主题: Re: [Banana] diff (banana load distribution, next-hop selection of multipath)

> On Feb 4, 2017, at 1:21 PM, Margaret Cullen <margaretw42@gmail.com> wrote:
> 
> Personally, I would consider algorithms that run within a single box to decide whether to aggregate a particular flow...

Actually, there might be a couple of exceptions to my statement that this could be implementation-specific.

We might want to specifically state how "BANANA Boxes" would detect a BANANA flow and avoid aggregating it again.  We might also want to define how they should detect some other flows that already have multi-path capability, like end-to-end MPTCP and exempt those flows from BANANA processing. 

But, I think the performance/reliability-related decisions about whether to split a given flow (that is not specifically called out in the standard) across multiple available access networks should be implementation-specific.

Does that makes sense?

Margaret

_______________________________________________
Banana mailing list
Banana@ietf.org
https://www.ietf.org/mailman/listinfo/banana