Subject: clarification on link sharing

From: Curtis Villamizar <[email-masked]>
Date: Wed, 13 Apr 94 16:38:22 -0500

Please humor me, I might be a little dense.

At Seattle I asked about the mechanism for controlling link sharing
allocations.  I got a quick answer indicating that SNMP or something
can be used to set up allocations.  This seems to be the task of the
magic box in the overview document known as the management agent.  I
was hoping we'd get more specific in some of the int-serv documents.

For link sharing I have gleened the following.  If link sharing is
driven by very static information (link multiyear contracts for
network service), the traffic control database could be driven by a
local configuration file (presuming the router supported the notion of
a file or some loadable persistant configuration information).  We
need an implicit classifier for IPv4.  The classifier provides input
for the packet scheduler.  We intentionally are not going to propose
standardizing on queueing algorithms, but may later provide some
requirements for the packets scheduler.

So my questions are:

    1)	Is it safe to assume that there is not going to be an
interface defined for the "management agent" that provides information
to the "traffic control database" and that using a configuration file
would be a perfectly acceptable way of doing this.

    2)	Is anyone working on a description of what classifiers might
be appropriate for link sharing.  The classic example is NSF want X1
mb/s, DOE wants X2 mb/s, and NASA wants X3 mb/s.  For this it may be
sufficient to look up the source and dest and decide whether to use
src or dst based on some algorithm that will make the same decision
for the reverse flow.  Of course you could peek at the TOS bits and
precedence field and maybe even look for that RSVP IP option and do
something different.  Hopefully you wouldn't have to look at TCP and
UDP port numbers.  For the classic NSF, DOE, NASA example, src/dst
would be sufficient and if you also did RSVP, the presence of a RSVP
flow IP option would use a reservation if one existed (otherwise ride
with the elastic packets).  This would presume one or more agencies
set aside some percent of bandwidth for real time traffic (which would
get used by the elastic traffic anyway if there wasn't enough real
time traffic to fill it).

    3)	Is the intention to pass everything through the classifier,
match those that correcpond to reservations and let the others fall
into the course classifiers for flows and the rest get some default
packet scheduler handling?

Maybe I just misunderstood the intention of John W.'s presentation on
classifiers.  Is the intention to make this a draft and push this as
The way to do classifiers.  Certainly if it is the standard for RSVP,
every packet must get classified in this manner since there is no
quick way to identify a flow.

I was hoping that a flow could quickly be identified by something like
an IP option and that internal routers which for reasons of traffic
levels could not do full classification could simply queue all
reservation traffic separately from elastic traffic and do fairly
course link sharing.  If a router can't support John's classifier for
some reason and has not quick way to simply separate real time from
elastic, it must then lump real time and elastic together.

Keep in mind that routers today are have trouble with 20,000 routes.
Why would 70,000 reservations be easier to handle?  The problem is
that to handle the forwarding load, interface cards must do the
forwarding directly to each other rather than through a central
processor and these typically don't have large local memories (that
aren't already dedicated to packet buffering by hardware design).
This is changing, but most routers today could easily handle a small
number of queues for link sharing and a small routing table field
which the src and dst could be checked against.  Do we want to make
this stuff grandeous or a reality?

BTW - NSF-93-52 has some wording regarding other services not
degrading the performance of the vBNS service.  The NSF OIG "Review of
NSFNET" dated 23 March 1993 suggests that NSF should seek similar
guarentees from the NAPs.  I've seen similar requests for service
guarentees of some sort in other RFPs.  If you believe bandwidth
reservation is a waste and most of this traffic will remain elastic
traffic, these look like requirements for link sharing.  Just thought
I'd share this.  :-)

Curtis

Disclaimer - I speak for me.