Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI??

From: "Kavi, Prabhu" <[email-masked]>
Date: Fri, 20 Apr 2001 09:01:18 -0400

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.

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:[email-masked]]
> Sent: Friday, April 20, 2001 8:39 AM
> To: David Charlap
> Cc: [email-masked]
> 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
> 
>

---

From: David Charlap <[email-masked]>
Date: Fri, 20 Apr 2001 13:12:59 -0400

> correct me if I am wrong.

Actually, Eric guessed right.

Bounded delay with variable-size frames is certainly doable.  The upper
bound will be the worst-case delay for all packets sizes.  I would
instinctively guess that this would be the delay incurred by MTU-size
packets, but this may not be true for all hardware.

Controlling delay variability with variable-size frames is more
difficult.  As Eric described, you may have to deliberately hold a frame
in one LSP and let one from another LSP get ahead in order to keep the
delay as constant as possible.

I think that per-LSP queueing (similar to ATM's per-VC queueing) can
accomplish most of this goal.

I do not expect this kind of hardware to be available until switching
hardware designed explicitly for MPLS is developed and built.

My point is simply that the signaling protocols should allow for these
kinds of parameters now (perhaps as optional TLVs) so that they don't
have to be extended when that kind of hardware comes into existance.

-- David