Subject: Re: TCP versus real-time apps in an int-serv internet

From: [email-masked] (Noel Chiappa)
Date: Fri, 11 Nov 94 03:51:58 -0500

From: [email-masked]

    Here's the problem: ... If we have FIFO queueing, to me, the only 'fair'
    solution is for the app to behave exactly the same way as the TCPs ...
    There are several approaches to the problem ... Lets put the real-time
    apps and TCP in separate classes. This will work. But if there is even one
    shared FIFO gateway, and this gateway becomes overloaded, even
    temporarily, then we are back to square one.

I think this is the way you have to go. You have to put the elastic traffic
like TCP in a class, and make sure it doesn't interfere with guaranteed
service classes.

I'll go one step past that, and say that to be really robust, you probably
need to separate out different TCP streams. VJCC works fine, and shares
bandwidth evenly among all comers, but a "bad guy" TCP which was tweaked could
grab more than an even share. I don't know if that degree of robustness is
a real need, but the possibility is there.

    I think that this line of thought reveals a possible flaw in the
    gradualist approach propsed by the int-serv co-chairs.  I don't claim to
    have a solution. But we certainly ran into the problem ourseleves.

In my comment to Sally, I was effectively proposing that you try and use
the routing to ensure that your path stayed, if at all possible, through
routers which supported the Int-Serv discipline. If you can, great, you're
set.

If, on the other hand, you want get from here to there on the green paving
stones, but can't, well, then you're basically stuck, no matter when you do.
Like you say, if one of those non-Int-Serv FIFO routers goes overloaded, you
lose.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 28 Nov 94 13:52:07 -0500

From: Christian Huitema <[email-masked]>

    The pricing approach to sharing is not new - I remeber studying it in
    economy classes, and that was quite some time ago. Have you tried to model
    it in practice ... This is generally where strict price based models fall
    apart.

Yes, it's going to suffer all the stability problems that any market does,
especially long-term instabilities. (E.g. price gouging by monopoly providers
who have driven competition out of business.) However, I think that it can be
as stable, short term, as any other resource usage feedback mechanism. As to
the long-term instabilities, I expect those would occur even with flat-rate
pricing, so I don't see that we're any worse off there either.

    DiSimone's paper does provide a hint on how to compute prices, i.e. in very
    much the same way that he computes the capacity loss caused by alternate
    routings. ... The price you sell it has to be larger than the product of
    reduction in service times number of affected customers.

Right, I didn't want to go through all the gory details, but I think you want
a pricing function which multiplies a "base" price by a factor which is a
curve which is asymptotic to infinity, based on load.

There are tons of details, like do you raise prices on existing reservations
(for this one, you probably only guarantee of price over a time quantum, and
get to adjust it at the end, otherwise people will open connections at
low-cost times and hang onto them at high-cost, which has the intersting side-
effect off allowing them to make money reselling them capacity, etc, etc, etc,
etc), etc, but I think they all have solutions (at least as much as any free
market system does).

	Noel