Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt

Mpierce1@aol.com Wed, 11 February 2004 16:29 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07930 for <ieprep-archive@odin.ietf.org>; Wed, 11 Feb 2004 11:29:04 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxE4-00050I-Kw for ieprep-archive@odin.ietf.org; Wed, 11 Feb 2004 11:28:36 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGSaYd019233 for ieprep-archive@odin.ietf.org; Wed, 11 Feb 2004 11:28:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxE4-000508-Fi for ieprep-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:28:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07785 for <ieprep-web-archive@ietf.org>; Wed, 11 Feb 2004 11:28:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxE3-0006Zq-00 for ieprep-web-archive@ietf.org; Wed, 11 Feb 2004 11:28:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxBr-00067s-00 for ieprep-web-archive@ietf.org; Wed, 11 Feb 2004 11:26:20 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqxAa-0005vs-02 for ieprep-web-archive@ietf.org; Wed, 11 Feb 2004 11:25:00 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aqx4r-0002dm-PB for ieprep-web-archive@ietf.org; Wed, 11 Feb 2004 11:19:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqx4m-0004Ce-GU; Wed, 11 Feb 2004 11:19:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqx41-00049x-8X for ieprep@optimus.ietf.org; Wed, 11 Feb 2004 11:18:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07158 for <ieprep@ietf.org>; Wed, 11 Feb 2004 11:18:11 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqx40-00054z-00 for ieprep@ietf.org; Wed, 11 Feb 2004 11:18:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqx2p-0004vI-00 for ieprep@ietf.org; Wed, 11 Feb 2004 11:17:00 -0500
Received: from imo-m23.mx.aol.com ([64.12.137.4]) by ietf-mx with esmtp (Exim 4.12) id 1Aqx2P-0004nL-00 for ieprep@ietf.org; Wed, 11 Feb 2004 11:16:33 -0500
Received: from Mpierce1@aol.com by imo-m23.mx.aol.com (mail_out_v36_r4.12.) id t.2b.50aab1b2 (4196); Wed, 11 Feb 2004 11:15:58 -0500 (EST)
Message-ID: <2b.50aab1b2.2d5baf3e@aol.com>
Date: Wed, 11 Feb 2004 11:15:58 -0500
Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt
To: jgunn6@csc.com, ieprep@ietf.org
CC: jmpolk@cisco.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_2b.50aab1b2.2d5baf3e_boundary"
X-Mailer: 6.0 for Windows XP sub 51
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60

In a message dated 2/10/2004 11:56:45 AM Eastern Standard Time, 
jgunn6@csc.com writes:


> Yes, I think it would be worthwhile to have a "definition" of CAC as a
> stand-alone posting on the list.   But I don't think we need to have a
> "discussion" about it.
> 

Well, it's hard to have a "definition" without some discussion, since it 
should be something that is agreed.

I think our "discussion" and the need is for a definition of "Call Admission 
Control", which I had used in my draft on preferential treatement examples, 
with the belief that there was a uniform understanding of what it meant. I 
believe it is an old term from the telephony environment, and what we are talking 
about here is "telephony". The application layer functions (call setup) haven't 
changed.

We should clearly separate the transport layer (e.g., RSVP, packet flows) 
from the application layer (call setup, preemption, release) with our terms. 
Unfortunately, RFC3181 uses the term "Capacity Admission Control (CAC)" in 
referring to packet transport.

Fred and James' comments related to RSVP, but RSVP never talked about 
"calls". As RSVP defines "Admission Control", I don't see the term
including "preemption", although RSVP clearly does.

In a message dated 2/10/2004 3:28:34 PM Eastern Standard Time, 
jmpolk@cisco.com writes:


>  define CAC in IP as:
> 
>          - set-up of the call at the endpoints (SIP does this), and
> 
>          - the ongoing monitoring process to keep the flow "functional"
> 
> this second bullet deals with packet admission, per packet to meet an 
> agreed upon bandwidth guarantee promised to all other nodes for that flow.
> 

Yes, I think this is fine, except that the first bullet is the application 
layer (call) and the second is the packet transport layer. So "CAC" would then 
be "Call/Capacity Admission Control".

CAC affects the initial setup of the call as well as the continuation of the 
call (packet flow). That's fine. I just think that the specific function of 
preemption of one call (packet flow) by another should be called something else 
for sake of clarity in descriptions, etc.

Mike Pierce