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

[Andrew Knutsen <andrew.knutsen at bluecoat.com>]

   I'll try to respond to all the issues raised today in this message:

Caitlin Bestler wrote:
> What is not clear is why the probe is based on OUI-specific secret 
> handshakes.

   This draft represents an effort to move technology which is 
currently shipping from at least three vendors toward standardization. 
The handshakes are currently not only "secret", but use invalid option 
kinds.  This draft allows movement away from the invalid kinds; getting 
all vendors to disclose and agree on the rest is future effort, which 
would result in the OUI-less IANA-registered types.  We could have put 
this "history" in the draft, but it didn't seem appropriate.  I did 
include it in the last announcement.

> 1) Why not simply probe for "first middlebox that sees this once the 
> TTL is less than or equal to X"?
>      That would enable discovering all middleboxes that understood 
> this option, no matter who
>      made them. Once identified SNMP can be used to obtain vendor 
> specific information.

   - Generally, you want to probe for a specific type of device, which 
will pair with the originator.

   - Performance is a very important factor here.  SNMP adds delay, 
just like the other existing alternates mentioned in the draft.

> 2) If vendor X has *two* middleboxes on the path from A to B, is there 
> any way to control
>      who answers?

   This would be specific to the device type, presumably based on the 
target data, although other info like the TTL could of course be used. I 
don't think there is anything in the draft saying a node cannot both 
respond to the probe and send it farther along, or even modify the 
target data and send it along. These actions would be defined with the 
device type registration.

> One further question, what is the correct handling of redundant 
> SYN-ACKs from different
> sources? This could happen if a middle-box takes longer than the 
> initiator anticipates
> and the retransmission follows a different path due to intermittent 
> failures and/or
> load balancing.

   This is a good question, however I think its best considered an 
endpoint issue, ie, not one requiring more protocol. All existing 
implementations (from the three or more vendors I mentioned above) 
should be prepared to handle this. Without saying anything specific, I 
will say we've never had a bug reported because of this situation ;-).

Andrew