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

From: [email-masked]
Date: Tue, 9 Dec 2003 15:19:56 EST

In a message dated 12/8/2003 4:56:54 PM Eastern Standard Time, [email-masked] 
writes:

> My draft addresses those directly, in section 2.6.
> 
>     A measurement-based counterpart to the MLPP procedure has been
>     proposed, in which calls experiencing significant loss treat this as
>     a signal from the network and drop the call. But if all calls at a
>     precedence level are experiencing loss, many and perhaps all calls at
>     the precedence level would be dropped by this heuristic; if many
>     calls are vying for service, the effect would be rolling call
>     disruption - a set of calls would be established, additional calls
>     would be established disrupting that class of calls, many of the
>     disrupted calls would drop, and then more of the competing calls
>     would be established - only to be disrupted when the first set
>     redialed.
> 
Besides the problem you noted above with this method of dealing with 
congestion (packet loss), there is also the problem that it can not function in a 
multi-precedence level environment without a selective packet discard mechanism as 
defined in MLEF.

It must be presumed that the intention of the above is that the decision to 
drop a call based on packet loss is made by the endpoint, that is, the user's 
terminal.

If there were only 2 levels, a terminal could know that it is involved in a 
call at the lowest level and release, or know that it has a call at the higher 
level and not release when packet losses occur.

However, the requirement is for 5 (or 6 levels). A teminal which is involved 
in a Priority call and is getting packet losses does not know if the loss is 
due to contention with 20 other routine calls, in which case it should just 
wait for the others to release, or if it is due to 20 other Flash calls, in which 
case this terminal must release quickly. An MLEF-type mechanism at the 
congestion point in between would resolve this problem.

Mike

---

From: Fred Baker <[email-masked]>
Date: Wed, 10 Dec 2003 11:34:12 -0200

At 06:19 PM 12/9/2003, [email-masked] wrote:
>congestion (packet loss), there is also the problem that it can not 
>function in a multi-precedence level environment without a selective 
>packet discard mechanism as defined in MLEF.

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.

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. 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. SRTCM/TRTCM 
would downgrade the second packets but keep them alive, which is closer to 
(although not exactly) what you want.

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? 

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