Subject: [middisc] TCP middlebox option requirements

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 20 May 2010 23:32:10 -0700

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

---

From: Andrew Knutsen <[email-masked]>
Date: Fri, 21 May 2010 11:23:06 -0700

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:
> _______________________________________________
> middisc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/middisc
>

---

From: Mark Day <[email-masked]>
Date: Mon, 24 May 2010 06:26:09 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Knutsen
Sent: Friday, May 21, 2010 2:23 PM
To: [email-masked]
Subject: Re: [middisc] TCP middlebox option requirements

    Thanks Ananth.

Andrew

---

From: Mark Day <[email-masked]>
Date: Mon, 24 May 2010 06:40:50 -0700

Two additional issues seem worth clarifying since I'm not sure how others would view them.

1. Are we concerned strictly with autodiscovery options, or are we attempting to understand the requirements for options usage generally among current symmetric middleboxes?  For example, Riverbed uses a different option for some forms of addressing information in situations after the two communicating peers have been established by autodiscovery.  It wouldn't surprise me to learn that other vendors have other similar schemes.

2. Don't we also need to consider requirements for autodiscovery options in IPv6 environments?  

In both cases, I can see a pragmatic argument for focusing narrowly vs. an architectural argument for considering broader issues. IPv4 autodiscovery is the clear existing interoperability/coexistence problem and may be solvable by simply agreeing on an option number and vendor id scheme, while the other areas might not yet have enough experience and implementations to justify a standard.  And yet it feels to me like we might solve one option-related problem just to trip across another similar one soon afterward.

--Mark

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

    Thanks Ananth.

Andrew

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 25 May 2010 17:28:25 -0700

It seems to me that if we do limit our goal here to agreeing on an 
option number and vendor ID scheme, we haven't really limited ourselves 
to autodiscovery except in the requirements we state for getting a 
vendor ID (ie, agreements on use). Mostly this would involve removing 
the requirement that the option only be present with the SYN bit. We 
added this requirement primarily due to concerns about reliable 
transmission, but in later discussions we came up with a midstream 
discovery requirement and mechanism where that isn't an issue, so I 
don't think we're particularly attached to it. Also, we probably don't 
have to require everyone to encode the vendor-specific type information 
in the same way.

   Another implication of that goal is that we wouldn't be making a 
standard per se; rather we'd be making a first step towards a set of 
standards.  Thats the purpose of the "P" bit in the current proposal, 
and the "standard vendor" codes in the proposal for removing the OUI in 
my message below. The idea is that as the technology matures, we can 
move towards a standard mechanism.

   I'm not familiar with IPv6 options, but at this point what we're 
doing sounds so simple it should work.

   I'm getting the impression that to make this alternate option useful 
to everyone here, we have to change the proposal in a few ways, including:

    1) Removing the OUI, and having a single byte of vendor code. The 
option format would be vendor-specific.
    2) Replacing the P bit with a "standard" vendor code or codes -- 
perhaps one code per interoperable option format.
    3) Removing the requirement that the option only be present with the 
SYN bit set.
    4) It sounds like the R bit may be redundant with other, more 
complex schemes already implemented by some vendors.

    This would mean the option format would only specify a single byte 
of vendor ID after the option length. We would need some stipulations on 
the option's use (making and maintaining tunnels, perhaps). Vendors 
would have to agree to these stipulations to get a code, so we aren't 
making a "catch-all" option.

    Opinions?

Andrew

---

From: Mark Day <[email-masked]>
Date: Tue, 25 May 2010 17:52:38 -0700

Specifying a single-byte vendor code, with some reserved "standard" value(s) of that byte, sounds good.  I also agree that we need to define what this is intended for so it doesn't become the all-purpose option.

As a practical matter the "t-word" (tunnel) may be problematic. Any of you who are not exposed to the competitive side of this market may find it mind-boggling, but there has been a lot of thrashing around on the topic of whether tunnels are evil and whether a given product does or doesn't use tunnels.  (Some of this has involved misunderstanding or mischaracterizing other vendors' products).  Accordingly it seems unwise to write a high-level generic statement of purpose in terms of establishing or maintaining "tunnels".

Can we say instead that this option is about discovering some other middlebox and maintaining communication with that discovered middlebox?

--Mark

From: Andrew Knutsen [mailto:[email-masked]]
Sent: Tuesday, May 25, 2010 8:28 PM
To: Mark Day
Cc: [email-masked]; Ron Frederick; Qing Li
Subject: Re: [middisc] TCP middlebox option requirements

    It seems to me that if we do limit our goal here to agreeing on an option number and vendor ID scheme, we haven't really limited ourselves to autodiscovery except in the requirements we state for getting a vendor ID (ie, agreements on use). Mostly this would involve removing the requirement that the option only be present with the SYN bit. We added this requirement primarily due to concerns about reliable transmission, but in later discussions we came up with a midstream discovery requirement and mechanism where that isn't an issue, so I don't think we're particularly attached to it. Also, we probably don't have to require everyone to encode the vendor-specific type information in the same way.

   Another implication of that goal is that we wouldn't be making a standard per se; rather we'd be making a first step towards a set of standards.  Thats the purpose of the "P" bit in the current proposal, and the "standard vendor" codes in the proposal for removing the OUI in my message below. The idea is that as the technology matures, we can move towards a standard mechanism.

   I'm not familiar with IPv6 options, but at this point what we're doing sounds so simple it should work.

   I'm getting the impression that to make this alternate option useful to everyone here, we have to change the proposal in a few ways, including:

    1) Removing the OUI, and having a single byte of vendor code. The option format would be vendor-specific.
    2) Replacing the P bit with a "standard" vendor code or codes -- perhaps one code per interoperable option format.
    3) Removing the requirement that the option only be present with the SYN bit set.
    4) It sounds like the R bit may be redundant with other, more complex schemes already implemented by some vendors.

    This would mean the option format would only specify a single byte of vendor ID after the option length. We would need some stipulations on the option's use (making and maintaining tunnels, perhaps). Vendors would have to agree to these stipulations to get a code, so we aren't making a "catch-all" option.

    Opinions?

Andrew

Mark Day wrote:

--Mark

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Andrew Knutsen

To: [email-masked]<mailto:[email-masked]>

    Thanks Ananth.

Andrew

Hi,

Reason for TCP option :

be

different.

-Anantha

middisc mailing list

[email-masked]<mailto:[email-masked]>

middisc mailing list

[email-masked]<mailto:[email-masked]>

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 25 May 2010 18:37:45 -0700

