Subject: Re: Intserv/ATM mappings

From: [email-masked] (Mark W Garrett)
Date: Mon, 15 Jul 1996 09:56:46 -0400

)A question about whether nrt-VBR and ABR provide adaquate delay
)properties to support Controlled Load service.

Hi Lee,

Yes, I think nrt-VBR or ABR are the natural counterparts
to CL.  The reason is that they achieve low delay in the
same general style, i.e., by allocating bandwidth resources
for the flow.  Guaranteed and CBR or rt-VBR are more heavy-handed.
For these you say explicitly what delay you want, or for GS,
you can calculate from the advertised parameters exactly what
delay you get in the worst case.  For CL you get the delay (and loss)
behavior that would be characteristic of a lightly loaded network
of the given capacity R.  The non-real-time ATM classes would
work exactly the same.  (UBR doesn't do this because there is no
explicit bandwidth allocation parameter/mechanism.)  So, just because
it's non-real-time doesn't mean you get high delay.

There might be a slight difference in the perception or assumptions
about how the implementations might go.  So, suppose we're working
with a fair queueing type of scheduler which can virtually isolate
chunks of bandwidth and traffic.  There are two implementations that
come to mind immediately.  In the first case you make every flow (or
connection in ATM) a separate class in the scheduler, so they are
isolated from each other as well as everything else, modulo the
interference accounted for by the second and third terms of Parekh's
delay bound (or C and D in Guaranteed Service terms).  In the second
case, you pile all the flows together into a single scheduler class,
and allocate it the sum of the rate parameters of the flows.  (I'll
ignore buffer allocation here since it's harder, tho it's not
unimportant.)  I could see someone argueing that CL is the first case
and nrt-VBR is the second.

However, I believe there is nothing in either spec which disallows
either of these implementation.  Since CL says you get behavior like
an unloaded network of capacity R, you could read that as meaning
direct isolation between flows.  But, it also allows the implementer
to play with statistical multiplexing, and combining the flows in the
scheduler could be a form of that, as long as you convince yourself
that the performance is adaquate for the purpose of CL.  In ATM
nothing is said about delay, but you do have to allocate the bandwidth
in some sense, so there is a strong expectation that the resources are
there.  (For example, if you provided me a nrt-VBR service, and I
signaled a connection for SCR=2 Mb/s and turned on 2 Mb/s constantly,
I should not expect to get high loss or delay.  So if you really only
allocated me 1.8 Mb/s, and that's all I could get over some longish
period, the implementation would clearly fail to be adaquate nrt-VBR.)

We should probably discuss this on the list, instead of privately,
since others will have similar questions, no doubt.  Hope you don't
mind if I post this.

-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 1A-220B			+1 201 829-4439
Mark W. Garrett		445 South St.			[email-masked]
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
                        WWW: ftp://ftp.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 16 Jul 1996 06:13:33 +0100

generally, i find the borden/garret internet draft on this very
readable and useful....but...

ABR:

i don't believe ABR corresponds to a single int-serv service....albeit
it may be a 50% approximation

ABR is weird - i think its nearest is a 2 level spec made of
controlled load with tspec equal to the MCR< and some additional
service that is NONE of the existing int-serv models above that - the
issue is one of fairness enforcement and delay bounding versus
loss......

Iff you specified a mapping for controled load or best effort between
routers, you COULD specify _additional_ behaiovour on receipt of RM
cells (e.g. tail drop or RED on queue overrun) - but without that, you
have an incomplete behaviour.....

if you had an end to end ATM path under IP, again you'd need to
specify edge (host IP to ATM Edge Device) behaviour for each and every
QoS mapping.......for IP service class  X over ABR....

apart from that (i.e. is abr useful? i'd prefer cbr or vbr+ ubr as a
mix), its all fine....

cheers
jon