Subject: [Ieprep] Levels of priority and comments on ieprep framework

From: [email-masked]
Date: Sun, 17 Mar 2002 00:36:51 EST

To all,

Guess it's time I said what "Mike meant", since there have been several e-mails on this subject.

First, it seems that some issues need to be put to bed for good.

1. I never suggested, nor do I think, that we should resurrect the per packet priority marking of RFC 781 or define any new per packet priority forwarding scheme.

2. The per session priority addressed in the Resource-priority draft is exactly what it says, session handling. The DoD requirement for five precedence levels is satisfied by this draft.

3. The requirement as spelled out in draft-pierce-sipping-assured-service, is to provide certain preferential treatments to a call (session) which is marked with a higher precedence. That may include preempting one or more lower precedence calls or taking resources from them. The requirement is that the attempt to set up a higher precedence call can not be blocked by the presence of lower precedence calls. So far, nothing in the requirements addresses QoS.

4. Any suggestions for per packet marking or handling is a potential solution. I've realized from Fred's comments that I should not have been suggesting the use of AF. EF is the appropriate mechanism.

Jim Polk described a case which demonstrates my suggestion for a solution using multiple drop precedences (with a minor difference).

First, we are talking of a case in which all other traffic (data, etc) has already been pushed aside, so only voice traffic is left, all using EF. In Polk's example, with 19 voice calls at the lower (session) precedence level, each using 80kbit/s on a T-1, when a new call at a higher level comes along, it can steal resources from the others without actually preempting any.

Perhaps RSVP could be used to modify the reservation of each of the existing 19 calls to reduce each by a uniform amount in order to make room to establish the 20th path.

Using Diff-serv instead, this requires multiple drop precedences (for EF), just as already defined for AF. The 20th call, at a higher precedence, is setup even though it exceeds the available bandwidth, and its packets are marked with the lower drop precedence than the other 19. Whenever congestion occurs, based on queue length or whatever (as defined in AF), individual packets of the other 19 calls are dropped. Packets for the one higher precedence call (lower drop precedence) are not dropped. Yes, the result is that the higher precedence call gets better QoS, but that is not the requirement.

(The deviation from Polk's example is that there is no requirement to drop equal numbers of packets from each of the lower precedence calls. If a disproportionate amount are dropped from one call because of the specific packet sequencing, that is acceptable. If an implementation can figure out a way to uniformly distribute the loss when using Diff-serv, that's fine.)

If there are more than two levels of drop precedence, it is always the highest which is dropped. There is no added complexity. It works exactly as defined today for AF. I have not proposed any change to this. The open question is how many drop precedence levels are needed. At least three as currently defined for each AF class makes sense, but we would prefer 5 to allow direct mapping from the five session precedence levels to the packet drop precedence levels.

Mike Pierce

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

---

From: Sean Donelan <[email-masked]>
Date: Mon, 18 Mar 2002 12:22:28 -0500 (EST)

On Sun, 17 Mar 2002 [email-masked] wrote:
> First, we are talking of a case in which all other traffic (data, etc)
> has already been pushed aside, so only voice traffic is left, all using
> EF.

I am assuming that this is just a small hypothetical for the purposes of
responding to Polk's specific example.  Not a statement of how such a
system should work.  Starving all other traffic for the sake of voice
is a nifty way to make the data nets perform as badly as the telephone
system does under load.  In a real emergency we may find that e-mail,
blackberry, IM or some other data traffic is more critical (not to mention
better utilitization of scarce resources) than a voice call.  During
periods of limited capacity, voice, video and other high bandwidth
consumers may have the lowest priority.

That's why folks keep saying the "policy" needs to be seperate.

---

From: Fred Baker <[email-masked]>
Date: Mon, 18 Mar 2002 14:23:16 -0600

At 11:22 AM 3/18/2002, Sean Donelan wrote:
>In a real emergency we may find that e-mail,
>better utilitization of scarce resources) than a voice call.

in point of fact, per the reports to the national academy of sciences panel 
that met two weeks ago to discuss events on 9/11, the combination of 
voice-on-IP and data (including AOL distributing blackberry-based 
email/instant messaging PDAs) running over were among the few things that 
worked really well. One outcome I (and I hope we) want to truly avoid is 
making the Internet work as poorly as the telephone system does under load.