Subject: RE: Differentiated Services working group

From: Yoram Bernet <[email-masked]>
Date: Sun, 1 Mar 1998 12:03:06 -0800

> The group will not work on mechanisms for the identification
> of individual traffic flows within the network, or on
> signalling mechanisms to support the marking of packets.
> 
	[Yoram Bernet]  In this case, what is the appropriate forum for
discussing  the interaction of hosts with the diff-serv network? Ultimately,
it is the users of hosts who are the customers of the diff-serv network... 

	Yoram

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 2 Mar 1998 08:15:48 +0200

> it is the users of hosts who are the customers of the diff-serv network... 

i have always assumed that the host can tell to the network, what type
of service, such as delay insensitive or delay sensitive, the host
expects the packet to receive using the bits in the tos byte.  the host
can also express a wish if the packet should be treated as in or out,
but that wish may not be satisfied by the network whereas the network is
not allowed to change the type of service of the packet, since that
would not make any sense.

if someone wants to have somekind of protocol between the host and the
network in addition to the tos byte settings, then i'm not sure if that
would fit into the charter of this working group.

-- juha

---

From: Burkhard Stiller <[email-masked]>
Date: Mon, 2 Mar 1998 10:08:55 +0100

>would fit into the charter of this working group.

The use of a specifically typed service requires that at least the
application residing in the host has to identify the type of service. The
tos field is appropriate for that - at least at a higher level of
abstraction. However, it requires an initial decision to look at either of
the two following possibilities:

a) running a "protocol" between host and network (i.e. first router) or
b) running an end-to-end protocol

to obtain a clear view of what the network or the hosts is expected to do.
Obviously, case a) looks very similar to the ATM approach of handling
signalling issues, while case b) may use some kind of (resource)
reservation protocol. Although, the advantages and drawbacks of these cases
a) and b) are not clear in general, is there any third choice to be
considered ?

Regards,
Burkhard

***********************************************************************
   Dr. Burkhard Stiller
   Institut fuer Technische Informatik und Kommunikationsnetze (TIK)
   FG Kommunikationssysteme
   ETH Zuerich                             Tel.: +41 / +1 / 632 7016
   Gloriastr. 35                           FAX:  +41 / +1 / 632 1035
   CH-8092 Zuerich                    E-Mail: [email-masked]
   Schweiz                   WWW: http://www.tik.ee.ethz.ch/~stiller
***********************************************************************

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 2 Mar 1998 11:41:45 +0200

> b) running an end-to-end protocol

i fail to see why you would need a protocol for that purpose.  voip
application, for example,  can set the delay sensitive bit on its own or
leave it to the operating system to set the bit.

 > a) and b) are not clear in general, is there any third choice to be

yes, the simple scheme that i outlined above,

-- juha

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 02 Mar 1998 12:34:53 +0000

>> > it is the users of hosts who are the customers of the diff-serv network... 

I thought the POINT of diff serve was that we now recignied that the
best signal was $$$ and that subdcription to Service Level Agreements
(above best effort) are the mechanism to "signal" dollars, and permit
the use of the bits.....which are acted on by ingress/access routers to
police people to their SLAs ... in fact, an interim deployment of
diffserve wouldn't even need hosts settign the bits, but the SLA in te
acces router would set bits for you.....(until IPSEC is deployed,
anything else will be tricky except for dialup users where the link
level may provide source authentication)

thus the characteristics of  signaling rates are MUCH slower for differve 
than for intserve
and an interim deployment doesnt need anyything beyond manual
configuration at subscription time

though rsvp could be used, so could snmp or telnet and a cli...

 >>would fit into the charter of this working group.

 cheers

   jon

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Mar 1998 12:51:34 +0000

> would fit into the charter of this working group.

Juha is correct. Diff serv is about what can be implemented very
simply, at low cost, on a very large scale, using a few bits
per packet to specify next hop behaviour. The bits set by the
host are an opening bid to the first boundary router. There is 
no end to end dialogue in such a model. This isn't a poor man's RSVP.

  Brian Carpenter

---

From: Melinda Shore <[email-masked]>
Date: Mon, 02 Mar 1998 10:10:40 -0500

> leave it to the operating system to set the bit.

That certainly would be adequate, assuming that nobody sets
the delay-sensitive bit unless the application really is
delay-sensitive.  However, as someone who's building systems
which require some sort of resource reservation (i.e. for
toll-quality voice in a campus environment, you need to
either get a circuit or not get a circuit - kinda sorta
mostly getting some of the bandwidth you need isn't
adequate), there's no question in my mind that end-to-end
signalling issues need to be addressed someplace (especially
if the network is going to be mucking with the TOS byte).  I
am, however, not at all sure that diff-serv is the place to
do it.  Diff-serv in the core and int-serv at the edge?

Melinda Shore
Lead Network Systems Programmer
Cornell Information Technologies
[email-masked]

---

From: Roch Guerin <[email-masked]>
Date: Mon, 02 Mar 98 10:34:46 -0500

[snip]
>there's no question in my mind that end-to-end

Melinda, I think the last point you make, namely, "Diff-serv in 
the core and int-serv at the edge" is totally reasonable.  The issue
then is to ensure the appropriate level of interoperability between
the two.
Roch

---

From: "Mike O'Dell" <[email-masked]>
Date: Mon, 02 Mar 1998 10:39:40 -0500

if you want a CBR circuit, run ATM.

	-mo

---

From: Melinda Shore <[email-masked]>
Date: Mon, 02 Mar 1998 10:42:51 -0500

> if you want a CBR circuit, run ATM.

Well, that's what I've been telling folks.

Melinda

---

From: Burkhard Stiller <[email-masked]>
Date: Tue, 3 Mar 1998 07:28:04 +0100

Melinda Shore wrote:
>if the network is going to be mucking with the TOS byte).

	That's exactly what I meant, when I distinguished the two choices
(for signalling):

	Of course, I agree that a "protocol" between the host and the
network may require a well-known one, as one including the tos field. And
additionally, end-to-end signalling requires an end-to-end protocol,
whatever you will call it, it might be RSVP, IPv6 (ICMP), or somewhat
different ....

	These are the mechanisms you require, either type.

	On the other hand, the list's discussion showed that the question
of "policy" is of more interest, at least it looked like. This encounters
the various policies who will specify, identify, and set the tos (or
something equal). It may be only one of the following four choices:

	1. User
	2. Application
	3. Host
	4. First Router (edge device)

	If other routers modify the, e.g., tos it is fine as well, however,
it may not reflect the 100% need of the user/application any more. It may
be changed in any way.

	Finally, we have to distinguish the "incentives" what to do when,
this is for an not exclusive list:

	i)   Pure QoS-incentive to obtain all QoS as fairly requested from
	     users or apps
	ii)  Basic QoS-requests as handled from the host itself, most easily
	     a value for the tos field
	iii) The $-incentive to simply pay for as much as you are willing to
	     spent
	iv)  The network-incentive to adapt incoming traffic as it best suits
	     its current free resources
	v)   etc.

	Obviously, the "protocol", "mechanisms", and "incentives" are
clearly linked, as a certain incentive requires particular mechanisms to be
suported by the protocol. There might be generic set of possibilities to
provide an extensible solution to the question of being open for the long
run and not only see short-termed solutions.

>I am, however, not at all sure that diff-serv is the place to

	That sounds as an interesting idea, but doesn't it fit into the
above list as a special case as well ?

Burkhard