Subject: RE: a), b), c), d), or e)

From: [email-masked]
Date: Thu, 30 Aug 2001 02:26:07 +0300

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-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 29 Aug 2001 16:53:16 -0700

> AAA should enable the Starbucks domain to know what you are 

Without a standard set of DSCP values what good does that do me?

> intra-domain, between operators. 

And this is the problem. The operators are finding that making
the DSCP completely random has resulted in a useless technology.
The flow label is an end-to-end field so there is a hope they
can restore what they need, but at the same time these bits
are being made mutable.

> The first hop can be solved by the diffserv

If they had only done that to begin with. 

> MF-classifiers as specified today.

I was being very careful not to use the 5-tuple
because the src/dst addresses are mutable thanks
to NAT. The only end-to-end consistent bits are
the protocol & port, and the flow label.

> Maybe no-one has tried out setting

It works as long as long as there is a trust or
financial relationship which creates feedback. 

Tony