Re: [middisc] TCP middlebox option requirements

The size of any option is very limited. Only 40 bytes of the TCP header are available for options. It is not difficult to be in a situation where other options consume 20 bytes of the available space in the header, so I'd like to suggest that a realistic design goal for practical deployment is 20 bytes or less.  

The longest current Riverbed option usage does consume 20 bytes.  The bulk of that is 3 IPv4 addresses (12 bytes total), a port number (2 bytes), the option number (1 byte) and option length (1 byte). We also use a byte for a loop-detection mechanism. That leaves us only 3 bytes total for figuring out which vendor/version/message this is, as well as any other flags or data.  That's likely to be feasible (barely), but not at all straightforward.

If we don't focus ruthlessly on making the vendor-id piece as small as possible, there will be an increase of two kinds of avoidable inefficiency:

1. Situations where a single round-trip has to become two or more round trips. Rather than integrating the necessary coordination into the 3-way handshake, more messages have to be exchanged. In strict autodiscovery terms this doesn't much matter, but the most economically-significant current usage of autodiscovery is in WAN optimization, where there's a good likelihood that the network has high latency and an extra round trip is a concern.

2. Situations where the standardized autodiscovery mechanism fails entirely because there's no room left in the header for an option of that size. Especially on enterprise networks, this would probably prompt a fallback to smaller vendor-proprietary schemes rather than allowing autodiscovery to simply break. 

--Mark

-----Original Message-----
From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Andrew Knutsen
Sent: Friday, May 21, 2010 2:23 PM
To: middisc@ietf.org
Subject: Re: [middisc] TCP middlebox option requirements

    Thanks Ananth.

    One possibility that Jamshid and I talked about addresses concerns 
about using 3 bytes for the OUI. We could skip it (and the P bit), and 
break up the 15 bits or so of "device capability" into an IANA-assigned 
vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific 
type. There could be one or more "standard" vendor codes for 
multi-vendor interoperability (ie, IANA-assigned types), and an 
extension code if we run out of room.

    Perhaps we also need to define the requirements for getting a vendor 
code or a standard type -- for instance, we might not want any 
individual to be able to get a vendor code, since they are limited; and 
the standard types would need some documentation, but perhaps not as 
widely reviewed as for a top-level option kind.

Andrew

Anantha Ramaiah (ananth) wrote:
> Hi,
>    I am just taking the liberty to post the first email on this mailing
> list. During our last call there was talk about the requirements of this
> TCP option. From our pov, the following would be the general
> requirements of the TCP option.
>
>
> Reason for TCP option :
>
> - A standard TCP option is needed because every vendor cannot have one
> option for the same purpose of auto-discovery and capability exchange.
> By standardizing the TCP option, firewalls etc., are aware of this
> option and problems can be avoided.
>
> Requirements of this TCP option :
>
> - There has to be a vendor ID (OUI) which would identify the specific
> vendor. This is needed because every vendors option format is going to
> be 
> different.
>
> - Already existing non-standardized option numbers (TCP option 33,
> riverbed's options no's) for doing auto discovery should not be
> allocated for this new TCP option. This is to prevent any confusion.
>
> - The TCP option needs to be variable length to permit multiple option
> formats since the option size may vary depending on the vendor.
>
> - This TCP option should be advocated for use only by middleboxes.
>
>
> My guess is that these requirements may be common for all the vendors or
> there may be some additional requirements not covered by this post. In
> either case we can continue the discussion and come to some conclusions.
>
> -Anantha
> _______________________________________________
> middisc mailing list
> middisc@ietf.org
> https://www.ietf.org/mailman/listinfo/middisc
>   

_______________________________________________
middisc mailing list
middisc@ietf.org
https://www.ietf.org/mailman/listinfo/middisc