Subject: Some words from the cochairs...

From: Scott Shenker <[email-masked]>
Date: Fri, 4 Nov 1994 17:53:58 PST

The cochairs of this WG are writing this note to discuss some
clarifications and corrections to our approach.  We'd like to take a
minute to describe our current thinking, and we ask for your comments
and advice.  As our charter states, the purpose of our WG is to specify
an enhanced IP service model.  Below we discuss two questions: (1) what
goals we should keep in mind when designing this service model, and
(2) how should we go about standardizing this service model?

**What goals we should keep in mind when designing this service model?**

We think there are two main goals.  They are related, but still
distinct.

The first goal is to help the world-wide Internet grow to include a
broader range of services, particularly services useful to support
"real-time" applications of various kinds.  To do this, we must
consider both what we -need- to support these applications, and
what we -can actually do- given the loose federation, decentralized
management, multiple service providers, and mixed pricing models of
the Internet.  Our technical work and our deployment strategy have to
take these factors into account.

The second goal is to ensure that the Internet Protocols are useful
over a wide range of circumstances.  We want the IP suite to have a
rich enough feature set so that if someone wants to build a
higher-performance region of the network, or a separate smaller
internet (e.g., with all subnets capable of offering strict delay
bounds to support nuclear reactor control), they can use IP rather
than some other solution.

We recognize that these two goals may conflict.  There are things you
can do in a centrally controlled network that just won't work in the
entire internet.  Part of the fun is to do the best we can for both
worlds.  We now turn to our second question.

**How should we go about standardizing this service model?**

The basic (though perhaps implicit) operating assumption in the initial
Internet Draft circulated to this working group, and in several of the
presentations to the group, was that all routers, in order to be IP
compliant, had to support the new service model, and that "supporting
the service model" meant providing -all- of the services in the model.
We now realize that this approach appears to be misguided, for at least
three reasons.

The first problem is that no progress can be made without consensus on
the basic set of services to be included in the service model.
Unfortunately so far we have little experience with these services,
and it is hard to resolve differences of opinion without a period of
experience and experimentation.  For instance, the cochairs (along other
interested parties) have been unable to reach agreement among
themselves on the nature of Predictive service; does it imply a
quantitative delay bound, and if so, how should that bound be
calculated?  This inability to reach consensus is mostly due to lack
of supporting evidence for any of the proposed solutions.  It thus
suggests that a viable design should allow exploration with a variety
of approaches.

The second problem is that the assumption of universal deployment of
all services makes it impossible for the architecture to smoothly
migrate to a new service model.  Even if we could agree on a single
comprehensive set of services, it would be completely impossible to
immediately deploy these services in all routers.  Thus, we would
inevitably have a period when many Internet routers would be deemed
noncompliant with the service model, and perhaps not usable by
applications that assumed that service model.

The third problem is that of diverse subnet technology.  There will be
many subnet technologies which will be incapable of supporting some of
the services in the new Internet service model.  This is partially
because of a lag time in updating technology, but also because some
areas of the network may decide to overprovision bandwidth rather than
providing QoS capabilities, and because some areas of the network may
simply have other constraints. It's important to explicitly incorporate
such heterogeneity within the architecture.

Thus, we obviously need to approach this problem differently.  In doing so,
we should keep in mind two key axioms:

  - As much as possible, the network should provide the services
    applications need.

  - As much as possible, applications should adapt to the service the
    network is providing.

This may seem obvious, but it contains a critical point; the level of
service available in different parts of the internetwork can and will
always differ, as it does today.  We view this as a feature, because
it gives us some hope of getting new services deployed, and because it
reflects the Internet's administrative realities.

With this in mind, we now propose an approach whose principles we briefly
describe below.  
  
1)  The service model is extensible.  Services can be added, but
existing services cannot be modified or deleted without upsetting
users.  Thus, changing widely used services is extremely hard, while
changing little-used services is still possible.

2) At any one time there is a single IP service model (made up of many
services).  A client can ask for any of these services and the network
will understand this request. 

