Re: [Banana] Updated Charter

["Muley, Praveen (Nokia - US/Mountain View)" <[e-mail]>]

Hi Margaret :
      My comments inline

From: [e-mail] [mailto:[e-mail]]
Sent: Friday, September 29, 2017 4:31 AM
To: Muley, Praveen (Nokia - US/Mountain View) <[e-mail]>
Cc: Sri Gundavelli (sgundave) <[e-mail]>; Margaret Cullen <[e-mail]>; [e-mail]; Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Banana] Updated Charter


Hi Praveen,

The document you cited is not an "over-the-top" or link-layer-independent mechanism, as it cites particular elements in an operator network.  It might be possible to change it to be more link-layer independent, though.

The bigger point is that it is not a standard.
PM >> Can you please elaborate this comment ?  All the interfaces shown are standard. That’s why the draft is informational. Draft doesn’t ask for any new extensions.

Currently, it describes one if several proprietary ideas for how to perform bandwidth aggregation.  I don't remember if this particular one is implemented or deployed, but some of them are.

PM >> This is implemented across all Nokia product lines relevant to this space and the co-author list on draft shows acceptance across carrier space.


The point of the WG would be to develop standards in this space for cross-vendor interoperability.

PM >>  But that also is goal of MP-TCP/MP-QUIC.  In fact if you have to do over the top solution for packet based distribution, then good candidates are MP-TCP/MP-QUIC as at least there is NO  firewall which will block that traffic. Any other encaps MAY need co-operation from the other carriers to allow such traffic.
            My concern on charter is we approaching this as BANANA solution and there are several components like discovery/signaling etc. IETF never had BNG like working group to solve all BNG related issues which are somewhat similar to this BANANA GW.  BNG uses set of protocols  and for each of them you have specific WG. IP address can be allocated using Radius/DHCP but there are different WGs dealing with those extensions. Similarly here there are different WGs working on solution and eventually market will decide which one they are interested in pursuing based on use cases deployment/legacy concerns etc.
                               And in this context its more important to scope out our problem statement and see what is missing in existing solutions.  Answer to some these questions will help us agree on charter text.
-Praveen

Margaret

Sent from my iPhone

On Sep 29, 2017, at 5:32 AM, Muley, Praveen (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>> wrote:
All :

 https://www.ietf.org/archive/id/draft-muley-network-based-bonding-hybrid-access-01.txt

This solution uses all existing standards and works in  all combinations of hybrid access  (DSL + LTE )  ( Wifi+LTE)  ( LTE + satellite)  and (5g + 4G) and works with  modems/handsets.  It also covers the approach using combination of solutions such as use of MP-TCP proxy to address packet based load balancing.

Apart from MP-TCP I see MP-QUIC being discussed in QUIC.    In that case  what type of traffic issues are we trying to address by having yet another MP mechanism here in BANANA?   It will be good to know the exact problem or use case which is NOT addressed by any of the other mechanisms  which hurts any of the existing deployments that.

https://datatracker.ietf.org/meeting/99/materials/slides-99-quic-sessb-first-experiments-with-multipath-quic/


In beginning 3 years back when the discussion started, I was very much in support of having common WG to discuss hybrid access problem and in fact had objected to adoption of MIP work getting adopted in DMM working group . But over the years MIP work is progressing in DMM, MP-TCP and MP-QUIC are discussed separately in their respective WG. Now,  It doesn’t make sense to reset any of that work now just to start another WG. And in those regards I see Wim’s proposal quite reasonable.
                           Since there seems to be concern on clarity of the problem statement among quite a few participants, I would suggest to use IETF 100 to have face to face meeting to hash out the exact problem statement.

-Praveen



















From: Banana [mailto:[e-mail]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, September 28, 2017 4:23 PM
To: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Banana] Updated Charter

> I suppose that the IAB and IESG could decide that it is a bad idea to standardize a packet-based load balancing mechanism for bandwidth aggregation.  I wouldn’t like that answer, but

We cannot use this one feature as a reason for redefining the entire MIP multi-homing architecture starting with a new signaling protocol and define 20 other extensions. I am sure, the same folks in IAB/IESG will not be delighted to see that WG will duplicate every thing that was done previously and then add this new feature.

I have said it multiple times. If you want to publish an algorithm/analysis on how Per-packet load balancing approach across multiple overlay tunnel paths, as a generalized approach applicable to MobIKE, MIP, Static Tunnels and GTP based architectures, it is absolutely fine. This was Wim’s comment too; to focus on the information elements that tunnel peers can exchange, which can be applied to any signaling protocol.

Its not my absence as an individual, in some what a semi-private meeting (or not governed under any IETF process), is the basis for redefining protocols. Our IETF process cannot be this weak where a small group of people can create alternatives with identical architectures and semantics. All of this confusion is due to the bizarre process adopted in IETF99 to skip PS discussion and focus on charter text which is cluttered with Banana terminology, and providing no data on gap analysis, or on the actual use-cases/PS.


Sri


From: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 28, 2017 at 3:42 PM
To: Microsoft Office User <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Banana] Updated Charter


