Tony Hain wrote:
>
> 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.
>
AAA should enable the Starbucks domain to know what you are paying for.
Agree with the signaling case: Your laptop could ask for specific QoS
(hopefully in application independent terms) and the first hop could tell
you what DSCP to use to get that. There would probably need to be some
monetary flow from you to Starbucks, if best effort would be all they are
willing to give away to attract customers. That monetary flow could be via
your AAA home domain (that could be e.g. your credit card company), and
could be based on either flat rate or per usage charging.
But I think somehow the scenario for the diffserv flow label has been
intra-domain, between operators. The first hop can be solved by the diffserv
WG alone by devising a suitable PHB-group.
>
> > > 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.
The point is, IMO the system doesn't work with the intra-domain 5-tuple
MF-classifiers as specified today. Maybe no-one has tried out setting
intra-operator SLAs based on protocol fields set by hosts (being outside of
the control of both the operators)?
Jarno
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
