Re: [middisc] TCP middlebox option requirements

[Ron Frederick <[e-mail]>]

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
[e-mail]