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

["James M. Polk" <[e-mail]>]

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" 
> <[e-mail]>, "Fred Baker" <[e-mail]>,
>                       @cisco.com>              Janet P Gunn/FED/CSC@CSC, 
> <[e-mail]>
>                                                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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep