The MPLS WG Archive

["Naidu, Venkata" <Venkata.Naidu@Marconi.com>]

> Eric,
> 
> I interpreted David's statements to mean that you can get 
> completely bounded delay with variable size packets.  David,
> correct me if I am wrong.

ATM established that cells, which are a set of frames
that are all the same size, are preferred because they
help to eliminate unacceptable "delay variability". In
reality, the fact that ATM cells are short is more 
important than the fact that they're all the same size.

The key factor in controlling delay is to control how
long each cell - or frame - occupies the transmission
facilities. The time that the cell or frame occupies the
line - which we'll call "packet time" - is directly related
to the "packet length" and inversely related to the
transmission speed.

In fairness, we should mention that the maximum
packet size is at least as important as the fixed size for
controlling delay. That is, a frame-based network with
a small maximum packet size can offer the same
packet times as a cell-based network with equal
maximum packet size.

Thanks & Regards
Venkata Naidu


> For example, a commonly used MTU of 1500 bytes requires only
> 5 microseconds of transmission time on an OC-48.  Therefore
> it is possible to create a queueing mechanism where a high
> priority packet is at most 5 microseconds away from the 
> start of transmission. Queuing points in the rest of the 
> system (if any) can be handled in a similar fashion.
> 
> Implementations of these systems might not be as far away
> as you think.
> 
> Prabhu
> 
> 
> > -----Original Message-----
> > From: Eric Gray [mailto:eric.gray@sandburst.com]
> > Sent: Friday, April 20, 2001 8:39 AM
> > To: David Charlap
> > Cc: mpls@UU.NET
> > Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI??
> > 
> > 
> > David,
> > 
> >     I'm sure some smart person or another has written a paper
> > on this, but I don't have the time to do a full-blown literature
> > search right now.  While what you are saying is technically
> > true, I believe it has very little applicability in practice.
> > You can see that this works by imagining that an implementation
> > might treat MTU propagation time exactly the same way that ATM
> > treats cell propagation time.
> > 
> >     But this is very ugly.  It is so coarse that many would be
> > hard pressed to consider it a useful guarantee.  It also seems
> > to require deliberately inserting latency (N times an MTU
> > propagation time) for all affected traffic (to allow for packet
> > shuffling to accomodate the guarantee).  And it would be
> > very difficult to allocate forwarding resources efficiently and
> > still deliver guaranteed delay variation deterministically.
> > 
> >     Without making any moral judgement about why it is so,
> > many people are more concerned about having a bounded
> > delay than they are about having a bounded delay variation.
> > And with a bounded delay, you get bounded delay variation
> > for free.
> > 
> >     My opinion: there are two models here and trying to make
> > technologies support both models may not be a good idea.
> > 
> > --
> > Eric Gray
> > 
> > You wrote:
> > 
> > > Eric Gray wrote:
> > > >
> > > >     You can't exactly do ATM style QoS over non-ATM media.
> > > >
> > > >     The thing that allows an ATM switch to contemplate delay
> > > > variation separately from delay is the fact that ATM switches
> > > > switch data in fixed size chunks.  When the size of data chunks
> > > > can vary, the only practical way to control delay 
> variation is to
> > > > try to control delay.  Therefore, with IP packets on non-ATM
> > > > media, you can't even begin support two knobs for delay and
> > > > delay variation.  So why would you undertake to add complexity
> > > > by trying?
> > >
> > > Variable-size frames don't make it impossible.  It just 
> > means you are
> > > forced to work with a coarser granularity (defined by your 
> > configured
> > > MTU size.)
> > >
> > > -- david