RE: stds-80220-requirements: Latency and packet error rates
Rex,
Thanks for the comments. The requirement is intended to cover "Delay and Packet Error Rate" guidance for the most common traffic classes only. Other classes can be defined for specific deployments.
Branislav
> -----Original Message-----
> From: Rex Buddenberg [mailto:budden@nps.navy.mil]
> Sent: Saturday, February 28, 2004 9:52 AM
> To: Branislav Meandzija
> Cc: Lai-King Tee; stds-80220-requirements@ieee.org; Humbert, John J
> [NTK]
> Subject: RE: stds-80220-requirements: Latency and packet error rates
>
>
> Branislav,
>
> There's one class of traffic that doesn't appear on your
> matrix: if you
> intend to use the networks resultant from this standard in
> some process
> applications then you need _determinism_ or _bounded_delay_delivery.
>
> On Fri, 2004-02-27 at 16:54, Branislav Meandzija wrote:
>
> >
> > Class Attributes of Traffic
> > -----------------------------------------------------------
> > Conversational | Two-way, low delay, low data loss
> > | rate, sensitive to delay variations.
> > -----------------------------------------------------------
> > Streaming | Same as conversational, one-way,
> > | less sensitive to delay. May require
> > | high bandwidth.
> > -----------------------------------------------------------
> > Interactive | Two-way, bursty, variable
> > | bandwidth requirements moderate
> > | delay, moderate data loss rate
> > | correctable in part.
> > -----------------------------------------------------------
> > Background | Highly tolerant to delay and data
> > | loss rate has variable bandwidth.
> > -----------------------------------------------------------
> Deterministic | Application requires bounded maximum delay
> | characteristics.
>
>
> This requirement is omitted from the IETF diff-serv docs because it
> simply isn't attainable across a multiple-segment routed
> network without
> doing terminal violence to the connectionless nature of the network
> layer. But it's practical to meet such requirements by providing some
> form of ___synchronous service in the bottleneck network segments
> (inevitably the radio networks) and overprovisioning the
> wired segments
> so they never become the bottleneck.
>
> We've been here before in wired networks; token networks had the
> theoretical ability to deliver determinism and FDDI had practical
> implementation. We've been here before in some radio networks too --
> Link 16 (aka JTIDS, aka TADIL-J) in the military delivers synchronous
> service using a TDMA structure.
>
> Most of the requirements justification that I can produce is
> military in
> nature -- weapons control is an obvious example. But I would
> guess that
> SCADA applications in commercial industry would be another example.
>
>
> BTW, viewing QoS requirements as purely latency ones is viewing QoS
> through a keyhole. QoS is adjusting the balance across several
> competing needs:
>
> 1. Bandwidth efficiency (aka throughput, but macro view)
> 2. Micro performance issues, incl:
> a. latency
> b. interactivity
> c. jitter
> (You've got a good handle on this in your post)
> 3. Determinism (aka bounded delay delivery)
>
> Help?
>
> > >
> --
> Rex Buddenberg
> Naval Postgraduate School
> Code IS/Bu
> Monterey, Ca 93943
>
> 831/656-3576
>