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