Re: [Banana] charter comments and discussion

Hi Pierre,

> 4. High reliability:

At the network layer, reliability about switching traffic from a failed link to a working link is fine. I believe the features you list are all issues of the transport layer. If BANANA picks the tunnel based to go forward, we would not design solutions to support the “higher” reliability, especially the retransmission stuff which was proved to be a wrong direction by the PPTP practice [RFC2637].

Thanks,
Mingui
________________________________________
From: Banana [banana-bounces@ietf.org] on behalf of Pierre Pfister [pierre.pfister@darou.fr]
Sent: Friday, March 31, 2017 5:35
To: banana@ietf.org
Cc: Margaret Cullen; David Schinazi; Juliusz Chroboczek
Subject: [Banana] charter comments and discussion

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

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