Re: [middisc] TCP middlebox option requirements

[Ron Frederick <[e-mail]>]

On May 27, 2010, at 10:18 AM, Knutsen, Andrew wrote:
> Just clarifying something for Ron...
>  
> The single byte I'm proposing would be just the vendor.  There would probably be a type in the vendor-specific info.
>  
> Reserving a vendor code for a following OUI sounds good.  Hopefully never needed, since I hope all this is standardized before there are that many players.

This runs the risk of creating two tiers of vendors (those who get in early and get one-byte assignments and those who don't and are forced to use the OUI escape hatch vendor ID). However, I agree that this would be one way to save space. If we assume that there's still a vendor-specific type code and we pack both the request/response flag and the type into a single byte rather than two bytes, we could basically save 3 bytes total. This would give us 254 vendors if we keep one vendor value for standard options and one for the OUI escape. Each vendor could have 127 options if they used the 'R' bit. Vendors would also be free to exclude the type code if they only wanted a single option, exclude the 'R' bit if they didn't need that, or even go up to a multi-byte type code if they needed more space (unlikely, I admit). The main question is how this vendor registration will be handled (see more below on this).

I'm also not sure I like the idea of trying to mix both vendor codes and standard option type codes into the same byte. While that would be a further 1 byte space savings for the standard options, that really seems to be overloading that single field too much.

Andrew also wrote:
> One issue I just remembered with the OUI, and I can't remember who brought it up, is that it opens the option to "safe" (but unsanctioned) use for arbitrary purposes by anyone with an OUI. With vendor codes, we can specify criteria for assignment, so the vendor would be breaking their agreement if they used it for other purposes.
> 
> It seems like this might be an IESG policy issue.  Lars, are you still here?


Who would perform this oversight? This gets into the points Anantha was raising:

> OUI as exists today is standardized and managed and provides unquiness. If we were to define a 1 byte vendor it, it has all issues which Ron mentioned below + the need for standardizing that space, I don't know who is going to manage allocation and maintenance of that field. I don't think IANA would do that.

I could potentially see IANA handling the registrations here, but I wouldn't expect them to be able to handle the approvals or do any checking on whether vendors were "breaking their agreement" in the way they used the option. To be honest, I'm not even sure I know what that means. What sort of criteria would we be looking for here? This doesn't seem like something we necessarily want to burden this process with.

Anantha also asked:
> I also wanted to understand the use case of having this option sent in the middle of the connection. FWIW TCP options as exisits today are either "negotiated" one time in the initial 3 way handshake (MSS, Window scale, SACK permitted etc.,) or sent on every packet (TCP MD5,  TIMESTAMP etc.,) On demand sendind of the option is something new, so is the concept of variable length TCP option (with the exception of SACK, which itself needs to agreed upon using SACK PERMITTED option during the 3 way HS.

Variable length options are nothing new. With the exception of the kind 0 & 1 single octet options representing the end of list and no-op, all TCP options have a "kind" byte and a "length" byte. While most options may happen to be a fixed length today, the length byte should allow us to support a variable length option with no additional effort.

Regarding sending options in the middle of a stream, I must admit that I'm still nervous about that, especially around how the middleboxes doing this will handle retransmissions of data packets originally sent with the option. However, I can see legitimate use cases for doing this, and I can see how an implementation could work if the options were just treated as essentially best-effort delivery with it being up to the specific middlebox implementation to handle any reliability concerns when sending such mid-stream options.
-- 
Ron Frederick
[e-mail]