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

From: [email-masked]
Date: Wed, 9 Nov 94 17:58 EST

In recent messages, two points have been made: 
1) Integrated services must adapt to available resources
2) We can't lose track of TCP while designing the future

While both points are valid, unfortunately, they do not go 
together particularly well.

Here's the problem: Suppose a 'real-time' application found out
that some bandwidth was available on some path, and used it
(lets say for adapting video or voice quality). Now, some number of
TCP sessions start up. If the real-time app does not back off,
the TCPs will, and this is probably bad for the TCPs. 
What should the back-off and start-up behavior of the app be?
If we have FIFO queueing, to me, the only 'fair' solution is for the 
app to behave exactly the same way as the TCPs (if it were more
aggressive, it would be unfair to the TCPs). Thus, the app
must buy into exactly the same flow control as TCP, if it
is to be fair. But, as others have pointed out, TCP style flow
control is not necessarily the best for all applications.
Thus, an app developer faces a problem - behave like TCP and
deal with periodic pauses with slow-start, or do your own flow
control and be unfair to other TCPs. 

There are several approaches to the problem

1) 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.
2) Don't be fair.
	TCP will suffer, and Curtis will flame you big time ;-)
3) Lets all do round robin.
	One day, maybe. Same problem as with 1.

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. I'd appreciate any thoughts or comments.

keshav

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 09 Nov 1994 21:51:25 -0500

In message <[email-masked]>, [email-masked] write
> the TCPs will, and this is probably bad for the TCPs.

No it isn't bad for TCP.  This is how it should work.

> control is not necessarily the best for all applications.

We (RFC-1633) have defined service classes that fall into elastic
and real-time.  You pick one or the other.  TCP is the application is
elastic, otherwise one of the real-time classes.  For example,
real-time delay tolerant, with delay variance adaptation.

> control and be unfair to other TCPs. 

You are not making sense here, since your prior argument was flawed.

> 	TCP will suffer, and Curtis will flame you big time ;-)

The intent of RSVP is to allow up to a administratively conmfigured
maximum portion of total link bandwidth to be reserved.  The rest goes
to whatever TCP applications and misbehaving stuff (NFS/UDP, etc) is
out there fighting for it.  I'm not opposed to RSVP or real time
traffic despite what you are implying (I see the smiley :).  If
another reservation is allowed and is added, the RSVP traffic gets
queued ahead of the elastic (less delay, no loss) and the elastic
backs off if the link was already full.

The two acceptable minimalist approaches for real-time are:
  1) FIFO queue with RSVP queued ahead of elastic --or--
  2) have enough bandwidth that it doesn't matter
If you don't do at least one of the two, RSVP (real time) won't work well.

For TCP, you need one of these two approaches:
  1) to be tolerant of TCP's burstiness - buffers and drop strategy
     are important --or--
  2) have enough bandwidth that it doesn't matter
If you don't do at least one of the two, TCP (elastic) won't work well.

For elastic traffic to work well (without enough bandwidth that it
doesn't matter), you also need to put a ceiling on how much traffic
you will allow reservations for and make sure the real time traffic
lives within it's reservations (policing of some sort on the real time
is needed - it can be primitive - or even advisory as a minimum
requirement).

Why is it that this WG is willing to state the minimum requirement for
RSVP to work well, but in not willing to state the requirements for
TCP to work well?  Or even acknowledge that it matters.

btw- Doing something elaborate may not mean it is good.  This WG
should be willing to state that if something elaborate is done wrt
queueing strategy or flow control, supporting evidence should be
available to show that *both* real time and elastic traffic will
continue to work well.

> problem ourseleves. I'd appreciate any thoughts or comments.

I don't think there is a flaw at all.  We do have fairly good support
of elastic traffic now and mediocre to poor support for a limited
amount of real time traffic.  Real time works well in the places where
one of the two factors for real time above is met (it just happens
that not much of the Internet meets those requirements).

Stating the real time requirements is a first step to getting the
problems addressed.  Same goes for stating the elastic requirements.
Why is this so foreign?

> keshav

Curtis

---