Some of us have been talking about bandwidth aggregation in an open, IETF, non-WG context for about 3 years now.  You were at some of our early meetings, at which we attempted to catalog and review all of the different solutions in this space, and talk about their similarities and differences.  Many people presented their solutions at Bar BOFs or provided pointers to specifications for their solutions, etc.  We asked you to present your MIP-based solutions, but you refused, and you later stopped attending our meetings.   We reviewed the related requirements work from the BBF.  We had several Bar BOFs, an informational BOF, and a WG Forming BOF.  There have been mailing list discussions, shared google docs, etc.  Some of the proposals were improved based on feedback from our meetings, or to incorporate features of other solutions.  Lots of different people from different companies have written drafts for consideration by the proposed WG.  Some of the proprietary solutions have been successfully deployed and are in use by hundreds of thousands of customers.  Researchers have done modeling of the behavior of some of the proposed mechanisms, and have come to interesting conclusions.  At this point we have multiple operators, several vendors and a couple of academic institutions actively engaged in the effort.

You and I are in agreement that people should go through a process of reviewing what is out there before they attempt to charter a WG to do new protocol work.  However, I believe that we have already done the things that  you are currently saying that we need to slow down and do.  It was your choice not to participate in that process, and I don’t think we should be required to do it over, so that you can participate this time.

We presented the results of much of our investigation at the Informational Bar BOF.  That work has lead many of us to the opinion that (1) there is no standards-based solution out there that solves this problem, as-is, (2) there are a number of proprietary solutions based on different standards-based technologies (MIP, MPTCP, GRE, etc.), (3) there is a need for bandwidth aggregation mechanisms that allows a single flow to be balanced across multiple paths, (4) MPTCP and tunneling mechanisms both have advantages and disadvantages, and (4) it would be beneficial to have standards in this space, for interoperability between vendors.

I suppose that the IAB and IESG could decide that it is a bad idea to standardize a packet-based load balancing mechanism for bandwidth aggregation.  I wouldn’t like that answer, but

Margaret


On Sep 28, 2017, at 5:19 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

We can make very  general statements that MIP is not designed for this, or that and so lets do some thing new. But, we all are very technical people and I hope to see these statements backed by technical data and with detailed analysis. Otherwise, these comments may not mean any thing.

If MIP has lot of options and capabilities, and one does not understand, we should have discussions on that and not charter a WG and define a new protocol. The amount of work that went in Multihoming, IFOM, Security ..etc is not a small effort.  Vendors have deployed solutions and so IETF should have reasons to define alternatives that do the same thing.

Sri



From: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 28, 2017 at 1:41 PM
To: Microsoft Office User <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Banana] Updated Charter


On Sep 28, 2017, at 4:03 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

> The downside is that they are all proprietary, so they don’t work _together_.

The list I gave is a set of features supported today based on MIP RFC standards.

I can see how (some of) the MIP technology could apply to (parts of) this problem space in interesting ways.  However, MIP (as it exists in the RFCs I have read, and presumably in most implementations) has several properties that don’t seem like a great fit for a the BANANA problem statement, including:

1) It is focused on mobility, not load balancing, and these aren’t inherently the same thing.  While I can see how you could repurpose some of MIP's mechanisms for load balancing, I don’t see how you could use an arbitrary RFC-compliant implementation for this purpose without modifications.
2) It is flow-based.  I didn’t see any mechanism for recognizing that a single flow has been split across multiple paths, and recombining that flow before forwarding it to the final destination.
3) Its security model seems to rely on the notion that the destination node and the Home Agent are under the same administrative control.  Maybe RFC 6618 will change my mind about this — I will read it.
4) The home agent is on the “home network” of the destination, not necessarily on the network where the destination is currently located…  I think that bandwidth aggregation needs to have one endpoint on the local network with the end-node, so that it can detect that there is more than one local link to aggregate.  However, even if there was a home agent locally, I am not sure how/if a MIP end-node would find it and associate with it.

It is possible that I am missing something, but if so, then it is very likely that other people are missing it, too.  If you want us to decide that there is no need to specify a flow-based bandwidth aggregation mechanism because MIP already does that, I think you would need to do something to explain _how_ MIP already does that, because it isn’t obvious.

Margaret

_______________________________________________
Banana mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/banana

_______________________________________________
Banana mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/banana