[Banana] Meeting of 29 March 2017: minutes

[Juliusz Chroboczek <[e-mail]>]

Hi,

Margaret has reviewed my notes, and we're still friends.  Please find
attached a copy of my best effort at minuting the Banana meeting of
29 March 2017.

----------------------------------------------------------------------

Dramatis personae:

  MC = Margaret Cullen
  jch = Juliusz Chroboczek
  PP = Pierre Pfister
  Mirja = Mirja Kuehlewind
  Christoph = Christoph Paasch
  Phil = Philip Eardley
  BS = Barbara Stark
  Allan
  Jim
  Vach
  and others

MC: if MPTCP charters the proxy work, good, otherwise we do it.

Christoph: demands clarification.

MC: the people who are doing it prefer MPTCP.  Let's assume for now that
they're successful.

MC: a magic end-to-end solution would be preferable, but end-nodes are
difficult to change.  End-nodes are not aware of multiple links, although
of course (multihomed) cellphones are.

???: but the CPE is aware.

MC: IETF would prefer a less constrained solution.  The remote node can be
anywhere on the Internet.  Fortunately, all the proposed solutions are
general enough.

jch: consider working at the application layer.  Example: QUIC could
potentially do load balancing without lower-layer involvement.

???: But QUIC doesn't do that.

???: You cannot split a single flow between multiple IP addresses.

MC: You're basically proposing MPTCP at the application layer.

MC: one of the goals is to combine links each of which is too slow for the
application.

???: the proposed charter is too restrictive, we should do more than just
the SOHO.

MC: the goal is to split a single flow across multiply attached links.
  Ex: one metered and one non-metered link.
  Ex: spotty LTE service, use it when available.

PP: the obvious approach is what jch mentioned.  Other
approaches involve NAT, let's make it clear from the outset that NAT is
not a solution.

MC: Nobody has proposed NAT.

PP: let's agree NAT is outlawed.

MC: 2 solutions: bonded links and MPTCP.  MPTCP could solve some of the
problems.

jch: Do you mean proxies?

Allan: QUIC is unproxyable.

MC: end nodes don't know how to split the traffic, somebody who knows the
DSL link does know.

jch: didn't MPTCP solve this particular problem?

Christoph nods.

MC: for the particular case of TCP.

jch: the technology is not specific to TCP.

PP: Margaret, you're overly pessimistic.

MC: it's been three years, and there's still no concrete proposal.

PP: so let's make one.

MC: you might have 9 DSL links, and still not be able to make a video call
because each link individually is too slow. 

PP, jch: let's assume you can make a new application for video conferencing,
one that is able to split the traffic.

MC: I want to do the video call, and I want to do it now.

Christoph: speaks about MPTCP proxy.  The solution is in MPTCP.

PP: Let's please avoid congestion control over congestion control.
I much prefer the tunnelling approach.

MC: If you use MPTCP, then you cannot customise policies.

Phil: Disagree, MPTCP is not so restricted.

MC: the problem with solutions at the transport layer is that it doesn't
know what other applications may be using the same link for.

Christoph: that's a problem that is solved by congestion control algorithms.

Vach: what if I have a very expensive line (monetary cost), TCP doesn't
know how to avoid it.

Jim: imagine non-TCP flows, e.g. a video connection running on one link.

Christoph: that's solved by the congestion control feedback loop.

MC: there are two approaches.

Allen: there is a group of 10 carriers driving within the BroadBand Forum
the notion of SGFix (?).  Hybrid access for converged operation.  Why not
liaison with BBF?

MC: just because they participate in a project, the companies haven't
chosen a solution yet.  They are simultaneously using tunnel bonding
solution.  (See draft-zhang-tunnel-bonding.)

MC: IETF is about solutions that don't come from a single provider.
Imagine bandwidth charges, imagine people arriving to your home with their
smartphones.

Dolson: (about different providers) it's an interesting interop problem.

MC: what's interesting for IETF is multiple applications.

Vach: multiple vendors don't necessarily want to implement a single
protocol, someone needs to standardise, could be IETF.

