Re: [middisc] TCP middlebox option requirements

"Frederick, Ron" <ron.frederick@bluecoat.com> Thu, 09 June 2011 01:49 UTC

Return-Path: <ron.frederick@bluecoat.com>
X-Original-To: middisc@ietfa.amsl.com
Delivered-To: middisc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BD111E8084 for <middisc@ietfa.amsl.com>; Wed, 8 Jun 2011 18:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qLef0AJGyam for <middisc@ietfa.amsl.com>; Wed, 8 Jun 2011 18:49:04 -0700 (PDT)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8342011E80CD for <middisc@ietf.org>; Wed, 8 Jun 2011 18:49:04 -0700 (PDT)
Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p591n4aQ027843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jun 2011 18:49:04 -0700 (PDT)
Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0255.000; Wed, 8 Jun 2011 18:48:58 -0700
From: "Frederick, Ron" <ron.frederick@bluecoat.com>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Thread-Topic: [middisc] TCP middlebox option requirements
Thread-Index: AcwmI0zFfltUolLcSMitiuc7V9sSUAAAn9xAABcRWYA=
Date: Thu, 09 Jun 2011 01:48:57 +0000
Message-ID: <84A68B92-562A-4A4C-A03F-08730083456B@bluecoat.com>
References: <974FE049BD0F2E4188567FAD99DEF03301B4BD@PWSVL-EXCMBX-01.internal.cacheflow.com> <0C53DCFB700D144284A584F54711EC580CEE513B@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC580CEE513B@xmb-sjc-21c.amer.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.2.2.106]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <80336A80881D5246B7FDF3A7248F83B8@bluecoat.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<middisc@ietf.org>" <middisc@ietf.org>
Subject: Re: [middisc] TCP middlebox option requirements
X-BeenThere: middisc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussions on TCP option for middlebox discovery." <middisc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/middisc>, <mailto:middisc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/middisc>
List-Post: <mailto:middisc@ietf.org>
List-Help: <mailto:middisc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/middisc>, <mailto:middisc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2011 01:49:05 -0000

On Jun 8, 2011, at 2:56 PM, Anantha Ramaiah (ananth) wrote:
> 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: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On
>> Behalf Of Knutsen, Andrew
>> Sent: Wednesday, June 08, 2011 2:44 PM
>> To: middisc@ietf.org
>> 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).
>> 
>>   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).
> 
> 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.

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
ronf@bluecoat.com