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

From: [email-masked]
Date: Thu, 30 Aug 2001 00:33:09 +0300

Tony Hain wrote:
> How does it work if I am encrypting my traffic (independent of
> protocol version)? On top of that the diffserv model provides 
> no control to the originator of the packets, and that is the
> source of the money which makes a business model work.

The originator CAN set the DSCP bits, as specified by the agreement with the
access operator. This control SHOULD only propagate as far as his money
propagates. If the access operator is not willing to share some of the
"value-added" income with the next operator, the RIGHT thing to do by the
next operator is to remark the PHB treatment indicator originally set by the
originator, and possibly remarked by the access operator.

> Yes there
> is a technical definition for diffserv QoS, but there is no 
> sustainable business and operational model which includes the
> source of the packets & money. A strict diffserv network is a 
> providers fantasy land. 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 between the originator
and the access operator and maybe some pretty standard conventions for
fee-schedules, or alternatively monthly (or daily) usage limits for each
DSCP indicated behavior aggregate.

> 
> > You assume that the flow label MUST be immutable, because you 
> > base your 
> > thinking on an absolute model. 
> 
> No, I base my thinking on the fact that for diffserv to work 
> there has to be a visisble set of immutable bits with well-known 
> end-to-end semantics. Otherwise each provider can't figure out
> which PHB is appropriate.

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.

	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:02:12 -0700

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 

> 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.

> maybe you meant more like "standardized semantics". See my comment on

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