Re: [STDS-802-16] Power variation due to burst boosting.
Yes. And ok, my grey matter was mostly right but not entirely complete.
The exponential costs when you add more queues remains -- that's the
rationale for the four DSCP values recommended.
Note that the 'recommended' part (allowing 2**8) makes no specification
so n vendors will result in at least n different implementations ... not
something you can map .16 QoS behavior to. (And in practice, nobody's
doing that ... indeed most ISPs filter the DS byte at their border
routers and reset the DS byte to 0 thereby obviating a security
vector.
On Thu, 2006-09-07 at 14:46 -0400, Peretz Feder wrote:
> Hello Rex:
>
> Are you referring to the following from RFC 4594?
> If yes, it is allowing 64 values:
>
> From RFC 4594
>
> 1.4.4. Differentiated Services Code Point (DSCP)
>
> The DSCP is a number in the range 0..63 that is placed into an IP
> packet to mark it according to the class of traffic it belongs in.
> Half of these values are earmarked for standardized services, and the
> other half of them are available for local definition.
>
> 1.5. Key Service Concepts
>
> While Differentiated Services is a general architecture that may be
> used to implement a variety of services, three fundamental forwarding
> behaviors have been defined and characterized for general use. These
> are basic Default Forwarding (DF) behavior for elastic traffic, the
> Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF)
> behavior for real-time (inelastic) traffic. The facts that four code
> points are recommended for AF and that one code point is recommended
> for EF are arbitrary choices, and the architecture allows any
> reasonable number of AF and EF classes simultaneously. The choice of
> four AF classes and one EF class in the current document is also
> arbitrary, and operators MAY choose to operate more or fewer of
> either.
> PF: Is the above what you refer to as: "4 sticks in my grey matter
> RAM"
>
> On 9/7/2006 11:25 AM, Rex Buddenberg wrote:
> > No longer correct. When the Diffserv working group in IETF formed, they
> > looked at the question in some depth. Up to this point, the TOS byte
> > existed in the IPv4 header but was never used and never defined. The DS
> > group quickly figured out that 2**8 was a non-feasible answer and in
> > reality, only about 4 categories makes any sense. The reason is found
> > in the way routers handle priorities: each DSCP requires the router to
> > set up a queue for it and sort datagrams into that queue. At about four
> > queues, the CPU requirements for sorting head up an exponential scale
> > and cost more than any benefits to be gained. The experimentation
> > showed that non-priv traffic did indeed get poorer treatment (that's the
> > stuff in the lowest priority queue). But the priv traffic also
> > suffered!
> >
> > So when the TOS field was renamed 'DS byte', only a handful (4 sticks in
> > my mind) of DSCPs were defined.
> >
> > On Thu, 2006-09-07 at 01:29 -0400, Peretz Feder wrote:
> >
> > > TOS bits are 8 bit field. They can provide 256 DSCP values, no?
> > >
> > > On 9/5/2006 1:09 PM, Rex Buddenberg wrote:
> > >
> > >
> > > > As you think through this, it might help to bone up on diff-serv.
> > > > Appears to me that what you're really getting to is 'how do we map the
> > > > DSCPs to the QOS mechanisms in 802.16?' There are only a few DSCP
> > > > values (4 sticks in my grey matter RAM).
> > > >
> > > >
> > > > On Tue, 2006-09-05 at 15:57 +0530, vimalraj s wrote:
> > > >
> > > >
> > > >
> > > > > Hi Lee,
> > > > >
> > > > > According to my understanding
> > > > >
> > > > > 1. An 802.16 system shall not open a seperate connection for each
> > > > > upper layer protocol if packets
> > > > > form upper layer protocols have the same QoS requirements.It means
> > > > > that if a SS has two
> > > > > clients and both the clients supports Rtps & BE service,if the Rtps
> > > > > service from client_1
> > > > > has same Qos parameter as of client_2 supporting Rtps service,then
> > > > > both the data traffic can go
> > > > > through same connection?????
> > > > >
> > > > > if i went wrong plz correct me.
> > > > >
> > > > > 2. If the above statement is right then, if any one of the QOs
> > > > > parameters(max sustained rate,min
> > > > > reserved rate,Max latency,jitter,traffic priority...mandatory
> > > > > parameter for Rtps) varies then a seperate
> > > > > connection is to be established for a same scheduling service type
> > > > > (Rtps/BE)????
> > > > >
> > > > >
> > > > > please clarify my doubt...
> > > > >
> > > > > thanks
> > > > >
> > > > > vimal
> > > > >
> > > > >
> > > > >
> > >
> >
> >
>