Subject: Re: Motivation for Intserv/Diffserv interoperation

From: Fred Baker <[email-masked]>
Date: Mon, 16 Apr 2001 14:25:29 -0700

At 06:55 PM 4/15/2001 -0500, Kuthonuzo Luruo wrote:
>I've come to the conclusion that the main motivation for using Intserv 
>with Diffserv is the signalling control and end-to-end semantics that 
>RSVP/Intserv brings to Diffserv.

Parekh and Gallagher, in Infocomm '93, demonstrated what is necessary to 
have a predictable behavior in a network. It has two elements: you have to 
know how much traffic there is, and you have to have the queuing points 
(host and router) behave predictably. If those two things are true, you can 
mathematically calculate the end to end delay. They give equations.

Diff-serv, which is a data plane tool, enables us to scalably make the 
router do predictable things, given that the amount of traffic and the 
bandwidth available are known.

TCP will put a stable amount of traffic into the network; unfortunately, it 
approximates the cliff rather than the knee. With red we can bring that 
down to the knee, and with ECN we can do so without dropping traffic. So if 
the routers behave predictably, we can create a quite predictable network 
for TCP-based applications.

But voice/video don't respond to delay, ECN marks, or loss; each such 
application sends at a constant rate while it is sending, and using 
diff-serv alone the number of senders (and therefore total traffic load) is 
unbounded. Hence, using diff-serv alone, one cannot build a predictable 
voice network. The alternatives are (1) to provide effectively infinite 
bandwidth for voice, so that it is never significantly delayed regardless 
of user count, or (2) to know how many calls there are in the network with 
what characteristics, and refuse excess calls. In networks that consider 
communications capability to be a cost of doing business as opposed to the 
business itself, (2) becomes necessary, and (2) is the province of 
int-serv, a control-plane tool.

Hence, for voice/video, we must use int-serv and diff-serv together.

---

From: Kuthonuzo Luruo <[email-masked]>
Date: Mon, 16 Apr 2001 18:31:24 -0500 (CDT)

pls see inline.

> Hence, for voice/video, we must use int-serv and diff-serv together.

so, can i conclude that the primary motivation for the Intserv/Diffserv
interoperation is the signaling that control plane Intserv brings to data
plane Diffserv for such voice/video flows that do not use TCP? with other
benefits being... able to perform better resource mgmt in Diffserv clouds,
fine-grained policy control etc (the 4 benefits in RFC 2998). 

ergo, from the operational "real world" viewpoint, my ISP would introduce
Intserv/Diffserv for the above reasons and NOT for the tighter qos
guarantees attributes of Intserv. this perception also seems to be
supported by a look at the Intserv/Diffserv network model: Intserv n/w
elements are at the stub n/ws where congestion is less likely, and hence
perflow intserv is unlikely to bring significantly better qos guarantees
(as opposed to extending Diffserv all the way to the stubs).

on the other hand, from a purely academic "scientific" perspective,
perhaps investigating the interworking problem from my initial perception
("hard qos guarantees Intserv benefits less strict qos guarantees
Diffserv") is worthwhile, thesis-wise :-).

thanks.

-thonuzo

---

From: Fred Baker <[email-masked]>
Date: Mon, 16 Apr 2001 17:51:25 -0700

At 06:31 PM 4/16/2001 -0500, Kuthonuzo Luruo wrote:
>guarantees attributes of Intserv.

given that controlled load presumes a common queue for all voice traffic, 
scheduled using priority or similar scheduler, I'm not sure I see a 
distinction. Controlled Load can be read pretty directly as "per-microflow 
signalling for EF-managed microflows". The difference here, I believe, is 
that we would like to see aggregate signaling as well as aggregate data 
management.

When you talk about fine-grained data management, you are talking about the 
Guaranteed Service, which presumes the characteristics of per-flow WFQ, 
although somehow it manages to not actually require a WFQ/WRR algorithm. 
This is something that is eminently possible using calendar-queue-scheduled 
WFQ algorithms, but has potentially interesting scaling properties.

>Diffserv") is worthwhile, thesis-wise :-).

very possibly. You could start out by arguing that the guarantees differ, 
and say why you think that. hint: with a control plane, you get told what 
you are guaranteeing. But I wouldn't compare a control plane solution to a 
data plane solution - the control plane isn't going anywhere without a data 
plane, and controlled load has the SAME data plane; the only thing that 
differs is how the classifier works. You want to explore what not having a 
control plane does to arbitrary amounts of voice and video.