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

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.

>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.

>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