I agree with your concern about terminology.  I just spent about 6 
months trying to get this past TCPM, and although the word "tunnel" 
didn't raise (many) hairs, the idea of spoofing sure did...  And of 
course transparent tunnels, like proxies, are spoofed (more than once if 
the customer doesn't even want to see tunnels on their network ;-).  
Funny thing is I bet almost everyone on that list uses spoofed 
connections every day.  Its not our job to help them with their denial 
though.

    If you think we should use the current draft as a starting point, 
please let us know if you think any part of it is "problematic". I had 
to make it somewhat explicit in some areas to give folks on the list 
some context, but we don't have to keep it all.  I don't have a problem 
with adding the "maintaining communication" text.

Andrew

Mark Day wrote:
>
> Specifying a single-byte vendor code, with some reserved "standard" 
> value(s) of that byte, sounds good.  I also agree that we need to 
> define what this is intended for so it doesn't become the all-purpose 
> option.
>
>  
>
> As a practical matter the "t-word" (tunnel) may be problematic. Any of 
> you who are not exposed to the competitive side of this market may 
> find it mind-boggling, but there has been a lot of thrashing around on 
> the topic of whether tunnels are evil and whether a given product does 
> or doesn't use tunnels.  (Some of this has involved misunderstanding 
> or mischaracterizing other vendors' products).  Accordingly it seems 
> unwise to write a high-level generic statement of purpose in terms of 
> establishing or maintaining "tunnels".
>
>  
>
> Can we say instead that this option is about discovering some other 
> middlebox and maintaining communication with that discovered middlebox?
>
>  
>
> --Mark
>
>  
>
>  
>
> *From:* Andrew Knutsen [mailto:[email-masked]]
> *Sent:* Tuesday, May 25, 2010 8:28 PM
> *To:* Mark Day
> *Cc:* [email-masked]; Ron Frederick; Qing Li
> *Subject:* Re: [middisc] TCP middlebox option requirements
>
>  
>
>
> option number and vendor ID scheme, we haven't really limited 
> ourselves to autodiscovery except in the requirements we state for 
> getting a vendor ID (ie, agreements on use). Mostly this would involve 
> removing the requirement that the option only be present with the SYN 
> bit. We added this requirement primarily due to concerns about 
> reliable transmission, but in later discussions we came up with a 
> midstream discovery requirement and mechanism where that isn't an 
> issue, so I don't think we're particularly attached to it. Also, we 
> probably don't have to require everyone to encode the vendor-specific 
> type information in the same way.
>
> and the "standard vendor" codes in the proposal for removing the OUI 
> in my message below. The idea is that as the technology matures, we 
> can move towards a standard mechanism.
>
>    I'm getting the impression that to make this alternate option 
> useful to everyone here, we have to change the proposal in a few ways, 
> including:
>
> of vendor ID after the option length. We would need some stipulations 
> on the option's use (making and maintaining tunnels, perhaps). Vendors 
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Andrew Knutsen
> To: [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>

---

From: Ron Frederick <[email-masked]>
Date: Tue, 25 May 2010 17:51:39 -0700

>     This would mean the option format would only specify a single byte of vendor ID after the option length. We would need some stipulations on the option's use (making and maintaining tunnels, per…

[Ron] A single byte for vendor ID clearly will not scale. There can easily be more than 256 vendors our there who may eventually want to use this option. I don't see any obvious way to do better space-wise than what we proposed with the OUI if we want this to be truly extensible to support all possible vendors.

Regarding the P bit, I don't really understand what you mean. We could have a single vendor code value for all the standard extensions, but we'd still need another byte for which option it was. If we burn a vendor code point for each interoperable option, we'd have even fewer code points left to allow vendor extensibility. If we think we can live with only 127 possible options (both for standard options and for each vendor), we could potentially shorten the type field from 2 bytes to 1 byte, which would then become 4 bytes when you add the OUI when the P bit is set, but I'm not sure the single byte of savings we get from that is really worth the flexibility we lose by dropping from 32K options per vendor to 127. Both of these numbers drop by a factor of 2 if we keep the R bit, which makes it even more of a poor choice.

I'm ok with dropping the requirement that these options are only sent on the SYN and SYN-ACK, but I would prefer to see an example of sending such an option mid-stream and some text which describes the known issues with trying to send an option in such an unsyncrhonized way.

Regarding the R bit, I could potentially see folding that into the vendor-specific data, but I would expect pretty much everyone to need to deal with this issue, so it seems like it would be best if we had a single general mechanism which did so.

-- 
Ron Frederick
[email-masked]

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 25 May 2010 22:59:24 -0700

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 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.
 
-Anantha

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ron Frederick
	Sent: Tuesday, May 25, 2010 5:52 PM
	To: Andrew Knutsen
	Cc: Ron Frederick; [email-masked]
	Subject: Re: [middisc] TCP middlebox option requirements

		    It seems to me that if we do limit our goal here to
agreeing on an option number and vendor ID scheme, we haven't really
limited ourselves to autodiscovery except in the requirements we state
for getting a vendor ID (ie, agreements on use). Mostly this would
involve removing the requirement that the option only be present with
the SYN bit. We added this requirement primarily due to concerns about
reliable transmission, but in later discussions we came up with a
midstream discovery requirement and mechanism where that isn't an issue,
so I don't think we're particularly attached to it. Also, we probably
don't have to require everyone to encode the vendor-specific type
information in the same way.
		
		   Another implication of that goal is that we wouldn't
be making a standard per se; rather we'd be making a first step towards
a set of standards.  Thats the purpose of the "P" bit in the current
proposal, and the "standard vendor" codes in the proposal for removing
the OUI in my message below. The idea is that as the technology matures,
we can move towards a standard mechanism.
		
		   I'm not familiar with IPv6 options, but at this point
what we're doing sounds so simple it should work.
		
		   I'm getting the impression that to make this
alternate option useful to everyone here, we have to change the proposal
in a few ways, including:
		
		    1) Removing the OUI, and having a single byte of
vendor code. The option format would be vendor-specific.
		    2) Replacing the P bit with a "standard" vendor code
