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

From: [email-masked]
Date: Thu, 10 Nov 94 09:27:27 MST

Christian,

That was a very clear and complete writeup.  So clear, in fact, that i
finally realized that i disagree strongly with what you are saying!

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

I don't believe that a service provider can do any more than enforce a
contract on "local resources" (i.e., bandwidth and cpu cycles within that
provider's part of the network).  I think that trying to enforce the
contract (or, provide the services at the level specified in the contract)
globally probably doesn't scale.  The net is made up of too many disparate
pieces to make any prediction "here" about what is going to happen "there".

The service provider is also unlikely to have enough memory and cpu cycles
to keep track of what each of its customers is getting in terms of *useful*
bandwidth (to know if the global net is living up to the *service
provider's* end of the contract).

Also, if the service provider detects, through some magic, that A is
getting more than its fair share in the global net, while B isn't, what is
the provider to do?  There is no way (that i can see) the provider can know
whether A's traffic is or isn't interfering with B's traffic (given that
the "denial of service" to B is happening "out there somewhere").

Additionally (or, for the same reasons), i think that the requirement for
*all* traffic on the net has to be that it *NOT* be open loop.  Van and RTP
have laid out one way of generating feedback for applications that might
seem "open loop".  There are some initial steps at making use of this
feedback (Wakeman, et al, at SIGCOMM 94).

I *suspect* that it is the end nodes, with hints and allegations from the
routing infrastructure, which are going to be able to push bits into the
black box of the global net, see what comes out, and figure out how to
adapt.

I also believe that "what comes out" will be determined by, among other
things, mechanisms such as admission control, fair queuing, class based
queuing, etc., at various points around the net.

(The task of a router is "given all the packets i've got, which should i
transmit now, which should i queue, which should i drop?"  This is a fairly
*local* decision and the router, especially a "backbone" router, is going
to want to make that decision with knowledge that is as local as possible,
ideally "who is connected to me"" or "who, immediately, sent me this
packet?".)

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

If i understand it correctly, the original model for "class based queuing"
is something like "agencies A, B, C, and D are sharing a link; each of them
is using protocol families P, Q, and R; within each protocol family there
is some ranking of time criticality into class X, Y, and Z".  Now, it may
take a relatively large database to look at a packet and decide the
*agency*; ultimately, however, you are mapping into a relatively *small*
set of scheduling classes.  I think that will work.  However, i'm not sure
that anyone has thought seriously about, let alone prototyped, anything
that tries to map into a large number of classes.

Your "virtual net" has the same problems i was worrying about above.
RENATER can guarantee you some level of service as long as your traffic
stays within RENATER.  And, they can do that in a "statistical" way which
keeps costs down.  However, i don't see how RENATER will be able to
guarantee *you* worldwide bandwidth.

Greg

---

From: Christian Huitema <[email-masked]>
Date: Thu, 10 Nov 1994 17:50:19 +0100

>guarantee *you* worldwide bandwidth.

Greg,

Maybe I was not so clear, after all. I do indeed believe that guarantees can
only be contractual, hence cannot be extended outside of the domain of
administration of the provider, except maybe through further recontracting with
fellow providers. Outside of the contracted domain, you have to be elastic.

Christian Huitema

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 10 Nov 1994 14:31:41 -0500

> fellow providers. Outside of the contracted domain, you have to be elastic.

For global conferences (IETF meetings, etc) you will probably be able
to graft onto a multicast tree that exists for other reasons (for
example US NSF funded the US portion of the tree, joint US/Europe
funding of the cross Atlantic, European network provider consortium
funding within Europe, and you payed INRIA a hopefully small
incremental fee to graft your site to the tree).  Even a commercial
site could pay only locally to graft onto such a tree.

For a private commercial video conference, the participants are going
to have to foot the end to end bill.

That makes sense and seems to be how the Internet is evolving (IMO).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 10 Nov 1994 14:23:58 -0500

> the "denial of service" to B is happening "out there somewhere").

A router (or switch) can only make decisions based on local
information.  The "some magic" may be the RSVP classifier and a check
of policing criteria (if policing is done) fro real time.  The "some
magic" for elastic may be WFQ and applying drop to individual queues.
For elastic traffic, it is sufficient to use a single queue if
fairness is a goal and applications are mostly well behaved (ie: are
using TCP).  The simplest feedback is to do a pseudo random drop as
the queue gets large and remains large (or tail drop on overflow, but
that doesn't work as well) under the assumption that the probability
of drop for any particular stream will be proportional to that
stream's proportional use of the bottleneck at that point in the
network.  This "magic" is not hard to do.

> black box of the global net, see what comes out, and figure out how to

What we are then talking about is providing advise on how equipment
provides this feedback or criteria which can be used be quantify how
effective a feedback strategy is.

> ideally "who is connected to me"" or "who, immediately, sent me this

Yes.  These are local decisions and this is the topic that the WG is
going to set out to address.  The WG will not be dictating algorithms,
just requirements and if possible criteria to quantify how well
various approaches works.  This way vendors, other WG or other
standards organizations have IP requirements and criteria to evaluate
their proposals or implementations against.

> that tries to map into a large number of classes.

The first is "link sharing".  The example here describes hierarchical
QoS.  You could further generalize and say that there could be a
hierarchy of general purpose classifiers.

What is described here is a solution.  What would be prefereable is to
extract the requirements that led to proposing this solution and
describe how other solutions can be evaluated with regard to their
ability to meet the requirements.

> guarantee *you* worldwide bandwidth.

That is fine.  RENATER isn't going to be paying INRIA for reserved
bandwidth in certain "other" parts of the network.  And the US NSF may
not pay a US regional network for reserved bandwidth in INRIA (or
maybe they would if there was some collaborative research involved).
If INRIA has an agreement with for example the UK then link sharing
can be extended.  (Let's not debate the political feasibility of
various funding or provider agreement combinations, please!).

The mbone will probably continue to exist on the informal agreement
among network providers supporting research needs to set aside a
certain amount of bandwidth for worthwhile conferences or events of
world interest.  But Xerox Parc or UCL will probably never pay anyone
to reserve worldwide bandwidth for a distinguished lecture and in many
parts of the world, the reservation will either be made gratis, or the
traffic will flow with no reservation.  In other parts of the
Internet, receivers will have to pay for a reservation that covers the
commercial leg needed to graft onto the "free" research mulitcast
tree.  There might be no reservation at all on their local ethernet.

Curtis

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 13 Nov 94 12:30:06 +0000

van played this clever game in 1988 with TCP _ he said

if we all play fair, what is the best we can do - then if we are all
selfish what is the best we can do - then if playing fair does better
for each individual than being selfish, then it is selfish to play
fair. this is a version of the denning/hofstadter iterated prisoners dilemma
and the result in the context of a best effort fifo net is
the TCP slow start/congestion avoidance system (with a nuimber of
small variants)

however, once the network is not a simple fifo system, but
distinguishes different traffic types, even down simply to soruces and
can adapt and police dynamicslly, the assumptions in slow start are
quite possibly just not optimal any more - if the net can police each
TCP flow to the current fair share, then we get quarantining of flows,
then we can use any scheme to find the current allowed share as fast
as possible,....

now, if we can, we can also use this flow for real time, and simply
drop the retransmissions for a flow that can't tolerate a step
function in delay varation of 1 rtt.....

so where is the distinciton any more?

 jon

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 14 Nov 1994 11:46:26 -0500

> so where is the distinciton any more?

What does this do for heterogeneous networking?

You can probably get rid of TCP if heterogeneous networking was a
non-goal.  Otherwise, I don't think you can.

Curtis