Subject: Can pure datagrams really service real-time applications?

From: [email-masked] (Noel Chiappa)
Date: Fri, 25 Mar 94 12:29:32 -0500

> Well, what makes this "interesting" to discuss, and less than obvious
    > to implement, are the mechanisms used to provide the appications'
    > required quality of service under other than very lightly loaded
    > conditions (and without adding an inordinate amount of overhead,
    > resource overreservation, or other wastage).

    A possible answer is:

Steve, I have two reactions to your long list of mechanisms.

First, it doesn't really handle the congestion problem. There is a resource
floor that most of these applications need, and beyond that you just have to
shut things down, if you have the bandwidth to run N of the things, and N+1
show up. (Otherwise, back in the old days of undersea wires, they'd have just
let more and more calls on, degrading the quality of all...) Your suggestions
1-5 just move the point at which N is reached, without getting rid of N. I'm
not sure exactly what will happen when a new application tries to start up in
a loaded channel; in the worst case, after fair-sharing is imposed, they might
*all* shut down.

Second, you've got a fair amount of mechanism there, and it only addresss the
resource issue. I wonder if this isn't an example of the kind of thing I
alluded to, where in an attempt to avoid soft-state setup, we wind up with
some pretty complicated stuff, perhaps more complex than a simple biting of
the bullet. Such bullet-biting would also give us more efficient support for
policy, security, authentication, etc, which I'm not sure you list really helps
with.

    (6) no less link bandwidth than the alternative ATM infrastructure.
    More would be nice -- whether or not any such "wastage" is a
    good engineering choice will depend on the price of bandwidth,
    which is related more to policy/regulatory/monopoly issues than
    anything else.

This is an interesting point. Historically, it's often been the case that it's
been less expensive to provide more resources, enough more to allow use of a
really simple-minded allocation scheme, than do something complex which didn't
work well anyway. The example I always use is optimal paging algorithms; they
never worked really well, and we finally just went out and made memory cheap.

It is a fair point that maybe this is the way to go; just provide enough
bandwidth that simple mechanisms work well statistically, and you don't need
stuff to handle a congested system. The thing that worries me about this path
is that I'm not at all sure we can predict the future well enough to be able
to trust this solution.

At the same time, I'l cheerfully admit that my knowledge of resource
allocation issues is pretty sketchy, and maybe there are fundamental reasons
why, even in a system which is resource-rich, we still need mechanisms to
guarantee service. Can a resource-allocation wizard tell us more?

	Noel

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 26 Mar 94 17:15:30 JST

> guarantee service. Can a resource-allocation wizard tell us more?

As no link is 100% reliable, QoS guarantee does not mean that the
specified QoS is provided 100% of the time.

So they are not so different qualitatively, while quantitative difference
could be a lot.

The possible difference is that if we pay for each QoS guarantee, we can
be paid back if the guarantee fails.

							Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 26 Mar 94 14:54:21 +0000

>a loaded channel; in the worst case, after fair-sharing is imposed, they might
 
no - fair sharing is for established flows

the solution is to know that the new flow is new. (not hard, but done
implicitly ratehr than througfh call setup) same as call blocking in
the phone net - 

note that most the phone net is now engineered to
practically never call block - this is not through clever queueing -
its through adequate bandwidth!

oh, if someone thinks their packets are more important, they use the
appropriate _different_ flow type, and get through anyhow (or we could
just admit it, that this is priority, and get into charging...)

 >some pretty complicated stuff, 

the code we have that does this is only a few hundred lines of C

what do you get extra with a call setup?
well, you get an O(n**2) headache with multicast, and you get the user
to give you some fictitious number they _think_ is the QoS they
want...i.e. not a lot

cheers
jon