[Banana] charter comments and discussion

[Pierre Pfister <[e-mail]>]

Hello banana fans,

I was at the bof yesterday and trust Margaret to send Juliusz notes to the list as soon as possible, but in the meantime, here are a few comments based on yesterday's discussion, and the charter as it currently stands.

1. Small flows should be in scope too:
Multiple parts of the charter focus on flows which are big enough such that
it is desirable that the packets of the given flow are load-balanced over the multiple uplinks.
Although this is an important part of the problem statement, the designed solution must
also take small flows into account. The designed solution must provide a way for
small flows to not be aggregated at all in order to avoid the overhead and disadvantages of packet
re-ordering and/or delaying.

2. Homenet:
The homenet working group addressed the problem of small zero-conf networks, including multiple routers as well as multiple uplinks. The WG specified the HomeNet Control Protocol (HNCP), which implements network auto-discovery, configuration and routing bootstrap. I think that the banana WG could take advantage of using the homenet architecture (homenet has spent quite a significant amount of time figuring out what a small network with multiple uplinks look like and how it should work). On the other hand, I think homenet could take advantage of the solution designed by banana. Therefore, I think the designed solution should be applicable to homenet networks.

3. Middle-boxes:
Based on the discussions during the bar bof, the currently privileged architecture seems to rely on the use of a dual-proxied connexion. Although I do share the idea that MPTCP is a great technology, which should be widely deployed in hosts, I am deeply concerned that the IETF would standardise a (double-)middle-box technology (particularly in the context of the IPv6 deployment, which intends to finally get rid of many of those). I think the charter should mandate that the designed solution either:
- 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.

4. High reliability:
It might be desirable to provide, for some class of traffic, higher reliability by the
mean of packet duplication (over multiple uplinks) and de-duplication (at the remote banana box). 
This could be useful for, e.g., DNS requests, early connexion packets, as well as other low-throughput mechanisms
which, when packets are lost, rely on a retransmissions.

That's all for now.

Thanks,

- Pierre