3) A region of the Internet need not support all of the services.  It
merely needs to know how to say "no, I don't do that service" (which is
different than saying "yes I do that service but no I don't have
capacity to handle you right now").  The meaning of this is clear in
the case of admission controlled services.  The idea also applies to
best-effort services.  For example, routers and subnets might map
"priority" requests into a single service (e.g., all priority levels
compressed into a single level) and still be in compliance.  It is not
yet clear how we should deal with possible future requirements that
routers/subnets implement some sort of fairness for best-effort
service.

We assume that the majority of applications will be adaptable enough
to make the best use of the services available, rather than simply
giving up. A variety of techniques for doing this have already been
developed and demonstrated in the internet community. We further
assume that the interface between applications and the network will
support this adaptability.  This may imply some new application
modularity, which will be the subject of a future discussion.

4)   The router requirements document is a series of if statements:

	If you support X service, then you must do Y

Such statements enforce a universal definition of the service X.
However, they do not mandate universal deployment of that service.
The standardization of services will follow the traditional IETF
standardization procedure.

5) The service model is not reduced to the lowest common denominator.
Just because we will likely always have ethernets in the Internet, we
should not restrict the service model to those services which can be
supported by an ethernet.  We are designing IP, we are not designing
the Internet infrastructure (i.e., we are not determining the set of
services available throughout the current Internet infrastructure).

6) The marketplace will determine which services the network actually
supports.  This does not mean that the IETF, and this WG, won't provide
coordination and guidance (e.g., in perhaps recommending the set of
services for the initial deployment).  Moreover, the modularity of this
approach does not mean that the WG merely accepts all proposals for
services and abdicates all design responsibility to the marketplace.
The WG will attempt to define a consistent and complete set of services
for the IP suite, though not for the Internet itself.  We intend to
document those services in a Router Requirements document.  However,
the nature of the document will have changed somewhat.  Before, we
envisioned it as a rather static leather-bound tome; it described what
every router had to do, and the introduction of new material would be
done very rarely and with great trepidation.  Now, we view it more as a
loose leaf binder, where it describes the set of services that a router
can select from, and new services can be introduced much more freely.

7) At some point, IP standards compliance may require a minimal subset
larger than what exists today. This is a secondary step, to be done
(if at all) at a later time.  We don't have to worry about it now.

We propose discuss some specific implications of this approach at the
next IETF WG meeting.  We also expect to have drafts of the first few
entries into the Router Requirement document.  We invite your comments
and advice on what we have said here.

--The cochairs

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 07 Nov 1994 10:13:45 -0500

In message <[email-masked]>, Scott Shenker write
> take these factors into account.

Let us not lose track of the importance of elastic applications in our
embrace of these new and "real cool" real time services.

> than some other solution.

The applications that need strict delay bounds are few and far
between.  Again, lets not lose track of what TCP and IP do well (TCP
shares bandwidth rather equitably, is able to function over a range of
speeds of 4-5 orders of magnitude, and makes efficient use of
available bandwidth, despite changes in application's offerred load)
and forget that it is a requirement that it continue to do it well.

Perhaps another goal might be to characterize criteria for evaluating
how well an underlying media supports IP and particularly TCP.
Routers with inadequate buffering is now becoming an operational
problem due to increases in delay bandwidth products of paths.  Tail
drop in routers was never optimal.  ATM is a disaster so far with tiny
buffers and packets chopped up into little cells and tail drop on the
cells.  The seems to be a need for a clear statement of IP
requirements (or factors that will make TCP/IP work better).  Having
criteria to evaluate against might encourage improvement.

> such heterogeneity within the architecture.

So throw the delay bounds idea out the window and move on!

One of the most useful things that came up was link sharing.  This can
be implemented within a subset of the topology and provide a great
deal of benefit.  For example, the subset may be a carrier's network
where a high bandwidth allocation is divided among a relatively small
number of beneficiaries of a research contract, a smaller bandwidth
allocation might be shared among an enormous number of beneficiaries
of research funding to provide quality basic connectivity, various
commercial arrangements might be made with varying quality guarentees
(or predictions), and budget commercial IP service might be available
with a smaller bandwidth allocation shared among a user community.
This is different than making guarentees on a per connection basis.

>   - As much as possible, the network should provide the services

Absolutely!  And we should take a good look at the current application
mix and see what can be done to better accommidate them as well as
expending effort to support new applications that the chairs postulate
will be very important in the future.

> reflects the Internet's administrative realities.

Nice to have you back (in reality that is).  ;-)

