Re: Last Call for draft-ietf-rolc-apr-00.txt

[Curtis Villamizar <[e-mail]>]

Tim,

In message <[e-mail]>du>, Tim Salo writes:
> 
> For what it is worth, in "real world" ATM, there may be some relationship
> between the desire for direct VCs and whether the source and destination
> are topologically "near" each other.  In particular, SVCs are [perhaps
> almost] possible in local ATM networks, but are not available in
> wide-area ATM services provided by carriers.  When carriers provide
> SVCs, users may want to have different criteria for using local- and
> wide-area SVCs, particularly if one costs real money (darn intrusion of
> the "real" world) and the other doesn't.

You've brought up an excellent point here.  If this was not initially
anticipated would you rather change something at the host level to
correct this or change all applications that use network services?

> It is not clear to me how "SVCs exist," "SVCs don't exist," "SVCs are
> free," and "SVCs cost money" map into "address aggregates."  On the
> other hand, it is fairly clear to me that users, (if we asked them and
> if they had a clue what we were talking about), would want to control
> the portions of their topology over which SVCs were used.

It might be easier for an application writer to write into the
application code which provides some hint (parameters) as to the
characteristics of the traffic that will be generated and the
requirements, where cost might be a configurable requirement, that the
user can override (the "do it even if it cost me something" option in
the application).  It may be easier at the host or router level to map
that parameterization into a method for providing the network service.

This way an application written somewhere else (LBL, etc) can be run
on your network without knowledge of the direct connectivity and costs
associated with prefixes reachable from your network.  We don't have
to build QoS routing decisions (the local/remote decision can be
regarded as a QoS routing decision) into every application.

How many application programmers barely understand what SO_SNDBUF and
SO_RCVBUF are for?  If we put the QoS decision in the application, we
are asking them now not only to characterize their application traffic
and its needs, but make the decision as to how the traffic should
flow.  A few will do a great job at this.  The majority will do
incredibly stupid things.  This is like putting congestion avoidance
in the hands of the application programmer with a UDP socket.  What
has the experience been like with that?

Curtis