Subject: Re: [Banana] charter comments and discussion

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 01 Apr 2017 09:38:48 -0500

>> - Makes sure that packets received by src (resp. dst) are identical to
>>   packets originated by the dst (resp. src).
>> - Only aggregates traffic "between consenting adults", i.e., when both src
>>   and dst endpoints are aware of what is going on.

> - you should not be stuck with banana when you are able to use
>   a transport protocol that can do better (e.g. MPTCP or MP capable Quick
>   some time in the future)

> - When using banana, you should be able to get rid of the reordering and
>   the delay it causes (e.g. if your transport protocol can really
>   tolerate reordering - not in a TCP way)

I think the two of you are speaking of different things.  Pierre is
speaking about his concern that Banana will introduce a new kind of IPv6
middlebox, so he requests that a Banana box behave as a dumb
en/decapsulator.  Pilipp is speaking about the ability to bypass Banana.

Both requirements have the same goal (avoiding contributing to so-called
"ossification"), but they are different requirements.  For the record,
I support both.

-- Juliusz

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 24 Apr 2017 03:38:11 -0400

> On Apr 1, 2017, at 10:38 AM, Juliusz Chroboczek <[email-masked]> wrote:
> 

So do I, although I am not sure we want to include this sort of detail in the charter vs. selecting solutions that have these properties.

Margaret

> 
> -- Juliusz
> 
> _______________________________________________
> Banana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/banana