> services available throughout the current Internet infrastructure).

There is nothing to prevent us from asking that RSVP reservations be
queued ahead of elastic traffic.  If they get slowed down by
collisions on an ethernet, that is not terrible.  It may still be
possible to configure the borders of an ethernet infrastructure to
limit the number reservations to make it possible to keep traffic
flowing.  Perhaps we just bhave to be a bit more creative, like
defining an ALL_RSVP_ROUTERS multicast address and a protocol to
coordinate and limit the amount of RSVP reserved traffic on any
particular segment, which would work well enough.  We can certainly
also provide guidance to improve the handling of elastic traffic on
ethernets and maybe prevent future ethernet cards with a total of 4 kB
of memory on card.

> can select from, and new services can be introduced much more freely.

And so far the market has spoken strongly in favor of elastic
applications such as WWW, gopher, ftp, WAIS, smtp, nntp.  WWW now does
multimedia things quite nicely.

> (if at all) at a later time.  We don't have to worry about it now.

Let's go for incremental change.  First get support for elastic
traffic right and provide support for a limited aggregation of
reserved traffic.  I'm willing to contribute text to the "get elastic
traffic right" part of the effort.

> and advice on what we have said here.

May we see these Router Requirement entries prior to the meeting and
have ample opportunity to discuss them beforehand?

Curtis

---

From: "Amit Gupta" <[email-masked]>
Date: Mon, 07 Nov 1994 14:15:18 PST

Hi Curtis

 Thanks for your detailed (and well-argued) comments. I would like to add the 
following (all strictly MHO)

1. In research, our decisions (and inferences) are based, to a large degree, 
on the set of assumptions that we are willing to make; e.g. the telephone 
companies assume that they can (and the do) control all the switches and the 
switch software inside the network; TCP assumes that it can not control 
anything inside the network (hope for reasonable behavior, at best) and that 
significantly impacts the research agenda and conclusions. 

2. Given that these assumptions have considerable impact on the research 
agenda and results, we should try our best to ensure that the assumptions are 
mostly valid; however, we can never predict the future with certainty.

3. The int-serv group "assumes" that we will need to provide support for 
real-time as well as for "elastic" applications. The research agenda follows 
that we should support these in an integrated framework, in which we can 
seamlessly integrate (as far as possible) support for these different types of 
applications.

4. You have suggested many interesting problems; however, I would contend that 
(most of) these problems are not appropriate for this forum.

5. Different service provider (and different consumers) have different sets of 
requirements and preferences; for some, the more important concerns are that 
the service make efficient and equitable use of available resources; for 
others, the quality of service assurances may be more important. While the 
current WWW multimedia may appear "good enough" for some, the others may find 
it unacceptable. Also, a network service provider may have a different view 
(from the one held by) a switch manufacturer. A service provider may not even 
like the idea of applications using more resources than what they have paid 
for, even if the extra resources are "going waste"; these are policy issues, 
and we should avoid dictating these to the service providers.

6. It is difficult for the market to speak up when alternative services are 
not available. IMHO, it is not very reasonable for us to predict that realtime 
services will not succeed, based solely on the current acceptance of "elastic" 
network services.

thanks

-amit

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 08 Nov 1994 00:50:01 -0500

Amit,

In message <[email-masked]>, "Amit Gupta" writes
> significantly impacts the research agenda and conclusions. 

Perhaps your research assumptions have failed to take into account the
existance of IP providers who are not telephone companies.  Your model
does not cover the current situation adequately and unless you foresee
the successful erradication of IP providers by the telcos, your model
doesn't fit the future either.

> (most of) these problems are not appropriate for this forum.

