[tcpm] New version of TCP Option for Transparent Middlebox Discovery available
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[tcpm] New version of TCP Option for Transparent Middlebox Discovery available



A new version of the Transparent Middlebox Discovery option draft is available at <http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-02.txt>.

The following changes have been made:

- The security section has been updated.

- An API section has been added.

- Simultaneous open is addressed.

- The "device type" field has been renamed "device capability",
since a single device may respond to several kinds of discovery requests.

- Miscellaneous cleanup and clarifications.

Several changes were not made:

- Specific uses of the option, such as discovery for management
   purposes, are not addressed.  This information belongs in
   the specs for the individual device capabilities.

- This does need to be a TCP option, since it must follow the
   same path as the TCP connection handshake. This is already
   addressed in the draft.

- Performance is a requirement for this option.  If an extra roundtrip is
   required, the option will not be used. This is also already addressed in
   the draft.

In addition, we made a couple more changes which I wasn't able to post before the
pre-meeting deadline. They include:

- Options with length < 4 are addressed. The following text is included:

  Options with length less than 4 MUST be ignored.

- The issue of limited option space is addressed. The following text is included:

  There may be situations where other options are required in the SYN
  packet which do not leave enough room for all of the target data
  necessary for the desired device capability to be advertised. In
  these cases, a shorter alternate device capability may be defined
  which signals the request to further negotiate the capability after
  the handshake completes. This will impact performance by introducing
  an extra round-trip during connection set-up, but this may be the
  only way to perform the negotiation within the limited TCP option
  space available.


   Unfortunately, none of the authors will be attending Hiroshima.

Andrew





Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.