Subject: Re: [Ieprep] Comments on draft-carlberg-ieprep-framework

From: [email-masked]
Date: Tue, 12 Mar 2002 11:08:19 EST

In a message dated 3/11/02 7:51:13 PM Eastern Standard Time, [email-masked] 
writes:

> At 09:33 AM 3/11/2002, [email-masked] wrote:
> >At this point, it would be good to consider whether the possibility should 
> >be included for multiple levels of "authorized". (Note that the parallel 
> >work in SG16 on H.460.4 is leaning towards including such a capability.)
> 
> are these "levels of authorization" or "kinds of authorization"? My 
> experience with levels is that the discussion is always about winners and 
> losers: "my stuff is more important than his stuff, so I think there needs 
> 

The idea is that there could be many different agencies/persons/functions 
that need emergency access - FEMA, police, medical, Red Cross, network 
administrators, etc. It's hard to image that all would be treated the same. 
If there is only one possible level to apply to all, it would be very 
difficult to decide whether or not a particular group would get the 
authorization, e.g., is the Red Cross one that needs this? Providing a way to 
distinguish would help. Whoever administers the authorization to use 
emergency levels in a network would decide who gets which level. Within 
"emergency" there needs to be 3 or 4 levels. (Remember, In MLPP, or "Assured 
Service", one could think of the 5 levels of precedence as consisting of a 
"Routine" level, and then four levels of "emergency".)

> 
> What makes sense to me in SIP is a simple statement: "I assert that this 
> call is an emergency call". If you are not authorized to make that 
> assertion, the correct policy is to ignore the statement. If you are 
> authorized, the network will have a policy to apply such as "permit this 
> call even if we are well into the overload zone" or "drop a random call in 
> order to complete this one." The network should determine the policy, not 
> 

Not sure of your point. The standard should allow a way to designate 
sufficient levels of importance, in order for a network to apply whatever its 
policy is. I can certainly envision that a desired network policy is to 
control access based on the relative level of the emergency call and the 
authorization of the person making the attempt. The MLPP model is that each 
user is authorized to use up to a certain level, and may signal any level up 
to that one in a call setup. The question is: how many distinct levels are 
needed?
> 
> >4.1.2 Diff-Serv
> >
> >[snip] In this example, there would need to be the 5 drop precedence 
> >levels for EF, as well as for each AF class, since eventually there should 
> >be a need to apply precedence type services to other traffic types besides 
> >voice. Clearly, there are not enough available DSCP code points.
> 
> I think you have a very different understanding of diffserv than I do. When 
> you talk about a drop precedence for EF (which doesn't have a drop 
> precedence), what are you talking about - dropping packets, or dropping 
> 

The current draft shows "EF for voice, with signalling of bandwidth". 
Therefore it whould need to have multiple levels of drop precedence. This 
refers to dropping individual packets, since that is where the marking is. 
Actually, I think that EF only for the signaling and one of the AF classes 
for the voice packets would make more sense, as I suggested in Annex A of 
draft-pierce-sipping-assured-service.

> 
> Recall that in GETS, you don't get differing qualities of circuits. You get 
> differing probabilities of getting a circuit, but once you have a circuit, 
> it is just a circuit and works exactly like any other circuit. In IP 
> telephony, you might have varying call preferences, but once you decide to 
> carry voice at all, EF is the service that carries voice. If you're trying 
> to model GETS in IP Telephony, dropping packets makes no sense. Dropping 
> 

If GETS resulted in different routing, it might mean different circuit 
quality (better or worse). Yes, it was "just a circuit", so there were 
limited things that could be done to play with quality. IP provides other 
options.

Yes,dropping calls might make sense, but I recognize the dislike for 
"preemption" and understand that it isn't allowed some places. The point I'm 
making is that some resources can be stolen for the more important call by 
causing the less important call to drop more packets, thereby stealing some 
of its QoS. The result, when the QoS of the less important call gets 
intolerably bad, is for the parties to give up and disconnect, freeing up 
more resources. Meanwhile, the establishment of new calls is being controlled 
based on precedence (importance), so their reattempt is blocked.

Diff-serv AF provides the drop precedence for what I described above, without 
any change. Is there anything else that could do this?

> 
> >As described in draft-pierce-assured-service...
> 
> 

Certainly. My fast typing often gets ahead of by slow brain.

> 
> BTW, in view of RFC 2597 "Assured Forwarding PHB Group", which is often 
> called "Assured Service", I'd personally appreciate it if you could find 
> another name. My head snaps every time I hear the name :^)
> 
> I'm certainly sensitive to using a term for two things. Is the term 
> "Assured Service" used in specs, or just in everyday speech? We'll consider 
> other names.

Mike

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Mar 2002 12:49:21 -0800

At 08:08 AM 3/12/2002, [email-masked] wrote:
>administrators, etc. It's hard to image that all would be treated the 
>same. If there is only one possible level to apply to all, it would be 
>very difficult to decide whether or not a particular group would get the 
>authorization, e.g., is the Red Cross one that needs this? Providing a way 
>to distinguish would help. Whoever administers the authorization to use 
>"emergency" there needs to be 3 or 4 levels. (Remember, In MLPP, or 
>"Assured Service", one could think of the 5 levels of precedence as 
>consisting of a "Routine" level, and then four levels of "emergency".)