What do you feel is inapproproate for this forum?  The framework calls
for support for elastic applications and I would like to see it
documented what factors effect elastic applications based on TCP.  I
see this as fitting within the charter of this group.

For example:

Is this inapproproate for this forum?  I think not.  Particularly if
we are now drafting router requirements.  Why should our router
requirements only address the requirementsa of real-time services and
not those of elastic services.

I also brought up link sharing which was a key feature in a previous
draft considered by this group, so I hardly see how it can be
inappropriate to bring it up.

I also suggested that it might be possible to do real time on ehternet
or similar networks.

Maybe that level of detail may be more appropriate for the RSVP WG.  I
though it just suggested a possible feasibility which would be
relevant to the comment made by the co-chair "Just because we will
likely always have ethernets in the Internet, we should not restrict
the service model to ...".

My mentioning the popularity of elastic applications should not be
construed as a condemnation of real-time:

And I think WWW does mpeg video and audio just fine.  No loss at all.
On my SGI one hop from the T3 backbone, it is fast.  On my BSDI PC at
home, over a 14.4 PPP link the transfer is slow, but it works fine.
WWW isn't remote conferencing, but it does what it does very well.

> and we should avoid dictating these to the service providers.

So what if telcos would prefer to waste bandwidth.  IP providers will
continue to buy bandwidth in bulk from the telco providers even if
they prefer that IP providers did not exist.  And IP providers will
continue to resell bandwidth for IP at prices way below what the
telcos will be willing to provide for point to point switched services
for fear that these switched data services will begin to be used for
voice and kill their cash cow.

The IETF is not here to be the pawns of the telcos.  We have the ITU
for that.  You seem to be agruing that the telcos will not like this
and therefore it should be "not appropriate for this forum".

> services will not succeed, based solely on the current acceptance of "elastic

I am not predicting that realtime services will not succeed as you
claim I am.  I believe they will suceed, though more slowly than some
predict.  I am willing to predict that elastic services will not go
away and will remain important.

It is fine for rsvp to concentrate on real time.  I don't think the
"integrated service model" that comes out of this group should be one
where elastic applications should be ignored in favor of real time
services.  Both are important.  Both should receive attention in the
documents produced by this group.

Curtis

---

From: "Amit Gupta" <[email-masked]>
Date: Tue, 08 Nov 1994 11:01:56 PST

Hi Curtis

 At the end of a long and well-argued article, you wrote:

I don't think the "integrated service model" that comes out of this group 
should be one where elastic applications should be ignored in favor of real 
time services.  Both are important.  Both should receive attention in the 
documents produced by this group.

 I agree completely with these sentiments. 

 I also feel that some of the issues (characterizing criteria for evaluating 
suitability of ATM/other media for supporting IP and TCP) are outside the 
scope of this forum, but that is just my opinion. I probably disagree with you 
on how well the current WWW does multimedia, and on whether the IETF activity 
should take into account the likely impact on profitability of non-telco IP 
service providers, but this is probably not the forum for discussing these 
issues. 

 thanks

 -amit

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 08 Nov 1994 15:55:46 -0500

In message <[email-masked]>, "Amit Gupta" writes
:
> scope of this forum, but that is just my opinion. 

I'm not suggesting we disect any particular media.  Since we are
striving to better take into account reality, we might consider
acknowledging that TCP is the overwhelming predominant means of
delivering elastic service.  TCP performance degrades when there is
too little buffering.  Drop strategy affects TCP performance as well.
Since the correlation between buffering and drop strategy is well
known and well documented and affects performance significantly, we
could document that fact.  We may be able to agree on some broad
statements about what the relationship between buffer capacity and
queue drop strategy is, but if not, acknowledging that there is a
correlation might be a help just in itself.  It would also be useful
to state the need to evaluate any media with an internal flow control
as a component in a heterogeneous media network and point out some of
the well known and well documented difficulties in handling TCP
(burstiness, potential synchronization of flows, etc).

> I probably disagree with you 
> on how well the current WWW does multimedia,

That's fine.  Let's agree to disagree.

> and on whether the IETF activity

