Subject: Re: [Ieprep] deja vu

From: "James M. Polk" <[email-masked]>
Date: Fri, 21 Nov 2003 13:08:52 -0600

Kimberly

One underlying assumption you are making about the CAC function below is 
that each knows where a destination endpoint is. You are not accounting for 
the mobility IP inherently brings to future networks.

At 09:39 AM 11/21/2003 -0500, King, Kimberly  S. wrote:
>All,
>
>I think the reason it is difficult to make definite statements about CAC
>would work or not is tied to the fact that you don't have a fixed
>architecture in mind.  (In fact, you haven't clearly defined the problem to
>be solved.)
>
>But, suppose I tell you this:
>
>There is a core network that is super.  It has tons of capacity, extremely
>low packet loss, low jitter and low delay.  We will engineer this network
>such that if you never exceed amount X of type EF incoming the network from
>each inbound link, and assuming some flexible traffic matrix, that these
>packets are going to get great treatment 99.9% of the time.  That would
>translate into great phone calls.
>
>Now then I tell you this:
>
>You have a bunch of feeder links into this network.  You have to limit the
>amount of EF traffic you allow into the core network to be less than X per
>link (I can be more general that this too).  You prefer to grant that EF
>bandwidth to the most important calls so you install a local version of CAC
>and tie it to the VoIP call signaling (either through an "IP PBX" or some
>local QoS appliance box that sits at before the access link that does
>stateful inspection of calls).  Your CAC can even preempt since it can be
>stateful about what the MLPP level of on-going calls.
>
>Okay.  Now, I'll bet this works pretty well, works with pretty much off the
>shelf stuff, and so why not go and model it.  Furthermore, for the purpose
>of this working group, somebody should really state (in a draft) the general
>problem to be solved.  We can look at requirements and then analyze if there
>is some gap in existing protocols.
>
>The question to ask is if it solves your problem, not if it solves it in the
>exact same way as it was solved before.
>
>Kimberly
>
>_______________________________________________
>Ieprep mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ieprep

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