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

From: "James M. Polk" <[email-masked]>
Date: Mon, 02 Feb 2004 16:57:51 -0600

Janet

My comparison in the quotes was a poor attempt at what occurs within MLPP 
Switches today (preemption tone or an announcement), and from an IP POV - 
the tone behavior is doable with my recent ID into SIPPING (Reason Header 
for Preemption), but the latter (the announcement) isn't doable to inform a 
user with words about which router was the culprit in not letting a call 
get through or the preemptor of a call.

The GSCR clearly call out these two behaviors, and they are probably 
appropriate for TDM networks, but IMO are not for IP networks where the 
congestion event happened at a router - but this distinction isn't made in 
the GSCR, both behaviors are still mandated (and I don't know how we're 
going to accomplish the announcement regarding a specific identifiable 
router causing a call to fail on purpose).

If this is an "IP at the Start" scenario, and the congestion event occurs 
within the TDM infrastructure, then I believe that announcement or tone 
MUST be communicated back to the IP phone and user on that call to inform 
them of what they get today

I know this is (slightly) off topic for this list

At 05:25 PM 2/2/2004 -0500, Janet P Gunn wrote:

>Comments in line- trying to make sure I understand what you are saying.
>
>
>----------------------------------------------------------------------------------------
>
>This is a PRIVATE message. If you are not the intended recipient, please
>delete without copying and kindly advise us by e-mail of the mistake in
>delivery. NOTE: Regardless of content, this e-mail shall not operate to
>bind CSC to any order or other contract unless pursuant to explicit written
>agreement or government initiative expressly permitting the use of e-mail
>for such purpose.
>----------------------------------------------------------------------------------------
>
>
>
>
> 
>
>                       "James M. 
> Polk" 
>
>                       <jmpolk                  To:      "Steve Silverman" 
> <[email-masked]>, "Fred Baker" <[email-masked]>,
>                       @cisco.com>              Janet P Gunn/FED/CSC@CSC, 
> <[email-masked]>
>                                                cc: 
 >
>                       01/29/2004 01:25         Subject: RE: [Ieprep] I-D 
> ACTION:draft-ietf-ieprep-domain-req-00.txt
>                       PM 
 >
> 
>
> 
>
>
>
>
>
>comments below
>
>At 11:33 AM 1/29/2004 -0500, Steve Silverman wrote:
> >If the offered load exceeds the network capacity, some packets will be
> >dropped.  If a line is at
> >95% of capacity, a 10% surge would cause 5% of the packets to be
> >dropped, degrading most of the conversations.  ( I am simplifying here
> >but I think this is clear.)
> >
> >The benefit of multiple DSCPs is that the sessions designated most
> >critical are unaffected.
>
>without active feedback to those lower priority sessions....
>
> >Actual experiment has shown that this does
> >work.
>
>yes it does - but without regard to any call quality.
>
>If the surge is 25 or 50 or 75% above maximum load possible, then what
>happens to the lower priority calls? There isn't any feedback to the users
>(other than pure silence). Further, there isn't any feedback (signaling) to
>
>their devices what's happening or to hang up the call. There's nothing. How
>
>long is this expected to last for? No one knows.
>
>Further, no one can test the system (because of no feedback).
>
>No one can point to where there might be potential problems with this
>architecture either (is the system behaving correctly?). There is no
>feedback to discover or monitor its performance. Where is it supposed to be
>
>discovered that a link between any two routers isn't fast enough (because
>there are perhaps frequent silence periods)?
>
>
> >In draft-baker-tsvwg-mlpp-that-works.00 it is assumed that the CAC
> >will ensure that voice is not overloaded.
> >Two problems with this are:
> >
> >         1)  If silence suppression is used and the bandwidth
>"oversubscribed"
> >(standard practice) then sometimes, more people on one end will talk
> >and cause congestion.
> >
> >         2)  If the area controlled by the CAC is large, propagation delay
> >will limit the reaction time of the system
>
>where's the propagation delay? the surge won't happen without the signaling
>
>having already occurred through the congestion point; meaning the system
>(read: routers) already know about all the call (flow) attempts - even when
>
>there is too much offered load for an interface. The router can either say
>"sorry, not enough resources available to complete your call attempt" or
>"sorry, but there was another call with higher priority, and I have to shut
>
>your call down now". BTW - these are device signals, this isn't a .wav file
>
>playing to the user or anything.
>
>[jpg] I think I understand how CAC says "not enough resources available to
>complete your call attempt" at call setup time.
>
>[jpg] It is not clear to me how CAC says "sorry, but there was another call
>with higher priority, and I have to shut your call down now" once the call
>has been established.  I was under the impression that, once the call was
>established, the router did not distinguish between individual calls.  I
>would be glad to be enlightened on that point.
>
> >and the computation to
> >oversee the entire theatre may also be a limiting factor.
>
>see above, computation occurs at the router that is experiencing this
>surge. It is in charge of the packet forwarding. It is aware of all the
>existing flows it has accepted. It is in charge of accepting new flows and
>preempting lesser priority ones if multilevel offered load exceeds the
>maximum load possible.
>
> >This may
> >cause short congestion incidents (several seconds long) which could be
> >mitigated by MLEF.  I'm not saying you don't also need the CAC.  I'm
> >saying
> >you need something local and fast reacting
>
>In the router itself isn't fast enough...?
>
> >(at the packet level rather
> >than the call level)
>
>packet level = Layer 3
>
>Call level = what? Layer 4, 5 or 7?
>
> >to ensure that the high priority packets get
> >thru.
>
>I am a believer in high priority calls getting through, and for all calls
>that remain up - having all their packets arrive safely too.
>
>[jpg] Me too
>
>Janet
>
>
> >Steve Silverman
>
>
>cheers,
>James
>
>                                 *******************
>                  Truth is not to be argued... it is to be presented

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Janet Gunn <[email-masked]>
Date: Mon, 9 Feb 2004 14:20:06 -0800 (PST)