I'll agree with that too.  If the telcos drop their switched service
prices and run all the IP providers out of business that is all the
better for IP users as long as they don't turn around and raise them
shortly after (but there would certainly be cries of foul play if that
happenned).  That is not an issue for this group.

IMO: If anything the service model should best serve the IP user
community.  That means not gearing requirements to any party (IP
providers, telcos, vendors of any one technology) at the expense of
the user community.  Keeping the opportunity for choice available is
key to best serving the users.  

Do you see more clearly characterizing requirements of TCP as somehow
serving the IP providers profitability at the expense of end users?

In summary:

  The ability to support elastic traffic will remain a critical
  requirement of routers or switching equipment supporting IP.

  TCP is the defacto means of delivering elastic service today.

  The ability to Support TCP well will remain a critical requirement.

  The ability to support TCP in a heterogeneous network will remain a
  critical requirement.

  We have yet to agree on what we can say about factors that affect
  the performance of TCP (if anything).  Whatever we say must be media
  and implementation neutral, though the requirement to support
  heterogeneous networks will certainly impact how some media and
  implementation fare when considered.

  Real time is also important and there are plenty of people standing
  up and stating requirements of real time services.

At what point did I go wrong here or step outside of the scope of this
WG?

Curtis

---

From: "Amit Gupta" <[email-masked]>
Date: Tue, 08 Nov 1994 13:48:17 PST

Dear Mr Curtis

 While I believe that you have raised several important issues, IMHO, 
(at least some of) these are more suitable to the "Router Requirements" 
type of WG (maybe in their "Link layer Requirements" document, which that 
group is yet to decide on). But again, that is just my opinion.

 I hope we can take the rest of this discussion off-line.

 thanks

 -amit

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 09 Nov 94 09:03:41 +0000

>WWW isn't remote conferencing, but it does what it does very well.

WWW does it just wrong

either you have to TCP the whole thing over, and then play it (which
for long video is an intolerable delay/latency before startup), or you
use the HTTP GET/TCP return connection to deliver the video piecemeal
into a player direct (i think netscape hacks images this way, which is
fine for stills, but...) in which case any stall in the TCP dues to a
transient slow start will stall the replay, whereas a loss tolerant 
compressed video stream should be able to use other congestion
avodance mechanisms (c.f. van's tutorial at sigcomm, or
wakeman/turletti/bolot paper same place...)

anyhow, the model of TCP as the right transport is shown by WWW  in
general to be wrong - TCP was very very good when the average
connection lifetime was long, and the application was not loss
tolerant...

www has short application lifetime (a single get usually retrieves
very littkle data) except for the video/audio data (mime content type
whathaveyou) which is loss tolerant

sorry....the elastic service can be a bit more elastic than tcp....
(but not much:-)

cheers
jon

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 09 Nov 1994 11:41:27 -0500

> wakeman/turletti/bolot paper same place...)

Jon,

This is the way Web readers do this.  If after retrieving the first
second or two (or 1/2 second or whatever is tolerable), it is evident
that the transfer rate is much greater than adequate, a client could
spawn the external reader and pipe the stream to it.  That would
require that the client knows not only what reader to bring up fro a
given file type, but also the range of transfer rates that the file
type could encompass.  This could be configured just as the name and
the command line arguments of the external reader are configured.
This is no limitation in the protocols to prevent this.

I agree with you that the client software could do this better.

> connection lifetime was long, and the application was not loss

Long should be expressed in multiples of RTT.  TCP works well after
the initial slow start, which is how many RTT from where you are
sitting?

> whathaveyou) which is loss tolerant

Postscript and gif are not loss tolerant and use the same MIME encaps.

Most (probably >>99%) of the people that fetch video/audio data cannot
do it at anywhere near real time speeds.  By using TCP, you could
accommodate those users, and also accommodate those with higher
bandwidth but with a big playback delay (1-2 seconds or more if you
allow a large spool ahead, which doesn't matter at all for a recorded
application).  Using RTP would break the application for most users.

> sorry....the elastic service can be a bit more elastic than tcp....

We are wandering way off the topic due to an off the cuff comment I
made about WWW.

Curtis