Allan: the multiple provider case is esoteric.

Vach: regulatory requirements is what drives investment.  E.g. require
minumum X mbit/s.  Just because it's a single provider doesn't mean we
don't need standards.

Allan: let's not neglect the gorilla in the room (alluding to the
consortium of operators he mentioned earlier).

MC: carrying a mobile phone into a home is not esoteric.

David: if it's a single box, how does it help with the mobile phone case.

MC: imageine an OpenWRT box that I put in my home, it shares all of those
links.

Mirja: the endpoint needs to be at the right place, or else you add latency.

MC: the box could be provided by the provider.

???: Why would the provider want to do that?  He's providing traffic for
a competitor.

Mark Donnelly: the provider is making money by using bandwidth provided by
another provider.

MC: In Seoul, a lot of people interested in this problem.  We're trying to
come up with a charter.

jch: I see 3 groups of people (application layer, proxying, tunnelling).

MC: there were only 2 (proxying, tunnelling) until you showed up.

jch shuts up.

Mirja: all we need is a control protocol.

Phil: agreed, signalling protocol between banana boxes.

MC: The MPTCP solution (is? should be?) in the MPTCP group.

Phil: could the group work out a way to be more generic, that doens't
depend on MPTCP or else.

MC: we already have a tunnelling solution.

Mirja: whatever the protocol, we need to get the banana boxes configured.

MC: we could call it a single solution with two transport protocols.  Or
call it two solutions.

Vach: ???

MC: a banana box connected to a hundred homes.  All the links have
different properties.  The user can define properties.

In Germany, TV has to go over ADSL.  There needs to be a policy to bypass
banana.

PP: I see two conflicting requirements.  Being generic, and able to be
clever.

Mirja: it's your decision what protocol to use.  You can use proxying.

(Mirja explains proxying to PP.)

PP: that's horrible.  It only allows some protocols?

MC: the traffic hits the box, the box decides.

PP: that's horrible... (interrupted by MC).

Allan: let's not compare approaches, let's define a framework.

Vach: ???

Mirja: the amount of information that needs to be communicated is very
limited.

???: Exchanging policies is a different matter, you should not even need to
do any signalling.

Allan: the amount of information that's communicated is very small.

Mirja: MPTCP only addresses tunnelling; in general, you need more data.

Jim: we're speaking of solutions, not of the charter.  Let's not put the
cart before the horses.

Dave: could we say that this only needs to work for IPv6?  If so, we can
play some games (with multiple prefixes, with virtual prefixes).

Mirja: this is not specific to IPv6.

MC: IPv6 is unnecessarily restrictive.

Mirja: we're trying to charter.  We need to scope it, just communication
between local and remote bananas.

MC: ???

Mirja: there is a lot of pushback on adding information to an end-to-end
protocol, because MPTCP is an end-to-end protocol.  That's just MPTCP
between the boxes.

MC: but how do you convert the traffic to MPTCP?

Mirja: I would like some guidance on setting up an MPTCP proxy.

MC: MPTCP is TCP only.

Mirja: that's just the tunnel.  MPTCP is not a tunnel protocol, that's why
we need a generic signalling protocol.

MC: there are three parts:

  - data;
  - signalling;
  - ???

Mirja: why is this different from any other tunnel?

Vach: the issue is about fat flows, splitting them across subflows.  GRE
has no info about splitting.

It's a solved problem for MPTCP, not for GRE.

???: Fat flows is not something you're going to detect ahead of time.

Mirja: ???

Vach: There is no GRE working group.

Mirja: we just need a seqno, not a new protocol.

MC: in MPTCP, there is a bunch of information.  In GRE, we need a control
protocol.

MC: we're speaking of a 12 page document for encapsulation.  If we put it
inside MPTCP, encapsulation.

???: is this specific to the case of one provider?

Mirja: the requirement is to have a sequence number.

jch: why?

MC: we want to avoid reordering.

Mirja: TCP has horrible performance in the presence of reordering.  THere
is some work to make TCP perform better.  QUIC is more robust.

