Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy -00.txt

From: Fred Baker <[email-masked]>
Date: Tue, 02 Jul 2002 22:13:26 -0700

At 12:00 AM 7/3/2002 -0400, Gunn, Janet NE wrote:
>OK.
>
>What, if anything, is the expected relationship between these traffic
>classes, and preferential "call admission" treatment?

The only calls I know of are in VoIP and video. in that case, you get 
bandwidth or you doin't in the admission process; once you have bandwidth, 
you have bandwidth, and there is no requirement for a separate data stream 
type.

The ones that have committed bandwidth - AF classes - don't have calls. 
They are internet data. They have SLAs, and if your SLA requires you to get 
a certain committed and a certain excess bandwidth, other traffic would 
become excess so yours would be committed - just like Frame Relay.

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 03 Jul 2002 12:31:44 -0700

At 10:13 PM 7/2/2002 -0700, Fred Baker wrote:
>They are internet data. They have SLAs, and if your SLA requires you to 
>get a certain committed and a certain excess bandwidth, other traffic 
>would become excess so yours would be committed - just like Frame Relay.

Let me clarify, because in making a reference to Frame Relay I was picking 
up on some points and dropping others, and probably really confused you.

The model behind EF is that of a constant bit rate circuit. In extending it 
to use AF services in video, the intent is to make a VBR circuit - AF 
provides the counterpart to the CLP flag in ATM. In both cases, however, 
there are three requirements:
  - the network has to agree that a particular call should get a certain
    bandwidth (done through admission - SIP or RSVP),
  - it needs to ensure that admitted traffic gets minimal jitter or delay
    (done through queuing - diffserv)
  - it needs to ensure that unadmitted traffic cannot abuse that service
    (done through policing)

One question, relevant to Mike Pierce's proposals, has to do with why the 
admission might be done using SIP or RSVP vs using a separate DSCP. That 
comes down to how one determines whether someone is authorized to use a 
certain DSCP. I can check that once and put the result into a access 
control list, or I can verify on every packet. I think you'll agree it 
wants to be checked once. That is, almost in its definition, the process of 
admission.

Let's talk a little about GETS and similar functions. When you place a 
telephone call using a circuit network, you touch some buttons, and a 
switch decides whether you should get the call (admission). If it admits 
you, you don't get a special circuit; you get a circuit like any other 
circuit, although it may have interesting routing. When you place a 
telephone call using at ATM network, you similarly talk to a switch 
(admission) to route the CBR circuit that will carry the AAL2 data stream, 
but once it is routed, the CBR stream isn't any different than any other 
CBR stream - it is just a CBR stream. In both cases, there are questions of 
potentially preempting another circuit or CBR VC, of taking reserved 
bandwidth because you are authorized to do so, routing through a network 
that is not available to other calls, or being held a few seconds to get 
access to the bandwidth of the next person to hang up the phone.

I submit that IP's EF service is most similar to the ATM case. You are 
going to admit or not admit the call, and there may be some interesting 
things done to enhance the probability of accepting the call. But once the 
call as been admitted, it has the bandwidth it needs. There is no reason to 
have a separate mark on the data, any more than there is a need to have a 
special kind of CBR circuit for emergency AAL2 traffic in an ATM network. 
The requirement simply doesn't exist. Mark it EF(voice) or AF4(video), as I 
have suggested, and you are done.

The model behind AF (RFC 2597) is that there is a service level agreement 
which, at minimum, says that traffic might arrive at any rate, and will be 
divided into two or more subsets with different markings. The expectation 
in that RFC is that this will be rate-based - traffic arriving at an edge 
device (what Frame Relay or ATM would call the DCE), which might be the 
router in front of the end system, or might be the edge interface on an 
ISP, or a number of other places, is measured according to its arrival 
rate, and at most <mumble> bps of traffic is marked "committed", at most 
<additional mumble> is marked with the next level, and so on until one runs 
out of levels. At any point in the network where congestion occurs, an 
active queue management such as Weighted RED is applied which results in 
packet marking (ECN) or loss being sent back to the sources sending at the 
highest rates, to get them to moderate their transmission. Relevant 
references include RFCs 3168, 2309, 2581, and 2582.

This is like Frame Relay up to this point; it is explicitly designed on 
Frame Relay's DE service and on ATM's VBR services. It differs from those 
in that there is no concept of a circuit in a connectionless network, but 
the model works reasonably well.

What I would do, to modify that for ETS from a generalized source, is say 
that the traffic accepted into the "committed" subset includes at most 
<mumble> bps, and by definition it includes traffic from/to authenticated 
and authorized systems. There is an interesting question on how the 
authentication takes place, but the point here is that their traffic is 
accepted as committed, potentially pushing other traffic to the "excess" 
position.

That said, it has not been shown, at least to my satisfaction, that 
Internet sources and sinks operate on the same basis as telephone system 
sources and sinks. I don't think folks randomly wander in and place calls, 
other than in a telephony environment. There is instant messaging, which at 
least as it exists today is largely a corporate offering entirely within 
AOL, Yahoo, or whoever, and those corporations can do things they deem 
appropriate. There are e911 services at web sites, and those web sites can 
prioritize things as they please. There is use of the Internet backbone for 
a variety of functions, but I don't see statistical evidence that the 
backbone itself becomes significantly congested, even under extreme load 
and in the presence of tens of simultaneous fiber cuts.

What becomes congested is access links (loss and delay) and servers (flash 
crowds, thrashing). The servers can prioritize their user's sessions as 
they will; that is not a traffic issue and has no bearing on this document. 
In the access links, the issue is essentially what traffic is more subject 
to delay or loss, and the servers and the edge routers are in a position to 
manage that within the diffserv architecture. But at the end of the day, 
the issue is whether a particular instance of an application will get 
certain service, or get less service, and exactly what service it needs. 
The diffserv architecture focuses on this "how to best serve the 
application" in describing a per-hop behavior.

If you want a DSCP for a class of user, here's what I need. Go read RFC 
3246, 2597, and 2474, and see what goes into an analysis of a per-hop 
behavior. Then come up with an internet draft that describes exactly what 
you expect the router to do on a per-packet basis because you happen to be 
an authenticated user. Do simulations and live fire tests, as have been 
done by myself and others in researching these PHBs, to demonstrate that 
they actually do what you expect them to do.

I, being one who has contributed to each of those RFCs and has some 
experience in doing this, think you will find this hard to do without 
knowledge of the application, and in the end I think you might agree that 
the approach I have taken is actually best for the individual and the total 
traffic. This is not intended to be a put-down or an arrogant statement, 
though it may come across as one. I'm telling you that you are coming from 
some premises that IMHO don't necessarily hold water, and the proposers of 
that model have not actually done the work to demonstrate their case. That 
is partly why it took so long to charter the working group, and why the 
current set of drafts don't reflect the user model you expect.