Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt (3)

From: [email-masked]
Date: Wed, 10 Dec 2003 22:05:46 EST

Fred,

Thanks for the detailed response and the time you're spending on this.

In a message dated 12/10/2003 11:45:16 AM Eastern Standard Time, 
[email-masked] writes:

You will note in the draft you pulled that text from 
(draft-baker-tsvwg-mlpp-that-works-00.txt), that I suggested that an 
extension to SRTCM or TRTCM, involving a color-aware mode with N colors, 
could be used with this, and would address situations where routing changed.

[MAP] Yes, I noted that, and this was the subject of another e-mail, asking 
what was meant by that, especially the part about it being "trivially extended 
to an arbitrary number of colors". SRTCM and TRTCM are based on exactly three 
colors ("TC") which are derived from comparisons with CBS and EBS, so I don't 
see how they can be extended. If they were extended to 5 "colors" which are 
then used to determine discard probability (as I think you implied), it sounds a 
lot like MLEF.

Something with MLEF that you want to seriously consider are "how do I know 
what number of calls to configure to police to" if there is no 
routing-aware CAC is that the numbers can be pretty seriously wrong, 
because there is no way to tell how to make them right. Even with 
RSVP-or-some-thing-like-it going along the path, if you are policing to the 
number of calls that have been admitted on each precedence level, if 
routing changes (say "manet") the numbers will be wrong until RSVP adjusts 
to track routing. 

[MAP] I think it is important to keep CAC (to limit new calls) and MLEF (to 
control packet discard) separate in this discussion, although it is fully 
agreed that MLEF can't work without an effective CAC. They're essentially on 
different "layers" and operate independently. Your first comment about needing to 
know how many calls to configure to police to and needing a "routing-aware CAC" 
would apply just as much to the non-MLEF case. This needs to be solved even 
without MLEF. Your comment about "policing to the number of calls" in this 
discussion about MLEF makes me think that we haven't described MLEF well enough. 
MLEF has nothing to do with "calls", since it operates in a router on individual 
packets. CAC does this policing on calls.

[MAP] Yes, in the case of "manet" or any rearrangement of packet flows due to 
a failure, this could cause the numbers (of packet flows) to be wrong until 
something else changes, and it is MLEF that ensures that the packet flows for 
high priority calls still get through during that period (until CAC or 
preemption brings the numbers back in line).

MLEF as specified permits one packet in the queue per
call allocated in each level. If two FO calls were admitted on one path, 
setting the policer to look for two calls, and one FO call was admitted on 
another path, and routing changed combining the paths, your policer would 
only allow packets from two of the calls at any given time.

[MAP] I'm not sure what you meant by the above, but it does not sound like 
the way MLEF is defined. If the limits set on the output queue, for example, are 
10 for when a routine packet is being queued, and 11 for when a Priority 
packet is being queued, there can be more that 1 Priority packet in the queue at 
one time for more than 1 Priority call. I would not expect there to be more 
than 1 packet for the same call in the queue at the same time, Priority or not, 
since that might represent excessive delay. But, MLEF does not prevent this any 
more than EF did. It is unaware of which packets belong to the same flow 
(call).

SRTCM/TRTCM would downgrade the second packets but keep them alive, which is 
closer to 
(although not exactly) what you want.

[MAP] Not sure how one "degrades" a voice packet, but "keep them alive". I 
believe that at any point (in a router) there are only two choices for a voice 
packet: queue it or discard it. Just as described in EF, it can't be delayed by 
priority queuing or reordered. SRTCM/TRTCM gave the example of discarding 
"Red" packets and putting the "Yellow" ones in the "Best Effort Queue", which we 
can't do for voice packets.

In CAC procedures, I'm looking for something deterministic (if M calls need 
to be dropped, drop exactly M calls, and if a call needs to be refused, 
refuse it before it sends any data traffic, and do so according to a 
network-controlled policy as opposed to a policy enforced only by the end 
station), and something that is routing-aware - if I have three exit paths, 
it asks about the one being used and ignores the ones not being used. I am 
also looking for one that cannot be displaced from the end station or the 
routing path; in a manet case, the DNS model would in effect require DNS 
servers in each vehicle in order for the DNS server to be in any sense 
aware of the paths, but one would generally find two or three redundant 
servers, at least one being reachable via satcom "back at the ranch". Ditto 
a gate-keeper if call counting is what you have in mind.

What I am very concerned about is that the CAC involved here doesn't meet 
the basic requirements to actually perform the service that MLPP performs.

So exactly what CAC model do you have in mind? 

[MAP] Clearly, we need to first agree on a definition of what CAC is. Is 
there one anyplace? I especially have a problem with including "dropping of calls" 
under "CAC" (since the "A" means "acceptance"). I would define CAC as those 
procedures/algorithms that decide whether or not a new call attempt can be 
setup. This would include authentication, restrictions of reachability, and 
bandwidth limitations. We should include the notion of forcing disconnect 
("preemption") under a different term (not "CAC").

With that definition, I'm not sure what you would mean by a "model". This is 
largely dependent on the architecure. With the architecture described in one 
of my drafts, it is the assigned proxy server that performs the CAC function 
for the calling party. The proxy needs to know three things:
- What route the packet flows will (likely) take
- What the limits are for each link in the route
- What the current load is on each link (e.g., number of packet flows or 
total committed rate)

With Multilevel Precedence added, the above information for limits and loads 
would need to be known for each precedence level. Beyond that, one could 
define different algorithms for the ways that limits would be defined and applied. 
I'm working on a draft to descibe one such method.

