[Banana] De bananibus

[Juliusz Chroboczek <[e-mail]>]

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