From: Christian Huitema <[email-masked]>
Date: Thu, 10 Nov 1994 11:10:34 +0100

>	One day, maybe. Same problem as with 1.

I have always felt that I was in the minority on this subject, but I may as
well explain why I believe that a combination of these approaches is important.

My first assumption is that a large proportion of the "real time" applications
are in fact elastic. This is based on experiments with IVS, reported in the
SIGCOMM-94 communication by Wakeman/Bolot/Turletti. You can demonstrate that
video and voice can operate over a range of throughput conditions; the feed back
mechanisms are very easy to design for point to point interactions, a tad more
complex but not undoable with group interaction. There is indeed a limit to
this; adapt within a group of 2 is easy, 10 has been done, 100 appears entirely
feasible, 100,000,000 would be somewhat more difficult. Well, I said "a large
proportion" - there are clearly some exceptions.

My second assumption is that there is no reason to priviledge one group of
users over another. You don't get special rights in the Internet just because
you bought a video camera. In fact, in the absence of special arrangements
(first class subscription, pay per view, reservations), the first approximation
of "fair" is indeed to give each user the same share. If that share is not
sufficient to run video efficently, this is just bad luck: you should maybe
stick to voice and white board, or maybe just white board if the bandwidth is
not sufficient to sustain a voice conversation. Indeed, one may expect that the
network is correctly engineered, i.e. that the in average the available share
of resources allows you to efficiently use the network.

Then, we may bring the theory in. The introduction of efficient feedbacks
mechanisms in TCP effectively "saved the net" in 1988. We have more or less
relied on TCP since, assuming that the congestion avoidance mechanisms
effectively result in "fair sharing". In fact, we all knew this was imperfect;
with the advent of "open loop" applications (e.g. some forms of video) this
"imperfection" is becoming less and and less acceptable. I believe that we have
to move from the "community" model, where good practices are enforced by social
pressure, to a more "contractual" model, where good practices are enforced by
the service provider. Scott Shenker's communication to the 94 SIGCOMM is very
convincing: we should do what the theory says, taht is implement fair queuing
because it gives users an incentive to "do the right thing", to use proper
feed back mechanisms in their applications. The good news is that it is very
easy to implement this strategy gradually, in some switches run by quality
conscious providers.

In fact, the providers could go further and define "classes of service" - there
is already some experience on "class based queuing". We have only explored it
in limited situations, e.g. for sharing transoceanic links. But we could
envisage to use this technology on a larger scale. Take the example of INRIA,
with 5 research establishments interconnected through one service provider,
RENATER. We could well imgine that RENATER sells us a "virtual network",
guaranteeing that whatever the other network user do, INRIA will always receive
a specified share of the network resources. Again, this kind of arrangements
can be done locally: there is no need to change all Internet switches. I truly
believe that we will see more and more of these arrangements, e.g. bilateral
contracts between providers to specify the resources available to transit
traffic. Actually, we may want to investigate the engineering of such
agreements, e.g. to develop "classification information exchange protocols"
similar to routing protocols.

Lets come back to the "special cases" which I mentioned above, e.g. "pay per
view video". This is the typical application for which some level of "resource
reservation" is expected: if you payed for a high definition version of "Basic
Instinct", you don't want to suffer from temporary congestion during the main
acts. In fact, there is a three party relation here: information vendors,
network providers, clients. The information vendors must have some guaranty
from the network providers that they will obtain sufficient bandwidth to run
their trade: this is a variation of the "virtual network" problem described
above. However, this guaranty is probably only effective in the network
backbone - the clients will have to reserve capacity for the particular
application. In that respect, we can see a way to insert reservations in the
global picture: clients are entitled, per their subscription, to some level of
resources. Within this level of resource, they use the reservation protocols to
tell the network about their preferences, e.g. the Basic Instinct
multicast rather than that of the IETF. Indeed, we can think of many
variations, e.g. bandwidth on demand for a fee. But I believe that the initial
introduction can be gradual, limited to one provider.

Well, this is already a very long message. I guess I should stop here, and
abstain to develop the contractual implications of multi-provider
reservations...

Christian Huitema