I also realize that a proxy knowing the above is a stretch, and I think your 
comments partly indicated that the above is impossible. If so, then CAC is 
impossible, and, if so, VoIP is impossible in any network which might experience 
congestion but which must provide "assured service" to some users.

So I can rephrase your final sentence above as "What I am very concerned 
about is that the CAC involved here doesn't meet the basic requirements to 
actually perform the service that telephony performs."

Mike Pierce

---

From: Fred Baker <[email-masked]>
Date: Thu, 11 Dec 2003 08:28:09 -0200

At 01:05 AM 12/11/2003, [email-masked] wrote:
>[MAP] Yes, I noted that, and this was the subject of another e-mail, 
>asking what was meant by that, especially the part about it being 
>"trivially extended to an arbitrary number of colors". SRTCM and TRTCM are 
>based on exactly three colors ("TC") which are derived from comparisons 
>with CBS and EBS, so I don't see how they can be extended. If they were 
>extended to 5 "colors" which are then used to determine discard 
>probability (as I think you implied), it sounds a lot like MLEF.

It does. The difference is that if a high precedence session exists but 
doesn't have credits to support it, it is downgraded and survives rather 
than being dropped.

>there one anyplace?

I don't know of a formal definition anywhere. Informally, Call Admission 
Control is any procedure by which calls are individually considered, a 
policy is applied to them, and some are accepted and some aren't. This 
differs from packets being considered, and the only places I have ever seen 
the term applied apply it to a control plane procedure.

There are several that are used in the industry:
  - ATM CAC is part of the method by which a VC is placed by the central VC 
routing system
  - H.323 has a call counting procedure in the gatekeeper.
  - SIP has a way of counting calls through a SIP Proxy
  - There is a procedure (name of the draft escapes me) that does a simple 
call counting
    procedure in a DNS server or proxy
  - RSVP/nsis offers a form of bandwidth admission with a fairly 
well-defined capability
    for preemption under a policy.

>  I especially have a problem with including "dropping of calls" under 
> "CAC" (since the "A" means "acceptance"). I would define CAC as those 
> procedures/algorithms that decide whether or not a new call attempt can 
> be setup. This would include authentication, restrictions of 
> reachability, and bandwidth limitations. We should include the notion of 
> forcing disconnect ("preemption") under a different term (not "CAC").

Maybe. If I look very hard at MLPP as specified for SS7, at least as I 
understand it, preemption is sort of a side effect of call admission; one 
first asks whether there is sufficient bandwidth for the call, if not one 
attempts to create the bandwidth by preempting another call, and depending 
on the success or failure of those steps, one finally accepts or does not 
accept the call. However, I tend to think that we could get into serious 
hair splitting very prematurely with this one. Bottom line, for your policy 
to work, both things need to happen, whatever we choose to call them.

>With that definition, I'm not sure what you would mean by a "model". This 
>is largely dependent on the architecure. With the architecture described 
>in one of my drafts, it is the assigned proxy server that performs the CAC 
>function for the calling party. The proxy needs to know three things:

Yes. And this fact fairly severely limits the choices: the proxy server 
could easily be on the other side of the planet, and generally has no 
concept of the routing or current load. That is fairly problematic.

>I also realize that a proxy knowing the above is a stretch, and I think 
>your comments partly indicated that the above is impossible. If so, then 
>CAC is impossible, and, if so, VoIP is impossible in any network which 
>might experience congestion but which must provide "assured service" to 
>some users.

Not so. May I suggest that you re-read and comment on 
draft-baker-tsvwg-mlpp-that-works-00.txt? I provide exactly what you're 
asking for:

  - as many marks on data packets as you like
  - correct calculation of the policing limits for each mark
  - bandwidth and route aware CAC at the points that experience congestion
  - specific layered policy controlling same
  - lack of state in places that are not bandwidth constrained
  - refusal of a call before it transmits *any* data, protecting other 
calls from same

It also happens to be (mostly, not the extended srtcm/trtcm part, and by 
the way there are other possible policing algorithms that we should perhaps 
discuss) implemented on a certain random vendor's router, and is 
standards-based as the bibliography of that document will attest.

By the way, on the no-called extended srtcm/trtcm, I sketched together 
drafts for same. They're probably not in form to post yet, but this will 
give you the drift of that line of reasoning:

     ftp://ftpeng.cisco.com/fred/mlpp/mrmcm.html
     ftp://ftpeng.cisco.com/fred/mlpp/srmcm.html

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

---

From: Fred Baker <[email-masked]>
Date: Thu, 11 Dec 2003 09:46:19 -0200

>  - correct calculation of the policing limits for each mark

by the way, as I note in the draft, the actual value of marking the data 
packets is very limited. If we know that all data packets in a queue have 
been admitted by an admission policy implementing mlpp, no packet should 
ever be dropped as long as they all are sending at less than or equal to 
the rate they said they would send at - regardless of the marking policy. 
The only case I can think of where marking actually buys you anything is in 
the short interval between a routing change and rsvp admission tracking 
that routing change. In such a case, what the "extended srtcm/trtcm" model 
buys you is that preferred calls drop less packets than others.

At this point, frankly, I'm splitting the difference with you - you want 
the marks real badly, and OK, I'll give them to you, but please don't take 
my doing so as an endorsement of a real need for them. I see little to no 
practical benefit in the presence of effective bandwidth admission (CAC).