Jarno Rajahalme wrote:
> The originator CAN set the DSCP bits, as specified by the
> agreement with the access operator.
Since the setting is not well known you will find that
end systems and applications are unable to figure out how
to mark them. Consider I use my laptop at home, in the
office, and at Starbucks. How does the OS or the app
know which SLA is applicable and which way to mark the
bits? If I had RSVP with DCLASS the first hop could
tell the OS, but we are talking about a strict diffserv
environment.
> > There must be a mechanism for the
> > endpoint to inject intent or there will be no reason to pay.
> All that is missing is a standardized usage of DSCP ...
Thank you. I have been trying to make this point, but
don't seem to be finding the right words.
> It may be hard to map from end-to-end semantics to
> per-hop-behavior. So
> maybe you meant more like "standardized semantics". See my comment on
> mutability above.
I got the words out of order that time. What I had been
saying is 'a visisble set of end-to-end immutable bits
with well-known semantics'. The point is that current
diffserv networks work because all the providers can
see the end-to-end immutable protocol/port bits and
make local decisions based on their interpretations
of the well-known semantics of those values. There is
no reason that using a different set of bits would
suddenly mean those have to be mutable. To the extent
the system works today with the end-to-end immutable
protocol/port bits, it will work with an immutable
flow label.
Tony
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
