Re: [middisc] TCP middlebox option requirements
"Anantha Ramaiah (ananth)" <ananth@cisco.com> Tue, 24 May 2011 22:10 UTC
Return-Path: <ananth@cisco.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 87D3BE07DE for <middisc@ietfa.amsl.com>; Tue, 24 May 2011 15:10:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.059
X-Spam-Level:
X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 ZG2ayHN5teaH for <middisc@ietfa.amsl.com>; Tue, 24 May 2011 15:09:57 -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 71C4DE07A7 for <middisc@ietf.org>; Tue, 24 May 2011 15:09:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=13689; q=dns/txt; s=iport; t=1306274997; x=1307484597; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=VzmHc+0onHM9yDbW5whGYJ9js6RdwmZuTg3+ueaU4sw=; b=T0fsPPeIprHrB7+d1+vP6Tttalo5HDTv1eS1DiaaM57PriE2Rj2M0tJr iKB7FL9B//irYueBuWOUCh1qxGty8WcAHo6ecmSsVyLxN9nUAxP2JZAWq ssPVZXbFareG1bHSh6UGE6D/USt0L2w/HnQYJqhCpIVlUF/h84DNyrIxh g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAAAGos3E2rRDoI/2dsb2JhbACXZAGORHeIcKFgnXeDFhqCawSGVo4GimQ
X-IronPort-AV: E=Sophos;i="4.65,263,1304294400"; d="scan'208";a="322795655"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 24 May 2011 22:09:56 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4OM9ujn016415; Tue, 24 May 2011 22:09:56 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 15:09:56 -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: Tue, 24 May 2011 15:09:55 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC580CCD61AE@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <4DDC26D1.6010003@bluecoat.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [middisc] TCP middlebox option requirements
Thread-Index: AcwaW9dvfWcBOOfbTxCIMPJPsmIpvgAAzhew
References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADAB3597@MAILBOXES2.nbttech.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D3D6@MAILBOXES2.nbttech.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com><C304DB494AC0C04C87C6A6E2FF5603DB47E64A333F@NDJSSCC01.ndc.nasa.gov> <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> <0C53DCFB700D144284A584F54711EC580CCD5F61@xmb-sjc-21c.amer.cisco.com> <4DDC162E.5000005@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD6121@xmb-sjc-21c.amer.cisco.com> <4DDC1B93.7010605@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD613F@xmb-sjc-21c.amer.cisco.com> <4DDC26D1.6010003@bluecoat.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: Andrew Knutsen <andrew.knutsen@bluecoat.com>
X-OriginalArrivalTime: 24 May 2011 22:09:56.0845 (UTC) FILETIME=[50E741D0:01CC1A5F]
Cc: 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: Tue, 24 May 2011 22:10:17 -0000
> -----Original Message----- > From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] > Sent: Tuesday, May 24, 2011 2:45 PM > To: Anantha Ramaiah (ananth) > Cc: David Harrington; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; > Ron Frederick; Mark Day; middisc@ietf.org > Subject: Re: [middisc] TCP middlebox option requirements > > > I also think having a full 0 byte for standard types is wasteful. > So what you're suggesting is using the vendor byte for three bits of > standard type or 5 bits of vendor ID, right? Yes. > And if there is a 33rd vendor, they have to use the 24-bit ID? My feeling is that there won't be 33 vendors doing WAN opt solutions and the need to do option insertion for the same purpose. > > Two alternatives have occurred to me: > > - A bit in the vendor byte, indicating whether the byte is a > vendor > or a standard type. Both get 7 bits. This is what I meant below when I mentioned MSB for demux. > The objection to this was it might be hard to parse in hardware. Agreed, I thought about that as well. > > - Allocating standard types out of the same 8-bit space as the > vendor IDs. Well even then you need to sub-divide the space otherwise how else you would distinguish between them. -Anantha > > On 5/24/2011 2:02 PM, Anantha Ramaiah (ananth) wrote: > > That may be ok, but the issue is, we are using 1 byte (vendor ID = 0) > > for explicitly stating that it is a standard type and there can be > need > > for multiple standard types and then one needs to have sub-type to > cater > > to multiple use cases. IMO, this is wastage of TCP option bits. > > > > -Anantha > > > >> -----Original Message----- > >> From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] > >> Sent: Tuesday, May 24, 2011 1:57 PM > >> To: Anantha Ramaiah (ananth) > >> Cc: David Harrington; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE > CORP]; > >> Ron Frederick; Mark Day; middisc@ietf.org > >> Subject: Re: [middisc] TCP middlebox option requirements > >> > >> > >> If you don't need a vendor code, that means its a standard > type, > >> which has vendor ID 0 in the current proposal. > >> > >> Andrew > >> > >> On 5/24/2011 1:46 PM, Anantha Ramaiah (ananth) wrote: > >>> Andrew, > >>> My primary motivation here was to accommodate other possible > >> use > >>> cases and at the same time be very sensitive to TCP option bits. > >> Hence I > >>> thought we could sub-divide the vendor field into 2 pieces. Instead > >> of > >>> having 8 bits for vendor type and another 8 bits for sub-type. We > >> could > >>> also have something like if the MSB is set, then it is WAN opt > >> option, > >>> what follows is vendor information, if 0 it can be used for other > >>> things. > >>> Also to paraphrase what I said earlier : if we want to > restrict > >> this > >>> TCP option allocation proposal's scope to middlebox WAN > optimization > >> use > >>> case alone, I am fine with that too. > >>> -Anantha > >>> > >>>> -----Original Message----- > >>>> From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] > >>>> Sent: Tuesday, May 24, 2011 1:34 PM > >>>> To: Anantha Ramaiah (ananth) > >>>> Cc: David Harrington; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE > >> CORP]; > >>>> Ron Frederick; Mark Day; middisc@ietf.org > >>>> Subject: Re: [middisc] TCP middlebox option requirements > >>>> > >>>> > >>>> Anantha, what do you see as the advantage of adding a sub- > type > >> to > >>>> the type code, which follows the vendor ID? > >>>> > >>>> Andrew > >>>> > >>>> On 5/24/2011 9:03 AM, Anantha Ramaiah (ananth) wrote: > >>>>> Hi David, > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] > >> On > >>>>>> Behalf Of David Harrington > >>>>>> Sent: Tuesday, May 24, 2011 6:13 AM > >>>>>> To: 'Eddy,Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]'; 'Ron > >>>> Frederick'; > >>>>>> 'Mark Day' > >>>>>> Cc: middisc@ietf.org > >>>>>> Subject: Re: [middisc] TCP middlebox option requirements > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I also have no skin in this game. and I'm looking at this list > >>> after > >>>>>> months of ignoring it, so I'm way behind in the discussions. > >>>>>> > >>>>>> I am concerned that unless severely limited in what it can be > > used > >>>>>> for, this will lead to other vendor-specific options. > >>>>>> Whether that is good or bad I'll leave to other people to > decide, > >>>> such > >>>>>> as my co-area director Wes, the IETF community and the IESG that > >>>> will > >>>>>> need to approve any document produced as a result of this > >>>> discussion. > >>>>>> I will observe that many IETF protocols developed for a limited > >> use > >>>>>> "escape into the wild". This happens ofetn when people decide to > >>>>>> develop a weak or non- security solution and claim it will be > > only > >>>> be > >>>>>> used within an enterprise, but it then gains use in the > Internet. > >> I > >>>>>> don't know if there is anything you can do to prevent this from > >>>>>> becoming a generic option for vendor-specific features if you > >>> design > >>>>>> in a vendor code. The best way to avoid that is to reach > > agreement > >>>> on > >>>>>> a standard that does not include a vendor code (which means > >>>> accepting > >>>>>> that your current products continue to not be compliant to the > > new > >>>>>> standard). > >>>>> This thread has been quiet for sometime and last week I had sent > > an > >>>>> email describing the current status and the steps moving forward > > to > >>>>> reach consensus. > >>>>> I agree with your concerns in the above paragraph and I am sure > we > >>>> need > >>>>> to have a section (applicability section ) which exactly spells > > out > >>>> the > >>>>> scope of the middlebox option, caveats etc., I am afraid this is > >>>> best > >>>>> that can be done, we can talk and debate about it but the reality > >> is > >>>>> multiple vendors already have WAN opt options and it is non-goal > > of > >>>> this > >>>>> effort to interoperate among vendors. > >>>>> > >>>>>> If you do have vendor-specific options, it will be important to > >>> make > >>>>>> sure that each vendor is uniquely identified, so we don't have > > two > >>>>>> vendors fighting over a vendor code. I recommend registering > >> vendor > >>>>>> codes with IANA to make sure this doesn't happen. > >>>>> Actually I had asked this question (about IANA managing the > vendor > >>>>> codes) earlier in this thread. It sounds very useful to me. > >>>>> > >>>>>> IANA already maintains an Enterprise Number registry that is > used > >>>> for > >>>>>> many IETF standards. It is a widely used ***standard*** in IETF > >>>>>> standards for identifying vendors using a code number. > >>>>>> http://www.iana.org/assignments/enterprise-numbers. > >>>>> Good to know. > >>>>> > >>>>>> Maybe you can convince the IESG that having another set of codes > >> to > >>>>>> identify vendors is important, and that a given vendor will > > likely > >>>>>> have a different code in your vendor code list than that used by > >>>> other > >>>>>> standards. It doesn't sound very convincing to me. > >>>>> One of the issues is the limited space of TCP options currently > >>>>> available, having a standard vendor code would cause it to eat > >> more > >>>> TCP > >>>>> option space which would impact the usability of this option. > > Given > >>>> that > >>>>> we have an handful of vendors ( I suspect this number to grow for > >>> the > >>>>> use case of WAN optimization anytime), it is probably ok to go > >> ahead > >>>>> with a shorter vendor code point. > >>>>> > >>>>>> If expansion CAN take place in the future, and now you need 0xff > >>>> plus > >>>>>> an OUI, you will also have added complexity to TCP, requiring > >>>> suppoort > >>>>>> for one-byte vendor codes plus OUI support. and you will have > >> added > >>>> a > >>>>>> new list of vendor codes (whether maintained by IANA or not), > and > >>>>>> you'll need to convince IESG all this extra complexity is > >>> justified. > >>>>> Actually sometime back I had mentioned the other use cases like > > the > >>>>> following draft by Dan Wing :- > >>>>> http://tools.ietf.org/html/draft-wing-nat-reveal-option-01 > >>>>> > >>>>> Actually it would be expedient to make the middlebox option > >>>> extensible > >>>>> to accommodate use cases like the above. As far as the WAN > >>>> optimization > >>>>> option goes, there are a very handful of vendors today and > >>> allocating > >>>> a > >>>>> whole byte is overkill and we can sub-divide that portion to > >>>> accommodate > >>>>> other use cases like the above. But this is something we want to > > do > >>>> if > >>>>> there is a consensus, at the minimum the goal of this effort is > to > >>>> get a > >>>>> TCP option for WAN optimization allocated. (which is the original > >>>>> intent) > >>>>> > >>>>> To make things clear I am talking about the following format > > (which > >>>> was > >>>>> one of the choices listed which the group came up with) > >>>>> Case 3: > >>>>> > >>>>> 0 1 2 3 > >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 > >>>>> +---------------+---------------+---------------+---------------+ > >>>>> | Opt kind=TBD | Opt len | sub-type + Vendor | | > >>>>> +---------------+---------------+--------------------+----------| > >>>>> | | > >>>>> | ...Optional vendor payload data dependent on vend typecode... | > >>>>> | | > >>>>> +---------------+---------------+---------------+---------------+ > >>>>> > >>>>> In the above we have a option sub-type which can be 3 bits long > :- > >>>>> > >>>>> 000 - WAN opt. > >>>>> 001 - NAT reveal > >>>>> > >>>>> This gives vendor codes 5 bits which is more than enough as far > as > >>>> this > >>>>> option goes. The point here is putting the OUI information is up > > to > >>>> the > >>>>> vendor and that belongs to the vendor specific metadata. All that > >> is > >>>>> required is a type code for middlebox option and have this format > >> as > >>>>> generic as possible so that multiple vendors requirements > >> (currently > >>>> as > >>>>> we speak there is Bluecoat, Riverbed, Cisco and maybe Citrix) > >>>>> > >>>>> Adding Dan in the loop. > >>>>> > >>>>> -Anantha > >>>>>> I recommend you consider simply using an existing IETF standard > >>>>>> registry already supported by IANA, such as Enterprise Numbers, > >> for > >>>>>> your vendor codes. OR don't support vendor codes at all, and > > agree > >>>> on > >>>>>> a single standard. > >>>>>> > >>>>>> David Harrington > >>>>>> Director, IETF Transport Area > >>>>>> ietfdbh@comcast.net (preferred for ietf) > >>>>>> dbharrington@huaweisymantec.com > >>>>>> +1 603 828 1401 (cell) > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: middisc-bounces@ietf.org > >>>>>>> [mailto:middisc-bounces@ietf.org] On Behalf Of Eddy, Wesley > >>>>>>> M. (GRC-MS00)[ASRC AEROSPACE CORP] > >>>>>>> Sent: Thursday, May 27, 2010 12:53 PM > >>>>>>> To: Ron Frederick; Mark Day > >>>>>>> Cc: middisc@ietf.org > >>>>>>> Subject: Re: [middisc] TCP middlebox option requirements > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: middisc-bounces@ietf.org > > [mailto:middisc-bounces@ietf.org] > >>>> On > >>>>>>>> Behalf Of Ron Frederick > >>>>>>>> Sent: Thursday, May 27, 2010 12:44 PM > >>>>>>>> To: Mark Day > >>>>>>>> Cc: middisc@ietf.org > >>>>>>>> Subject: Re: [middisc] TCP middlebox option requirements > >>>>>>>> > >>>>>>>> ... > >>>>>>>> > >>>>>>>> If this is really the case, it would be a mistake to limit the > >>>>>> total > >>>>>>>> number of type codes across all vendors to 256. We'd basically > >> be > >>>>>>>> repeating the mistake that led to this effort in the first > >>>>>>> place, where > >>>>>>>> TCP options as a whole have a space of 256 options and we're > >>>>>>> currently > >>>>>>>> using multiple of those to solve this problem. > >>>>>>> I don't have skin in the game, but on reading this thread, my > >>>>>>> thought was that it's probably possible to use a single byte, > >>>>>>> but define one codepoint (like 0xFF) to mean "use a full OUI > >>>>>>> which follows". This way you can start with using a single > >>>>>>> byte given the relatively small number of vendors today, and > >>>>>>> have a way to accommodate larger numbers in the future, if > >>>>>>> the need arises. > >>>>>>> > >>>>>>> This only works if the means of extending to a full OUI is > >>>>>>> part of the base specification and everyone has to support > >>>>>>> it, otherwise there are backwards-compatibility issues when > >>>>>>> someone tries to use it in the future. > >>>>>>> > >>>>>>> -- > >>>>>>> Wes Eddy > >>>>>>> MTI Systems > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> middisc mailing list > >>>>>>> middisc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/middisc > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> middisc mailing list > >>>>>> middisc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/middisc > >>>>> _______________________________________________ > >>>>> middisc mailing list > >>>>> middisc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/middisc
- [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Mark Day
- Re: [middisc] TCP middlebox option requirements Mark Day
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Mark Day
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Ron Frederick
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Mark Day
- Re: [middisc] TCP middlebox option requirements Ron Frederick
- Re: [middisc] TCP middlebox option requirements Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [middisc] TCP middlebox option requirements Knutsen, Andrew
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Ron Frederick
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Mark Day
- Re: [middisc] TCP middlebox option requirements Lars Eggert
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Ron Frederick
- Re: [middisc] TCP middlebox option requirements Ron Frederick
- Re: [middisc] TCP middlebox option requirements David Harrington
- Re: [middisc] TCP middlebox option requirements Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Frederick, Ron
- [middisc] TCP middlebox option requirements Knutsen, Andrew
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Frederick, Ron
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen