Re: [middisc] TCP middlebox option requirements

Andrew Knutsen <andrew.knutsen@bluecoat.com> Thu, 09 June 2011 18:56 UTC

Return-Path: <andrew.knutsen@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 A8E9111E81E9 for <middisc@ietfa.amsl.com>; Thu, 9 Jun 2011 11:56:17 -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 Zt9jON5tOARu for <middisc@ietfa.amsl.com>; Thu, 9 Jun 2011 11:56:16 -0700 (PDT)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id D05A811E81D5 for <middisc@ietf.org>; Thu, 9 Jun 2011 11:56:16 -0700 (PDT)
Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p59IuGkT006388; Thu, 9 Jun 2011 11:56:16 -0700 (PDT)
Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jun 2011 11:56:10 -0700
Message-ID: <4DF1174A.8030705@bluecoat.com>
Date: Thu, 09 Jun 2011 11:56:10 -0700
From: Andrew Knutsen <andrew.knutsen@bluecoat.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Frederick, Ron" <ron.frederick@bluecoat.com>
References: <974FE049BD0F2E4188567FAD99DEF03301B4BD@PWSVL-EXCMBX-01.internal.cacheflow.com> <0C53DCFB700D144284A584F54711EC580CEE513B@xmb-sjc-21c.amer.cisco.com> <84A68B92-562A-4A4C-A03F-08730083456B@bluecoat.com>
In-Reply-To: <84A68B92-562A-4A4C-A03F-08730083456B@bluecoat.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Jun 2011 18:56:10.0917 (UTC) FILETIME=[E5EB6D50:01CC26D6]
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 18:56:17 -0000

On 6/8/2011 6:48 PM, Frederick, Ron wrote:
> 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.

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

Andrew