From andrew.knutsen@bluecoat.com Wed Jun 8 14:44:22 2011 Return-Path: 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 BBB0E11E80A0 for ; Wed, 8 Jun 2011 14:44:22 -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 c+z2MQZnJ41V for ; Wed, 8 Jun 2011 14:44:22 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id 584A711E809B for ; Wed, 8 Jun 2011 14:44:19 -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 p58LiIDK009753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Jun 2011 14:44:18 -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 14:44:13 -0700 From: "Knutsen, Andrew" To: "middisc@ietf.org" Thread-Topic: TCP middlebox option requirements Thread-Index: AcwmI0zFfltUolLcSMitiuc7V9sSUA== Date: Wed, 8 Jun 2011 21:44:12 +0000 Message-ID: <974FE049BD0F2E4188567FAD99DEF03301B4BD@PWSVL-EXCMBX-01.internal.cacheflow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 21:44:22 -0000 While we're waiting for any more details that may help us reach consensu= s 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 as= signing 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 p= roblematic (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 thin= g which is perhaps fundamental: Do we anticipate any use of this option where the intended consumer of t= he option is the actual host at the destination IP address? (Excepting res= ponses). To me, this is a pretty clear discriminator for a "middlebox option". M= y 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 ananth@cisco.com Wed Jun 8 14:57:11 2011 Return-Path: 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 3048C21F853C for ; Wed, 8 Jun 2011 14:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.436 X-Spam-Level: X-Spam-Status: No, score=-10.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Uyq-trUZPFNz for ; Wed, 8 Jun 2011 14:57:10 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 532D721F843E for ; Wed, 8 Jun 2011 14:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=1856; q=dns/txt; s=iport; t=1307570230; x=1308779830; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=/rUkG4gyZHUPv78VFE6yGOEU5wAMyMvDKhjR1VHDzUw=; b=fotBQsn/LubOWOPSYrlesbTuKA6LXjso3hVRpzTlJyUJCsVdhPq2F5n8 M+Cj+rTV4hMZeIuA5coUCPPnsEIFBGOgzV1QnJlgnTkH8/zzLdhEFbbiJ oFHAcCHnr/ek2YUQbrN0IKLk9aSXIRfOiKrGW++v5j92aMEvScnD8S5jg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBAOvv702rRDoG/2dsb2JhbABTl0aOb3eIcaBcnXyGIwSGf45yixU X-IronPort-AV: E=Sophos;i="4.65,340,1304294400"; d="scan'208";a="333057397" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2011 21:56:53 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p58Lurhj031819; Wed, 8 Jun 2011 21:56:53 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 14:56:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 14:56:49 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580CEE513B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <974FE049BD0F2E4188567FAD99DEF03301B4BD@PWSVL-EXCMBX-01.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: AcwmI0zFfltUolLcSMitiuc7V9sSUAAAn9xA References: <974FE049BD0F2E4188567FAD99DEF03301B4BD@PWSVL-EXCMBX-01.internal.cacheflow.com> From: "Anantha Ramaiah (ananth)" To: "Knutsen, Andrew" , X-OriginalArrivalTime: 08 Jun 2011 21:56:53.0134 (UTC) FILETIME=[F9F8B2E0:01CC2626] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 21:57:11 -0000 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 >=20 >=20 > 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). >=20 > There are a few details to be considered, but I'm curious about one > thing which is perhaps fundamental: >=20 > 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. >=20 > 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 >=20 > Andrew >=20 > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc From ron.frederick@bluecoat.com Wed Jun 8 18:49:05 2011 Return-Path: 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 ; 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 ; 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 ; 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" To: "Anantha Ramaiah (ananth)" Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: AcwmI0zFfltUolLcSMitiuc7V9sSUAAAn9xAABcRWYA= Date: Thu, 9 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: "" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 :- >=20 >> -----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 >>=20 >>=20 >> 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). >>=20 >> There are a few details to be considered, but I'm curious about one >> thing which is perhaps fundamental: >>=20 >> 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). >=20 > 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 e= ither the client or server, at least for uses related to WAN Optimization. = In some cases, one could imagine this option actually being used directly b= etween a client and server with no middlebox involved at all. From that per= spective, trying to call this a "middlebox option" isn't technically correc= t. The idea here is really to advertise additional optional capabilities wh= ich can be implemented by either end hosts or middleboxes which are along t= he path. When two boxes along the path both support one of these capabiliti= es, 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 al= so not intended for every router on the path (where an IP option would be m= ore appropriate). To take advantage of a capability advertised this way, th= e 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. --=20 Ron Frederick ronf@bluecoat.com From andrew.knutsen@bluecoat.com Thu Jun 9 11:56:17 2011 Return-Path: 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 ; 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 ; 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 ; 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 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" 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: "" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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