or codes -- perhaps one code per interoperable option format.
		    3) Removing the requirement that the option only be
present with the SYN bit set.
		    4) It sounds like the R bit may be redundant with
other, more complex schemes already implemented by some vendors.
		
		    This would mean the option format would only specify
a single byte of vendor ID after the option length. We would need some
stipulations on the option's use (making and maintaining tunnels,
perhaps). Vendors would have to agree to these stipulations to get a
code, so we aren't making a "catch-all" option.
		
		    Opinions?

	
	[Ron] A single byte for vendor ID clearly will not scale. There
can easily be more than 256 vendors our there who may eventually want to
use this option. I don't see any obvious way to do better space-wise
than what we proposed with the OUI if we want this to be truly
extensible to support all possible vendors.

	Regarding the P bit, I don't really understand what you mean. We
could have a single vendor code value for all the standard extensions,
but we'd still need another byte for which option it was. If we burn a
vendor code point for each interoperable option, we'd have even fewer
code points left to allow vendor extensibility. If we think we can live
with only 127 possible options (both for standard options and for each
vendor), we could potentially shorten the type field from 2 bytes to 1
byte, which would then become 4 bytes when you add the OUI when the P
bit is set, but I'm not sure the single byte of savings we get from that
is really worth the flexibility we lose by dropping from 32K options per
vendor to 127. Both of these numbers drop by a factor of 2 if we keep
the R bit, which makes it even more of a poor choice.

	I'm ok with dropping the requirement that these options are only
sent on the SYN and SYN-ACK, but I would prefer to see an example of
sending such an option mid-stream and some text which describes the
known issues with trying to send an option in such an unsyncrhonized
way.

	Regarding the R bit, I could potentially see folding that into
the vendor-specific data, but I would expect pretty much everyone to
need to deal with this issue, so it seems like it would be best if we
had a single general mechanism which did so.

		Mark Day wrote: 

			Two additional issues seem worth clarifying
since I'm not sure how others would view them.
			
			1. Are we concerned strictly with autodiscovery
options, or are we attempting to understand the requirements for options
usage generally among current symmetric middleboxes?  For example,
Riverbed uses a different option for some forms of addressing
information in situations after the two communicating peers have been
established by autodiscovery.  It wouldn't surprise me to learn that
other vendors have other similar schemes.
			
			2. Don't we also need to consider requirements
for autodiscovery options in IPv6 environments?  
			
			In both cases, I can see a pragmatic argument
for focusing narrowly vs. an architectural argument for considering
broader issues. IPv4 autodiscovery is the clear existing
interoperability/coexistence problem and may be solvable by simply
agreeing on an option number and vendor id scheme, while the other areas
might not yet have enough experience and implementations to justify a
standard.  And yet it feels to me like we might solve one option-related
problem just to trip across another similar one soon afterward.
			
			--Mark
			
			-----Original Message-----
			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Andrew Knutsen
			Sent: Friday, May 21, 2010 2:23 PM
			To: [email-masked]
			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

				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.

				- 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

	-- 
	Ron Frederick
	[email-masked]

---

From: Mark Day <[email-masked]>
Date: Wed, 26 May 2010 20:28:00 -0700

I may be confused about what we expect will be the future developments in this space, but it's not obvious to me that we need to support more than 256 vendors.  I suppose the key question here is what we mean by "eventually." I thought this option-number reconciliation-and-rationalization was envisioned as a first step toward taking one (or a small number) of the "vendor" codes and using them as a basis for a standardized discovery protocol.  I'm not meaning that this particular group should do it, and certainly not that we should try to do it right now - but I did think that was a shared goal for some point in the future.

We currently have a handful of different proprietary discovery protocols that we are expecting to reconcile at the level of allowing them to multiplex a single consistent option code.  Do we really think that we'll have hundreds of additional discovery protocols between now and when there is agreement on some kind of open-standard discovery protocol(s)?  I just don't see that as a realistic concern, but perhaps I'm misunderstanding.

