Subject: Diff-Serv and Controlled-Load

From: [email-masked] (ETX-DN-SL Anders Eriksson)
Date: Mon, 17 Nov 1997 14:55:45 +0100

Consider the following networking example: A company needs 
to interconnect a number of its LANs over a wide area IP 
network. The LANs support the Controlled-Load Service, 
while the wide area IP network supports Differential Services. 

The example illustrates the problem of interoperation 
between networks that support the Controlled-Load Service, and 
networks that support Differential Services. 

A straightforward solution would be to introduce a support for 
the Controlled-Load service in the Differential Services framework. 
However, there have been several mails on the list suggesting that 
this should not be done. The assumption seems to be that RSVP 
signalling would be needed, which is in conflict with the goal 
of a very simple differential service. 

However, a Controlled-Load service can be implemented for 
predefined flows on a semipermanent basis, without any signalling.
One way of supporting, or at least approximating, such a semi-
permanent Controlled-Load service would be to use a differential 
services type of mechanism. A service profile at the edge of the 
network plus a CL-specific code point in the TOS octet could then
be used. A static resource allocation for the aggregate of the 
predefined flows would also be required. Per flow states would then 
be needed at the network edge, but not in the core of the network.

A Controlled-Load service implemented in this way could coexist 
with other less demanding types of differential services.

Comments on this?
Is there any interest in introducing a support for the 
Controlled-Load Service in the Differential Services framework? 

/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: Jon Crowcroft <[email-masked]>
Date: Mon, 17 Nov 1997 14:28:08 +0000

In missive <[email-masked]>, ETX-DN-SL Anders E

 >predefined flows on a semipermanent basis, without any signalling.

and one way to do this is to set up a profile, and index suvh a
profile with
soruce address, and/or destination address and/or precedence bits set
by ingress routers......

i.e .ratehr than having a "semin-permanent" CL service, one could
select on a per packet basis whether to use it or not with 1 bit....

but otherwise, what you suggest is entirely consistent with Van's
proposal in munich for controlled load service.....and not that
inconsistnet with Dave Clark and John Wroclawksi...

 >Controlled-Load Service in the Differential Services framework? 

yes.......

 cheers

   jon

---

From: Roch Guerin <[email-masked]>
Date: Mon, 17 Nov 97 12:21:42 -0500

>Controlled-Load Service in the Differential Services framework? 

Definitely, at least from my side.  Actually, I'd like to make sure I
can have as smooth an interoperability between Diff-Serv and
RSVP/Int-Serv.  I think this is doable without impacting the
simplicity goal of Diff-Serv, and I'm putting the finishing touches to
a write-up on this.  Hope to post it soon (although it always takes
longer than I think).
Roch

---

From: Wu-chang Feng <[email-masked]>
Date: Mon, 17 Nov 1997 13:57:44 -0500

> Controlled-Load Service in the Differential Services framework?

Using DP marking, if your "profile" is a token bucket, then you're
essentially implementing a controlled-load type of service already with
DiffServ type of overhead.  (It's actually more like protected
best-effort than controlled-load).

In going from a DP-based network to an RSVP/Controlled-load based
network, the router needs to take the priority packets and shape them to
fit into a reserved TSpec in order to preserve the semantics of the DP
bit.  This may cause re-ordering which is potentially bad for TCP,
though.  In going the reverse direction, the router needs to take all
compliant traffic and mark them with the DP-bit.  You'll need some sort
of policy to prevent overmarking (tragedy of the commons) for it to work
right.

Wu

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 17 Nov 1997 21:03:48 +0200

A service profile at the edge of the 
   network plus a CL-specific code point in the TOS octet could then
   be used. 

how about code points for the other int-serv services (current and
future)? 

   Comments on this?

i'm not personally interested, but don't mind others doing the work as
long as it doesn't complicate the diff-serv model by a bit, i.e., as
long as support of controlled load is transparent to diff-serv and is
written up in a separate rfc.

-- juha

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 19 Nov 1997 10:03:25 +0900

> Controlled-Load Service in the Differential Services framework?

This might be another example why we'd better not exhaust all TOS bits
for delay.

--
Regards,

Dae Young
--------------------
http://ccl.chungnam.ac.kr/~dykim/