I have finally had a chance to do some more reading, and I think I fianlly understand the source of my confusion (and probably some others).

I had assumed that the term "Call Admission Control" was active only only at the START of a call- that once a call had been admitted in the first place, there was no further CAC involvement.  

However, reading between the lines in several posts, and relating that to some of the reference documents, it appears that the term CAC is being applied to a mechanism which remains involved throught the live of the call, and can "rescind" the admission during the course of the call, if necessary.

Is this right, or am I just barking up a different wrong tree?

Janet

-----Original Message-----
From: Scott Bradner <[email-masked]>
Sent: Feb 3, 2004 5:31 AM
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt

> would be glad to be enlightened on that point.

note that the router is not involved in establishing the call - its all
packets to the router

but if the call QoS is maintained by RSVP (as Fred suggested) there is 
less of an issue - a router can reject RSVP sessions even after they
have started

Scott

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 09 Feb 2004 17:02:26 -0600

At 02:20 PM 2/9/2004 -0800, Janet Gunn wrote:
>I have finally had a chance to do some more reading, and I think I fianlly 
>understand the source of my confusion (and probably some others).
>
>I had assumed that the term "Call Admission Control" was active only only 
>at the START of a call- that once a call had been admitted in the first 
>place, there was no further CAC involvement.
>
>However, reading between the lines in several posts, and relating that to 
>some of the reference documents, it appears that the term CAC is being 
>applied to a mechanism which remains involved throught the live of the 
>call, and can "rescind" the admission during the course of the call, if 
>necessary.

What you were believing was the case is called "Locations based CAC" (done 
once at start-up, and not again). This is a hack, but kinda sorta works in 
very limited links between 2 locations (not daisy-chained mind you, the 
complexity and topology knowledge is just not really possible then).

What you have realized about RSVP is that the CAC functionality is from 
call inception, makes sure there is enough resources to complete a call at 
a known bandwidth (errors the set-up if there isn't enough), and the 
routers in between remain in a "soft state" condition for all the RSVP 
"flows" that have been accepted through that interface for the duration of 
all the flows (or calls) until their end, which is either by a normal end 
of a call (user hang-up) or a preemption event at a congested router 
interface (to make room for another flow/call).

>Is this right, or am I just barking up a different wrong tree?

the crowd applauds!!

cheers,
James

                                *******************

---

From: [email-masked]
Date: Wed, 11 Feb 2004 11:15:58 EST

In a message dated 2/10/2004 11:56:45 AM Eastern Standard Time, 
[email-masked] 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, 
[email-masked] 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