Re: [Diffserv] "Critical" traffic in a DS Domain

Scott W Brim <sbrim@cisco.com> Wed, 03 May 2000 17:59 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07597; Wed, 3 May 2000 13:59:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09999; Wed, 3 May 2000 13:29:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09975 for <diffserv@ns.ietf.org>; Wed, 3 May 2000 13:29:02 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07011 for <diffserv@ietf.org>; Wed, 3 May 2000 13:29:01 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA04266; Wed, 3 May 2000 10:04:08 -0700 (PDT)
Received: from sbrim-nt.cisco.com (rtp-dial-2-92.cisco.com [10.83.96.92]) by airborne.cisco.com (Mirapoint) with ESMTP id ABG02130; Wed, 3 May 2000 10:03:58 -0700 (PDT)
Message-Id: <4.3.2.3.2.20000503125629.00b2db70@airborne.cisco.com>
X-Sender: sbrim@airborne.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.3 (Beta)
Date: Wed, 03 May 2000 13:03:54 -0400
To: Brian E Carpenter <brian@hursley.ibm.com>
From: Scott W Brim <sbrim@cisco.com>
Subject: Re: [Diffserv] "Critical" traffic in a DS Domain
Cc: "Wilson, Greg" <gwilson@necam.com>, "'diffserv@ietf.org'" <diffserv@ietf.org>
In-Reply-To: <391050C8.CA298023@hursley.ibm.com>
References: <A500CE54D312D311929900105A0D7379901599@cngmail1.esd.dl.nec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Of course it's not just the DSCPs that matter, it's the end-to-end 
service (here we go again :-)).  The class selectors promise nothing 
about loss or delay, except in relative terms.  If you want to be sure of 
zero delay, zero loss, you need a service which provides that -- which 
you could implement with class selectors 6 and 7, or EF or AF.  You're 
feeding right into the per-domain behavior discussion that's been going 
on (see draft-ietf-diffserv-ba-def-01.txt).

At 11:16 05/03/2000 -0500, Brian E Carpenter wrote:
>Class Selector 6 or 7 (RFC 2474, section 4.2.2.2)
>
>     Brian
>
>"Wilson, Greg" wrote:
> >
> > All-
> >
> > What would be the best DS configuration for data that falls into a
> > "critical" category.  IE:  Network Control Traffic, Heartbeats, Error
> > Messages, or any other kind of data that directly controls the primary
> > functionality of a far-end, time sensitive device that is connected 
> to the
> > network.  This kind of traffic, if delayed or dropped, can cause 
> problems or
> > perceived problems with the affected devices.
> >
> > I am looking to find a PHB that focuses on this kind of "critical" 
> traffic.
> >
> > Thanks
> > -Greg Wilson
> > gwilson@necam.com


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/