Re: [Banana] Updated Charter

["Sri Gundavelli (sgundave)" <[e-mail]>]

> 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