Vach: or use MPTCP.

MC: that's two solutions.  You could potentially use both at the same time.

Mirja: if the latency difference is low, you don't need to reorder.

Mirja: a QUIC flow should be treated as a single flow.  If you want
different treatment, use multiple QUIC connections.

MC: this makes it even more important to be able to split a single flow.

jch: much as I enjoy this dicussion, is this not getting too technical at
this tage?

MC: that's the problem we've been having for four yers.  But we are moving
forward.

Phil: it would be good to come back to the three problems.

I'm not sure how the MPTCP people would react to having a new signalling
protocol.

There's the no-round-trip-time requirement.

We don't want the banana boxes to negotiate during a few RTT for each new flow.

MC: that's not the plan.

(MC and Mirja have a technical discussion, I am lost, like much of the
audience.)

Mirja: plain mode MPTCP draft is not a terminating proxy.  They add an
MPTCP option on the fly, they change the address, recompute the checksum.

Phil: that's essentially NAT.

MC: it's a good thing they took UDP out.

I think we basically have agreement on the problem statement.

(MC starts editing the draft charter.)

MC: Banana box?

Phil: it's a good term.

jch: the charter is ambiguous: is the signalling protocol between local
Banana boxes, or between local and remote?

Phil: the local box is naturally on the default path.  Not so the remote.
You need to do something.

(Mirja, Allan, Praveen get into a technical discussion.  I zone out.)

jch: is support for multiple banana boxes required?

Mirja: that shouldn't be required.

Allan: I don't think that's possible.

PP: perhaps you should consider the Homenet architecture.  It'd be
a pity if a case solved by Homenet were ignored.

MC: I'm not suggesting it be ignored.

(More word-smithing discussion, a sentence gets added to the charter.)

Vach: you're putting too much about GRE in the charter.

Jim: the charter should be solution-neutral.

MC: there are two kind of working group, solution-based and problem-based.
(She mentions Babel, which pleases the note-taker.)

Phil: satisfied that MPTCP is mentioned.

Mirja: please narrow scope, avoid specifying new encapsulation.

MC: not sure.

Jim, Mirja: select and possibly extend existing encapsulation.

MC: specify that the encapsulation is at layer 3.

Vach: leave that open.

Mirja: ???

MC: what if the signalling protocol were extensible?  It could be later
extended to handle UDP, MPTCP, MP-QUIC, etc.

We need to make sure that nothing bad happens if there are multiple banana
boxes, even hierarchical.

Phil: what about the case of a smartphone and a banana box?

MC: the smartphone acts as a banana box.  A software box.

David: call it a banana function, then.

jch: strongly object, banana box sounds much better.

MC and Mirja discuss bypassing, in order to avoid multiple encapsulations.

MC: bypassing depends on whether there's NAT or no NAT.

Mirja, Phil: Banana must not break MPTCP.

Mirja: ???

Allan: objects to the extensive use of "should" in the draft charter.

David: are we addressing the requirement that TV in Germany must go over
the DSL line?

MC: yes, this is similar to an expensive (monetary cost) link.

BS: Cellphone in a Banana network, has its own traffic that is not
accounted by Banana.

MC interrupts BS.

BS apologises.

Allan: we should mention that we will collaborate with whatever group
"owns" the encapsulation.

MC: if MPTCP charters (the proxying work), we collaborate.

Vach: get rid of the two paragraphs (about collaboration).

Phil: send it to the MPTCP list.

MC: not a good idea, might be taken as grandstanding.

Need to define Banana boxes, but won't do it with 20 people in the room,
then send it to the list.  The charter may change, let people not be shocked.

Phil: agrees.

MC: send it to Shuresh, he's probably going to change it.

Mirja: Shuresh -> IESG -> external review.

MC: IAB review?

Mirja: no

MC: BoF already a lot of interest, hope for WG-forming in Prague.

Mirja: the charter's intentions are clear, suggests adding a milestone.

MC: agrees, maybe multiple milestones.

The note-taker collapses with exhaustion.