--Mark

---

From: Ron Frederick <[email-masked]>
Date: Thu, 27 May 2010 09:43:31 -0700

On May 26, 2010, at 8:28 PM, Mark Day wrote:

> I may be confused about what we expect will be the future developments in this space, but it’s not obvious to me that we need to support more than 256 vendors.  I suppose the key question here is what we mean by “eventually.” I thought this option-number reconciliation-and-rationalization was envisioned as a first step toward taking one (or a small number) of the “vendor” codes and using them as a basis for a standardized discovery protocol.  I’m not meaning that this particular group should do it, and certainly not that we should try to do it right now – but I did think that was a shared goal for some point in the future.
>  
> We currently have a handful of different proprietary discovery protocols that we are expecting to reconcile at the level of allowing them to multiplex a single consistent option code.  Do we really think that we’ll have hundreds of additional discovery protocols between now and when there is agreement on some kind of open-standard discovery protocol(s)?  I just don’t see that as a realistic concern, but perhaps I’m misunderstanding.

My expectation here is that this option will provide a standard way for all of the current proprietary schemes to share a single TCP option, and over time there will be specific use cases where middleboxes can interoperate with one another and switch to one of the "public" type codes which get defined within this framework, but there would continue to be good reason to use vendor-specific codes for the foreseeable future in addition to that.

The reason I say this is that latency is of critical importance here, and many uses of this option will involve at least some vendor-specific information that needs to be exchanged during the discovery phase. Solving the discovery problem alone won't be enough. We need to be able to discover the other middlebox and communicate enough information during that initial round-trip to begin whatever additional processing the middleboxes need to perform. So, we'll be able to standardize the framework for doing the discovery, but not the details of what appears in the options which are exchanged, at least not for all of our current use cases.

If this is really the case, it would be a mistake to limit the total number of type codes across all vendors to 256. We'd basically be repeating the mistake that led to this effort in the first place, where TCP options as a whole have a space of 256 options and we're currently using multiple of those to solve this problem.
-- 
Ron Frederick
[email-masked]

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Thu, 27 May 2010 11:52:52 -0500

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Ron Frederick
>Sent: Thursday, May 27, 2010 12:44 PM
>To: Mark Day
>Cc: [email-masked]
> ...
>If this is really the case, it would be a mistake to limit the total
>number of type codes across all vendors to 256. We'd basically be
>repeating the mistake that led to this effort in the first place, where
>TCP options as a whole have a space of 256 options and we're currently
>using multiple of those to solve this problem.

I don't have skin in the game, but on reading this thread, my
thought was that it's probably possible to use a single byte,
but define one codepoint (like 0xFF) to mean "use a full OUI
which follows".  This way you can start with using a single
byte given the relatively small number of vendors today, and
have a way to accommodate larger numbers in the future, if
the need arises.

This only works if the means of extending to a full OUI is
part of the base specification and everyone has to support
it, otherwise there are backwards-compatibility issues when
someone tries to use it in the future.

--
Wes Eddy
MTI Systems

---

From: "Knutsen, Andrew" <[email-masked]>
Date: Thu, 27 May 2010 10:18:28 -0700

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.
 
Andrew

From: Ron Frederick [mailto:[email-masked]]
Sent: Thu 5/27/2010 9:43 AM
To: Mark Day
Cc: Knutsen, Andrew; [email-masked]; Li, Qing
Subject: Re: [middisc] TCP middlebox option requirements

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 27 May 2010 12:59:28 -0700

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?

Andrew

---

From: Ron Frederick <[email-masked]>
Date: Thu, 27 May 2010 14:43:28 -0700

> 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
[email-masked]

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 27 May 2010 15:29:17 -0700

Ron Frederick wrote:
>> 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.
>>
>> 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.

    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.

    Of, course, if we went with the OUI, the owner of that OUI would be 
responsible for breaking the spec if the option was used 
inappropriately. However I've picked up concerns that we need a bit more 
accountability.

Andrew

---

From: Mark Day <[email-masked]>
Date: Fri, 28 May 2010 09:17:46 -0700

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