Perhaps, but you're mixing apples and orangutans. Providing a way to 
distinguish calls is probably a good thing. Using the standard that defines 
the label with which you identify traffic to define the policy to apply to 
those various distinguished kinds of calls dramatically reduces your 
flexibility, and brings you into a global space you are not thinking about. 
Being able to say "This is a FEMA Code 27 call" (distinguishing calls) is 
quite a bit different than saying "This is a FEMA Code 27 call, all 
telephone systems in the world including those deployed in Madagascar need 
to be able to understand what that means, and by the way that means that my 
call should be placed ahead of a call for the Red Cross but behind a call 
which might launch missiles" is quite another.

By all means, put identifying marks on calls. Leave the policy to be 
applied to those calls ("all telephone systems in the world including those 
deployed in Madagascar need to be able to understand what that means, and 
by the way that means that my call should be placed ahead of a call for the 
Red Cross but behind a call which might launch missiles") to the network.

It's not obvious to me, by the way, that '5 levels of precedence as 
consisting of a "Routine" level, and then four levels of "emergency"' is 
wise, or solves anything. Take a recent case in point: on September 11, the 
calls directing emergency traffic to the lower Manhattan or around the 
Pentagon were not "authorized" folks, they were Joe Citizen who was in no 
way special but happened to be on the scene. Cutting Joe Citizen out of the 
loop, while enabling "authorized" access to folks whose first instinct 
would have been to call home and say they were all right, would have been 
at least as disruptive to emergency services deployment as the fact that 
Joe Citizen also wanted to call home. Precedence makes sense when you have 
the power to choose; as I understand the GETS network, it doesn't choose 
whether or not to place a call as it does choose whether to let a person 
use specific network resources to accomplish that.

>>call even if we are well into the overload zone" or "drop a random call 
>>in order to complete this one." The network should determine the policy, 
>>not the standard.
>
>sufficient levels of importance, in order for a network to apply whatever 
>its policy is.

And who decides what is important and what is not? I think you'll find that 
someone standing on the corner watching people bleed will feel their calls 
are *very* important, while someone with a different perspective might 
decide that places where lots of people are bleeding are more important 
than places where only a few are. My point is that that the policy must 
describe how to make that decision - the network policy must decide whether 
one thing is more important than another. As such, it cannot be placed in 
the hands of the actor who has only a small part of the picture. It must be 
done by the network.

Therefore, you want the person making the call to identify the issue in 
some way, and let the network apply a pre-determined policy to decide what 
resources to apply to it.

>The question is: how many distinct levels are needed?

You have yet to demonstrate that the concept of "levels" is decidable on a 
global basis. Is a FEMA call more important than its counterpart in 
Madagascar? Is that a nonsense question? If it is a nonsense question, why 
are we discussing it in the context of a standard for products that will be 
used without change in both the US and Madagascar?

>>>levels for EF, as well as for each AF class, since eventually there 
>>>should be a need to apply precedence type services to other traffic 
>>>types besides voice. Clearly, there are not enough available DSCP code points.
>>
>>I think you have a very different understanding of diffserv than I do. 
>>When you talk about a drop precedence for EF (which doesn't have a drop 
>>precedence), what are you talking about - dropping packets, or dropping calls?
>

There are 51 posted drafts that contain the words "voice", "signalling", 
and "bandwidth". I have just reviewed all of them and have not found those 
words. Please advise - which draft are you thinking of?

>draft-pierce-sipping-assured-service.

As an author on AF, a material contributor to EF, and someone who has done 
a fair bit on trying to make voice work on IP, I am deeply confused by that 
statement. As near as I can tell, it results in a service that doesn't 
work. Are you available at the IETF to discuss this?

>"preemption" and understand that it isn't allowed some places. The point 
>I'm making is that some resources can be stolen for the more important 
>call by causing the less important call to drop more packets, thereby 
>stealing some of its QoS. The result, when the QoS of the less important 
>call gets intolerably bad, is for the parties to give up and disconnect, 
>freeing up more resources. Meanwhile, the establishment of new calls is 
>being controlled based on precedence (importance), so their reattempt is 
>blocked.

>Diff-serv AF provides the drop precedence for what I described above, 
>without any change. Is there anything else that could do this?

That's the wrong place to start. The requirements voice has are for minimal 
jitter, latency, and loss for a data stream of defined rate. EF 
accomplishes that by measuring rate, dropping excess, and giving priority 
to the rest. The requirements for TCP are at most one drop per RTT per 
session, and preferably those drops should come from data segments (as 
opposed to Acks etc) coming from TCP speakers who are sending relatively 
large amounts of traffic. AF offers a network administration the ability to 
identify those large sessions and isolate drops to them. By the way, the 
drop precedence is within AF classes, not among them. AF1 doesn't get 
dropped before or after AF2; AFx2 gets dropped before AFx1, and AFx3 before 
AFx2.

Moving VoIP to an AF service to get the drop precedence makes no sense. You 
give up all the capabilities that make voice work, in order to get that 
capability, and the capability you are seeking makes voice not work will 
for the disadvantaged users.

If what you want to define is an EF service with multiple drop precedences, 
I would strongly suggest that you define an EF service with multiple drop 
precedences. When you do, remember that in computer science there are three 
reasonable numbers: "zero", "one", and "many". I can tell you for sure what 
will happen if you prioritize some traffic over other traffic - loss, 
delay, and variation in delay (jitter) will be transferred from the 
prioritized traffic to the other traffic. I think I can tell you what will 
happen with two priorities if the priorities map respectively to voice and 
video traffic. Folks have done a zillion simulations on priority systems 
with more levels, and have not been able to demonstrate utility on a 
per-packet level.

>"Assured Service" used in specs, or just in everyday speech? We'll 
>consider other names.

it's mostly in speech, but it is widely used.

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