RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs

"Andrew Smith" <ah_smith@acm.org> Sat, 08 March 2003 00:41 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20191 for <diffserv-archive@odin.ietf.org>; Fri, 7 Mar 2003 19:41:02 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h280ql400682 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 19:52:47 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280j2O32228; Fri, 7 Mar 2003 19:45:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280WbO30716 for <diffserv@optimus.ietf.org>; Fri, 7 Mar 2003 19:32:37 -0500
Received: from albatross.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17977; Fri, 7 Mar 2003 19:20:21 -0500 (EST)
Received: from user-11206ng.dsl.mindspring.com ([66.32.26.240] helo=ANDREWLAPTOP) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18rS6Y-0001nX-00; Fri, 07 Mar 2003 16:22:22 -0800
From: "Andrew Smith" <ah_smith@acm.org>
To: "'Woundy, Richard'" <Richard_Woundy@cable.comcast.com>, <diffserv@ietf.org>, "'IPCDN WG \(E-mail\)'" <ipcdn@ietf.org>
Cc: <jf.mule@cablelabs.com>, <narten@us.ibm.com>, <erik.nordmark@sun.com>, "'Wijnen, Bert \(Bert\)'" <bwijnen@lucent.com>
Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs
Date: Fri, 7 Mar 2003 16:24:13 -0800
Message-ID: <0ad901c2e509$0f2c40e0$1500000a@ANDREWLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <6732623D2548D61193C90002A5C88DCC056637AB@entmaexch02.broadband.att.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-BeenThere: diffserv@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=unsubscribe>
List-Id: Diffserv Discussion List <diffserv.ietf.org>
List-Post: <mailto:diffserv@ietf.org>
List-Help: <mailto:diffserv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Rich,

Thanks for the context - it wasn't clear from the draft or the WG
charter that this was an update to an earlier MIB. I appreciate the
momentum that comes with 20 million deployments!

My comments were aimed exclusively at the CMTS, not the modem: I think a
CMTS probably has a much better chance of supporting the Diffserv MIB,
which sacrifices implementation simplicity for generality in ways that
seemed appropriate for Diffserv switching nodes. I would also assume
that deployment of updates to CMTSs is many orders of magnitude easier
than changes to modems and that backwards-compatibility with RFC 2669 is
also less of an issue.

Regards,

Andrew Smith


-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] 
Sent: Friday, March 07, 2003 2:28 PM
To: 'Andrew Smith'; diffserv@ietf.org; IPCDN WG (E-mail)
Cc: jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com;
'Wijnen, Bert (Bert)'
Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs


Andrew,

Please keep in mind that the current Cable Device MIB is an update to
RFC
2669, which pre-dates your RFC 3289 by three years. Since the
publication of
RFC 2669, about 20 million cable modems have been shipped, with our
industry
presumption that the Cable Device MIB was IETF-blessed. :^(

I described the Cable Device MIB filters as "re-marking boundary nodes"
using the language of RFC 2474. But the original Cable Device filters
really
were designed as extended access control lists for cable modems, e.g. to
keep unwanted traffic off the cable network: NetBEUI, spoofed DHCP
servers,
etc. The filters also happen to contain IP ToS matching and overwriting
capabilities. As we figure out how to update the RFC 2669 MIB, naturally
we
want to replace IPv4 ToS management with IPv4/v6 DSCP management... two
weeks ago we start to look at RFC 3289 for the first time. :^(

The Subscriber Management MIB is designed as a light-weight extension to
the
Cable Device MIB for Cable Modem Termination System (CMTS) filtering.
That
MIB separates TCP/UDP port filtering into separate filtering tables due
to
performance reasons. Otherwise, it is modelled after the Cable Device
MIB.

With all that said, the right thing to do may in fact be to adopt the
DiffServ MIB for the filtering and/or classification functions in DOCSIS
cable modems, particularly since:
- it supports IPv6 addresses better than the filters in RFC 2669,
- it supports DSCP and flow ID matching better than RFC 2669,
- it supports more flexible traffic classification, and
- it allows cable modems to reuse an existing IETF MIB used outside of
cable.

But take heed that this is a very significant change to a critical modem
function used by most of the cable industry. It's going to take myself
and
others some time to figure out how to adopt more/all of the RFC 3289
DiffServ MIB.

Here are two typical cable industry considerations:
- The base DOCSIS 1.1 and 2.0 technology is not yet DiffServ-aware,
since it
currently relies on IP ToS masking and ranges for upstream traffic
queuing.
There is interest among the cable operators to start to fix this, but
that
may take a long time. To see what DOCSIS expects today, see Appendix
C.2.1.5.1 in
<http://www.cablemodem.com/downloads/specs/SP-RFIv1.1-I09-020830.pdf>;.
- The standard DOCSIS cable modem is an inexpensive device (e.g. <$100),
so
simplicity of implementation is very critical. This might be satisfied
by a
simplified MIB compliance for DOCSIS cable modems -- if it is a real
issue
here.

If you are volunteering to help us adopt the DiffServ MIB for DOCSIS,
then I
accept your help!

I appreciate and support the IETF community's desire to reuse existing
work.
In return, please appreciate that this is changing the expectations of
our
IPCDN MIBs (and impacting its publication dates) yet again in a very
significant way.

-- Rich

-----Original Message-----
From: Andrew Smith [mailto:ah_smith@acm.org]
Sent: Friday, March 07, 2003 4:06 PM
To: Woundy, Richard; diffserv@ietf.org
Cc: jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com;
'Wijnen, Bert (Bert)'
Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs


Rich,

You wrote:
...
> I agree with Wilson when he emphasizes that these Dscp objects in the
> various DOCSIS MIB are access filters, not PHB selectors. In fact,
such
> objects enable the DOCSIS equipment to act precisely as "re-marking
boundary
> nodes", which are also described in RFC 2474 Section 3, pages 8-9:
...

If the pieces of DOCSIS equipment are acting as "re-marking boundary
nodes, which are also described in RFC 2474 Section 3, pages 8-9" then
shouldn't they, by definition, be implementing the IETF's existing
Diffserv MIB RFC 3289 in order to control this functionality? I would
hope that your WG would provide a strong argument why IETF should
sanction another MIB for this same purpose when this work comes before
the IESG for consideration.

Andrew Smith




_______________________________________________
diffserv mailing list
diffserv@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html