Re: [middisc] TCP middlebox option requirements

[Mark Day <[e-mail]>]

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.

--Mark