Subject: New draft on a Committed Rate service

From: Roch Guerin <[email-masked]>
Date: Fri, 14 Jun 1996 09:42:37 -0400

We have just submitted a draft that describes a new Int-Serv service
providing flows with a Committed Rate guarantee.  This service is
meant to provide rate guarantees similar to those of the Guaranteed
Service, but without the rigorous delay bound and losslessness 
property of that service.  This allows higher link utilization and
lower requirements on network elements to be traded-off for weaker
service guarantees. The draft should soon be available from the
on-line Internet-Drafts directories in ACSII format.  

Comments are obviously welcome.

       Title     : Specification of Committed Rate Quality of Service
       Authors   : F. Baker, R. Guerin, D. Kandlur
       Filename  : draft-ietf-intserv-commit-rate-svc-00.txt

Abstract of the draft: 

   This document describes the network element behavior required to
   deliver a Committed Rate service in the Internet.  The Committed Rate
   service provides applications with a firm commitment from the
   network, that at a minimum the transmission rate they requested is
   available to them at each network element on their path.  The
   commitment of a given transmission rate by a network element is not
   associated with a specific delay guarantee, but requires that network
   elements perform admission control to avoid over-allocation of
   resources.

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 15 Jun 1996 02:08:17 +0300

how does crq service differ from bpe service when minimum rate is
greater than zero?

-- juha

---

From: Roch Guerin <[email-masked]>
Date: Sat, 15 Jun 1996 18:09:12 -0400

Juha, 
I think that the Committed rate service differs from the 
Protected Best Effort service in numerous ways, although I
have not read the last version of your draft so this is based
on your initial draft.

Some of the main differences I can think of are that the CR 
says absolutely nothing about how to treat the traffic in excess 
of the TSpec, i.e., does commit to giving it a fair (or not)
share of any available bandwidth.  For example, a flow can get
a service cloes to what it would see if it was going over a 
dedicated wire running at the requested bit rate.  
Also, note that even if this
is not required and wont be used by all implementations, 
reshaping of the traffic at each hop is perfectly permissible.
This is yet another difference with PBE.  

There are several
others, but in general I think that the CR and PBE services
target different applications.  My understanding of the initial
goal of the PBE service, is that it was intended to provide a
minimum level of guarantees to individual flows to ensure that
they would not be treated too unfairly when going over congested
links.  In contrast, the CR service provides much stronger 
guarantees, but is less flexible in terms of how it 
lets flows access free resources in the network.
Roch