Re: [middisc] TCP middlebox option requirements

[Ron Frederick <[e-mail]>]

On May 26, 2010, at 8:28 PM, Mark Day wrote:

> [Ron] A single byte for vendor ID clearly will not scale. There can easily be more than 256 vendors our there who may eventually want to use this option. I don't see any obvious way to do better space-wise than what we proposed with the OUI if we want this to be truly extensible to support all possible vendors.
>  
> I may be confused about what we expect will be the future developments in this space, but it’s not obvious to me that we need to support more than 256 vendors.  I suppose the key question here is what we mean by “eventually.” I thought this option-number reconciliation-and-rationalization was envisioned as a first step toward taking one (or a small number) of the “vendor” codes and using them as a basis for a standardized discovery protocol.  I’m not meaning that this particular group should do it, and certainly not that we should try to do it right now – but I did think that was a shared goal for some point in the future.
>  
> We currently have a handful of different proprietary discovery protocols that we are expecting to reconcile at the level of allowing them to multiplex a single consistent option code.  Do we really think that we’ll have hundreds of additional discovery protocols between now and when there is agreement on some kind of open-standard discovery protocol(s)?  I just don’t see that as a realistic concern, but perhaps I’m misunderstanding.

My expectation here is that this option will provide a standard way for all of the current proprietary schemes to share a single TCP option, and over time there will be specific use cases where middleboxes can interoperate with one another and switch to one of the "public" type codes which get defined within this framework, but there would continue to be good reason to use vendor-specific codes for the foreseeable future in addition to that.

The reason I say this is that latency is of critical importance here, and many uses of this option will involve at least some vendor-specific information that needs to be exchanged during the discovery phase. Solving the discovery problem alone won't be enough. We need to be able to discover the other middlebox and communicate enough information during that initial round-trip to begin whatever additional processing the middleboxes need to perform. So, we'll be able to standardize the framework for doing the discovery, but not the details of what appears in the options which are exchanged, at least not for all of our current use cases.

If this is really the case, it would be a mistake to limit the total number of type codes across all vendors to 256. We'd basically be repeating the mistake that led to this effort in the first place, where TCP options as a whole have a space of 256 options and we're currently using multiple of those to solve this problem.
-- 
Ron Frederick
[e-mail]