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

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" <steves@shentel.net>, "Fred Baker" <fred@cisco.com>,   
                      @cisco.com>              Janet P Gunn/FED/CSC@CSC, <ieprep@ietf.org>                                       
                                               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

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep