Subject: Diffserv semantics and mechanisms

From: [email-masked] (ETX-DN-SL Anders Eriksson)
Date: Wed, 4 Feb 1998 15:08:34 +0100

To what extent should mechanisms be standardized in the diffserv 
framework? For example, is there a need to standardize a specific 
queue management mechanism (such as RIO) to support different degrees 
of drop preference? This was one of the issues discussed at the 
Washington meeting, see the intserv WG minutes. 
Here are some additional ideas:

The standardization of a specific diffserv drop mechanism (such as RIO) 
is justified if there is an interoperation issue. Consider a diffserv 
network where the drop mechanism is not standardized, and a number of 
different proprietary mechanisms are operating in the routers along the 
path of a TCP connection. Due to the interaction betweeen the TCP flow 
control and the various proprietary drop mechanisms, it may be a tricky 
problem to analyze and predict end-to-end performance over such a network. 
Moreover, the development of future improved flow control mechanisms in 
the hosts would become more difficult with a network full of various 
proprietary diffserv drop mechanisms, each responding in a different way 
to varying degrees of congestion.

The situation is rather different for traffic which is tagged as 
"delay sensitive" in the ToS field. Various scheduling mechanisms 
such as priority scheduling or weighted fair queueing can be mixed 
along the path of a delay sensitive flow without interoperation problems. 
There should therefore be no need to standardize the scheduling mechanism 
for delay sensitive traffic. 

In conclusion: 

The standardization of a specific diffserv drop mechanism (RIO or 
some other mechanism) in the diffserv framework would facilitate 
end-to-end performance analysis and prediction. 

However, standardization of a specific mechanism for the 
handling of delay sensitive traffic should not be needed.
Standardization of ToS code point semantics such as 
"delay sensitive" would probably be sufficient. 

Comments on this?

/Anders Eriksson

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Anders Eriksson                E-mail:  [email-masked]
Ericsson Telecom               Tel.   +46- 8-719 2253
Dialoggatan 1                  Fax.   +46- 8-719 6677
Kungens Kurva            
S-126 25 Stockholm                                            
Sweden

---

From: Geoff Huston <[email-masked]>
Date: Thu, 05 Feb 1998 12:07:28 +1100

Anders,

I feel this is a basic enough point to hightlight from your message.

You assert that 

  Due to the interaction betweeen the TCP flow 
  control and the various proprietary drop mechanisms, it may be a tricky 
  problem to analyze and predict end-to-end performance over such a network

predicting performance and diff-serve appear to me to be
different concepts....

My point it that this is _differential_ service, not absolute service.
i.e. this does not match the guaranteed service as described
in the T-Spec of RSVP. My take on the direction is that the
desired outcome is that the user and the network provider
between them have a mechanism to manage different traffic
components with different levels of resource allocation, and
hence yield potentially different service level outcomes.

Best effort is not a predictable service. Differentiation within
best effort still does not yeld predictable service.

Hence your conclusion:

where you cite predictability of performance is one which I cannot
reconcile with a differentiated service environment.

regards,

  Geoff

-- 
Mailto: [email-masked] 
http://www.telstra.net/gih

See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

---

From: Woo-June Kim <[email-masked]>
Date: Thu, 5 Feb 1998 19:41:16 +0900 (KST)

Geoff,

> best effort still does not yeld predictable service.

But won't the users of differential services demand to have 
at least some sort of "soft" predictability ?
After all, users of diff serv will be paying extra to get
some sort of differentiated service, but if this does not 
lead to some sort of predictability for that user, what is
he/she paying for?

I believe Anders is correct in pointing out that if 
the routers were to use different dropping mechanims
there is the possibility (I am NOT saying that it will 
happen,.. just that it might. This is a subject that
needs research.) that connections may suffer.
For example, TCP connection's do not react well to multiple 
losses in a single window, but if you have one router using
RIO and another using a different method(or even if both use RIO 
but with different parameters) such as a threshold method,  
you could wind up with multiple losses...( I know this is not
clearly thought out. But i'm just pointing out the possibility).

-- 

-----------------------------------------------------
  Woo-June Kim
  School of Electrical Engineering
  Seoul National University, 
  Kwanak P.O. Box 34, Seoul, 151-742, KOREA
  (Tel)+82-2-880-8429 
  (Fax)+82-2-880-8209 
  (Email) [email-masked]
-----------------------------------------------------

---

From: "Alessio Casati" <[email-masked]>
Date: Thu, 5 Feb 1998 11:46:19 +0100

I quote Jon's sentence here:

	scaleable aggregation policing, a.k.a drop, relies on some sort of game
	theoretic superiority of the tactic and strategy of the net over the
	end system behaviour (a.k.a trust)

network operation tactic and strategy is mostly ISPs' matter, so it's hard
to identify something in the WG scope.
I agree with Anders that if any need of standardization would be, then
it would most likely be related to drop actions. Geoff's thinks there
wouldn't be such a need since no end-to-end strict guarantee exists in
diffserv model. However, the way assured and premium services are defined,
although they are admittedly not providing strict guarantees, implies standardization
of some drop and marking actions.
The WG may decide not to define any particular service, and to rely on ISP and vendor
to build  stategies and equipment supporting diffservices. The WG outcome would be
thereof turned into some informational RFC providing examples of diffservices smart
peolple thought about (much in the same way as the ADAPTS BOF is going to
lead to the set up of a WG with informational purpose). At most, the WG would
issue a standard track RFC devoting some bits of the IP header to the thransport of
diffserv relevant information.
Is it the trak the WG is willing to walk along?

---

From: Geoff Huston <[email-masked]>
Date: Thu, 05 Feb 1998 23:09:11 +1100

>at least some sort of "soft" predictability ?

Well there's the rub - when you pay the extra toll to use the
express lane there's still no trip time guarantees, but there
is only the implication that your trip will be shorter than
the normal traffic lanes.  Thats all you get for your money.

Whether network users willl buy that line, and how much they
would reckon its worth is perhaps in the hands of the
marketeers rather than with you or me. 

My point is that _by its very nature_ differentiated
service is not an 'absolute' mechanism - its outcomes are
relative to the service level its being differentiated from.

Differentiated service does not offer absolute predictions
on delay, jitter or loss.  Differentiated service offers
the vague promise that when congestion damages the
network your differentiated service will incur less damage
than my base level best effort service. 

(Now if you can convert that relativity into a prediction 
of achievable service, then I must defer to you :-) )

 Regards,

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Thu, 05 Feb 1998 23:37:10 +1100

>of some drop and marking actions.

Perhaps you could clarify this, as I don't see how the assurred and
premium services are anything special in terms of providing
some expectation of service level. Standardization of drop actions
is relative to local congestion, and yields unpredictable service
outcomes. I'm sorry, but I don't understand what you mean by 
standard marking actions. Taken together I don't understand
the benefit of standardizing 'drop' and 'mark'  - some clarification
would no doubt help me understand the point being made.

on another point...

Jon's point is subtle and correct - differentiated services are very
akin to game strategy, although my view is that the game is a three
way game where the user is attempting to devise a superior strategy
which maximises performance and minimises price, in relation to
the strategies of the network and other users. (if we all chose
premium service for example the only winner is the network
operator, and so on...)

regards,

  Geoff

---

From: "Alessio Casati" <[email-masked]>
Date: Thu, 5 Feb 1998 15:17:14 +0100

> would no doubt help me understand the point being made.

I'll try to be more clear (if I won't be, please let me know).

 "Perhaps you could clarify this, as I don't see how the assurred and
 premium services are anything special in terms of providing
 some expectation of service level."

The assured service is defined in such a way that if the user is compliant
to a certain profile, then she/he expects to have her/his packets delivered
with a very good approximation of the service (in terms of rate, loss or whatever)
she/he has contracted with the ISP. Non compliant packets are marked and treated
without any commitment by the network. The dropper might be of any kind. Smart people
proposed to use RIO.
Premium service doesn't tolerate any non conformance, so, the user will experience
virtually no queueing delay as long as she/he is within the contracted rate. Policing
(that is a drop action) is a must at the ingress of the network.
Is it clearer now?

> Standardization of drop actions is relative to local congestion, and yields 
> unpredictable service outcomes. 

Service is unpredictable if something wrong happens, that is bad network engineering,
bad admission... Drop actions, in a well engineered network, would occur only to
out of profile packets and very seldom to conformant packets. That is congestion
would be a very unlikely event for better than BE, conformant, packets.

> I'm sorry, but I don't understand what you mean by 
> standard marking actions. 

I mean exactly what happens to out profile packets: in assured they are marked. That
would be a standard action the profile meter would take whenever an out of profile packet is
identified.

> Taken together I don't understand

If you do not say that the standard action for out of profile packets in assured
is marking them and in premium is dropping them, then they both would not work.
Do you agree with me?

>(if we all chose premium service for example the only winner is the network
> operator, and so on...)

May I ask you to elaborate on this concept, in a multi ISP market where each of them
try to offer better and cheaper services than others'.

I hope I've been clear enough and I apologize because I wasn't in the previous message.

Regards

alessio