Subject: [middisc] TCP middlebox option requirements

From: "Knutsen, Andrew" <[email-masked]>
Date: Wed, 8 Jun 2011 21:44:12 +0000

While we're waiting for any more details that may help us reach consensus on the format of the option, I've been thinking about the text we'll use to restrict its uses.  This text would be guidance to the IANA (or other assigning authority) to determine when to assign a vendor or standard code.  It could also be used for policing after assignment, but thats a bit more problematic (although that's all that would be possible in the OUI/PEN case).

   There are a few details to be considered, but I'm curious about one thing which is perhaps fundamental:

   Do we anticipate any use of this option where the intended consumer of the option is the actual host at the destination IP address?  (Excepting responses).

   To me, this is a pretty clear discriminator for a "middlebox option".  My impression is that we want a minimum of requirements in the text, so that we can all use this for the things we need it for; however we also want to make sure its not a "catch-all", like the old SNAP option.

Andrew

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 8 Jun 2011 14:56:49 -0700

I am in the process of forming a outline for the new draft which I'll be
sharing soon. That said, response to the comment inline :-

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Knutsen, Andrew
> Sent: Wednesday, June 08, 2011 2:44 PM
> To: [email-masked]
> Subject: [middisc] TCP middlebox option requirements
> 
> 
>    While we're waiting for any more details that may help us reach
> consensus on the format of the option, I've been thinking about the
> text we'll use to restrict its uses.  This text would be guidance to
> the IANA (or other assigning authority) to determine when to assign a
> vendor or standard code.  It could also be used for policing after
> assignment, but thats a bit more problematic (although that's all that
> would be possible in the OUI/PEN case).
> 
>    Do we anticipate any use of this option where the intended consumer
> of the option is the actual host at the destination IP address?
> (Excepting responses).

I would think the answer is : yes. But, we want to accommodate such an
use case if possible without burning a lot of cycles and making
modifications. I believe this shouldn't be a problem.

> 
>    To me, this is a pretty clear discriminator for a "middlebox
> option".  My impression is that we want a minimum of requirements in
> the text, so that we can all use this for the things we need it for;
> however we also want to make sure its not a "catch-all", like the old
> SNAP option.

Agreed.

-Anantha
> 
> Andrew
> 
> _______________________________________________
> middisc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/middisc

---

From: "Frederick, Ron" <[email-masked]>
Date: Thu, 9 Jun 2011 01:48:57 +0000

> modifications. I believe this shouldn't be a problem.

I agree that there might be cases where one of the two endpoints could be either the client or server, at least for uses related to WAN Optimization. In some cases, one could imagine this option actually being used directly between a client and server with no middlebox involved at all. From that perspective, trying to call this a "middlebox option" isn't technically correct. The idea here is really to advertise additional optional capabilities which can be implemented by either end hosts or middleboxes which are along the path. When two boxes along the path both support one of these capabilities, the capability can be exercised. This is true regardless of whether the boxes supporting the capability are middleboxes or end hosts.

The key difference between this type of option and traditional TCP options is that the option is not intended ONLY for the end hosts. However, it's also not intended for every router on the path (where an IP option would be more appropriate). To take advantage of a capability advertised this way, the two boxes involved will likely end up with an independent TCP connection between them, and other TCP connections (where needed) to communicate with the original end hosts.
-- 
Ron Frederick
[email-masked]

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 09 Jun 2011 11:56:10 -0700

> The key difference between this type of option and traditional TCP options is that the option is not intended ONLY for the end hosts. However, it's also not intended for every router on the path (w…

    Good point.  So perhaps the option SHOULD be useful to an 
intermediate, but MAY be interpreted at the endpoint...

Andrew