Subject: [Banana] De bananibus

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 30 Mar 2017 14:23:38 -0500

Dear Banana Boxers,

I've sent a cleaned up version of my notes from yesterday to Margaret at
some ridiculous time last night.  I guess she'll want to send them to the
list after some careful censorship.  If she doesn't, I'll do.

While I am more in favour of performing aggregation at the application
layer, I do think that Banana is a fun little engineering project, one
that can be done horribly wrong (e.g. by tunnelling over MPTCP) or pretty
elegantly if one has taste.

First, a question that wasn't raised at the meeting: is communication
between Banana boxes secure (authentified or encrypted)?  I can see
arguments both ways -- on the one hand encrypting the tunnel is good for
user privacy, notably by hiding the destination of traffic from all but
one providers, on the other hand one might argue that the tunnel is part
of the public Internet, and therefore deserves no more protection than is
already provided to any traffic it carries.

Second, I can foresee a danger for the working group: it might turn out
that everyone and his brother (or sister) will want to add their favourite
feature to the control protocol (please add my TLV, add my scheduling
policy that has no use cases, use XML instead of a binary protocol, and
make sure that it interoperates with YANG).  I think the group will need
to be very vigilant to design an extensible but very minimal control
protocol.  Make it as lightweight as possible, and then remove half of
what is left.

Third, I think there are some fun algorithmic issues involved, and I'd
suggest checking the published literature on multipath VPNs (I'm not sure
there's much on the subject).  For decent performance, a Banana box must
have a refined AQM and a refined scheduling algorithm.  It's not clear to
me whether the scheduling is below the AQM, above the AQM, or whether the
two are a single algorithm.  I think there's an analogy with MPTCP here,
where the scheduler and congestion control algorithm are intertwined in
mysterious and marvelous ways.  (I do have some ideas, but I want to check
the litterature before I dive in.)

Another interesting issue is the policy with out-of-order packets.  You
obviously want to buffer out-of-order packets for a time that depends on
the relative RTTs of the different links, but the actual details may be
tricky.  Perhaps multilink-PPP has solved the problem?

Thanks for the entertainment,

-- Juliusz

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 31 Mar 2017 10:36:36 -0500

One quick comment:

> Am 30.03.2017 um 14:23 schrieb Juliusz Chroboczek <[email-masked]>:
> 

I think/hope this is out of scope for banana and the ietf. That’s a place where you can do research and bring it to the IRTF or come back when you have a good and widely deeply solution. Banana may provide one recommendation for a simple solution but there is also no need for interoperability and therefore less pressure for standardization.

Mirja

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 31 Mar 2017 11:10:17 -0500

>> there's much on the subject).

> I think/hope this is out of scope for banana and the ietf.

I agree that this does not require standardisation, at most informational
implementation recommendations.  OTOH, in my experience IETF is rather
friendly to working code, and discussing algorithmic and implementation
concerns on this list is perfectly legitimate.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 31 Mar 2017 11:27:55 -0500

> OTOH, in my experience IETF is rather friendly to working code, and
> discussing algorithmic and implementation concerns on this list...

That sounded a little bit too assertive, sorry.  It was meant to say that
discussing implementation concerns on this list is hopefully legitimate.

-- Juliusz