Subject: Re: [middisc] TCP middlebox option requirements

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Jun 2010 12:21:41 +0300

Hi,

On 2010-5-28, at 1:29, Andrew Knutsen wrote:
>     What I was thinking is simply that there would be a stipulation (in the option spec) that when an entity applied for a vendor code that they'd use it for the specified purpose.  Ie, not for some other purpose, or just to sit on. Then, if the option was seen "in the wild" being used inappropriately, the vendor would have an interest in not doing that since they'd be publicly breaking their agreement.  No police (unless you count the vendor itself), just peer pressure, so to speak. 

that seems like a reasonable approach. From the IETF perspective, we'd want to assign an option number for middlebox discovery techniques, with enough flexibility in the description that the option could be shared by and work with the techniques different vendors employ. But we wouldn't want to allow arbitrary flexibility, so that the option could be used for any vendor-specific purpose.

Obviously, the IETF cannot police whether implementations/vendors will comply. (We can't even police if folks are using option numbers without proper assignment...) The best we can hope for is, as Andrew says, some sort of community fingerpointing if a vendor disregards and goes beyond the stated use case of the option (middlebox discovery).

Lars

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 01 Jun 2010 11:54:40 -0700

What about the OUI option, which would bypass the vendor code 
assignment (although whoever used it could be assumed to be aware of the 
spec for the option kind)?

Andrew

---

From: Ron Frederick <[email-masked]>
Date: Thu, 10 Jun 2010 10:29:11 -0700

> Obviously, the IETF cannot police whether implementations/vendors will comply. (We can't even police if folks are using option numbers without proper assignment...) The best we can hope for is, as…

I agree that we'd want some kind of accountability here, and I think the OUI would give us that just as much accountability as some new IANA registry of vendor codes for this option would. For me, it just comes down to the question of how much space we think we can afford.

In our original proposal, standard versions of this option would cost 2 bytes for the type code and vendor-specific versions would cost 5 bytes. While we could squeeze things down to a single byte type code and single byte vendor ID to make both versions fit in 2 bytes, this severely limits the amount of room we have to grow either of those spaces if the option gets a lot of use. It all comes down to how many different applications we think will eventually find value in this.
-- 
Ron Frederick
[email-masked]

---

From: Ron Frederick <[email-masked]>
Date: Thu, 10 Jun 2010 10:37:03 -0700

On May 28, 2010, at 9:17 AM, Mark Day wrote:
> 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.
>  
> I may have inadvertently created this concern, and if so I’d like to clarify my position to see if we can get it off the table.
>  
> I objected to the requirement for restriction of options to headers with the SYN bit set, since Riverbed products do use options in other cases.  However, I don’t believe there is any case in which we start adding options in the middle of a stream.  Sometimes an option appears only on a few packets at the start of a stream and is no longer used after some number of exchanges; in other cases, an option is used for the entire duration of a connection. I don’t believe that we have any need for an option to suddenly appear midstream on a flow that did not previously use it.
>  
> As is correctly noted, it would not be reasonable to assume that a packet with a newly-added option will still be able to reach the destination, since something along the route may suppress it. If the middlebox had added a new option and was not receiving acks from the other side, it’s not clear what the right behavior would be. When I think it through a little, all of the choices seem problematic. It seems like a whole can of worms that is best avoided.

Thanks for the clarification, Mark. This makes perfect sense, and I see no problem with continuing to allow the option to be sent for all data packets on the connection.

As for the case where the option is sent only for a few packets at the start of a stream and no longer used after some number of exchanges, I guess I can see how to make that work. In that case, it seems like each side would need to keep retransmitting the option data it was sending to the other side in all data packets until it received a positive acknowledgement in the return option from the other side that the data had been received. This would happen independently in each of the two directions, if both sides wanted to send additional option data in packets after the SYN/SYN-ACK. Once the acknowledgement was received in either direction, that direction could stop retransmitting the corresponding option data.
-- 
Ron Frederick
[email-masked]