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

From: [email-masked] (Noel Chiappa)
Date: Sat, 26 Mar 94 13:39:01 -0500

> 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.
 
    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 -

This sounds plausible, but I don't think I believe it.

First, how can the router know when two communicating hosts start up a new
instance of the application? For instance, without looking down into the
header quite some ways, it might not be able to tell. I'm also confused as to
exactly how they are going to "block" the new one; do they drop all packets
that they think belong to it? Suppose a packet gets through in a momentary
traffic lull, and then the application is going?

Second, how can the routers differentiate between the cases where i) there are
N flows going, but have more than their minimum required bandwidth, so it can
add one and drop everyone a little, and ii) there are N flows going, but each
is at the limit, and will shut down if cut back? Again, without knowing a fair
amount about the application, it seems difficult to do that.

Anyway, it seems to me that you have exactly the same amount of state,
enforcement mechanism, etc, with this as with flow setup. It's just that the
state is inferred from watching the packet stream (a more complex and less
likely correct process than explicit setup), and you have to figure out which
state block a packet belongs to, again, a perhaps slower and less likely
correct operation than explicit assignment via a header field.

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

Yup; that's what I was alluding to when I said that maybe adding resources
are the way to go.

On the other hand, note that the phone network does try hard to guarantee
resources to connections which are already set up. However, they don't provide
enough bandwidth to *never* run out. When the net *does* get congested (and
it does happen sometimes), this probably makes it more robust in that
operating regime.

    > 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, 

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

Does it really provide all the items Steve mentioned (1-5)? How general are
the resource semantics it supports? Even so, if it's being done on every
packet, it could be considered substantial, especially since, as I noted, all
it does it the resource stuff.

    what do you get extra with a call setup?

Well, you can get one-time authorization overhead, a more robust and
extensible routing architecture (with all the policy routing hooks anyone
could ever want), etc, etc, eytc. What extra do you get with your stuff?
(Also, I don't like the term "call setup" because in many minds it probably
invokes a somewhat different image than the one I'm thinking of. I prefer
"flow setup".)

    well, you get an O(n**2) headache with multicast,

I keep hearing people toss around "O(N^2)" like it's some kind of last word in
any debate about mechanisms, but in at least one case it was, on closer
inspection, provably wrong.

Exactly what is growing at O(N^2), and what's N? Do you mean that if you have
multicast groups where each source has a separate distribution tree, that
results in O(N^2) growth in state in each individual router through which
that tree passes, where N is the number of of participants in the group?

    and you get the user to give you some fictitious number they _think_ is
    the QoS they want...

Well, if the user can't quantify their application because they're a twit,
that's not my department. Now, if you could show me that the kinds of
applications we want to run are *inherently* non-quantifiable, then I'd be
more worried.

    i.e. not a lot

You seem to be looking at the pros and cons of flows entirely from the
resource allocation standpoint. This is wrong. The nicest thing about flows is
that they help a *whole bunch* of seemingly unrelated things (routing,
security, etc) all work better.

	Noel

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 28 Mar 94 16:23:06 +0100

>applications we want to run are *inherently* non-quantifiable, then I'd be

an FTP could use infinite bandwidth - it has no time requirement excep
the social urgerncy of the file being retrieved.

however, the cost of this is dependend on _the other traffic_

so how can the user quantify this

a video compression scheme is scene dependneent - should a user look
at the shirt they are wearing before bookingthe network call.

sorry, asking the user to state their QoS requirement in advance is a
nono., even though, as frank kelly says, it does lead to very neat
simplifications in the queueing systems, its a shangri la.

cheers

 >security, etc) all work better.
 
yes, i definitely agree flows re a good thing...specially when typing
from seattle :-)

 jon