Subject: RE: Diffserv/Intserv relationship

From: Yoram Bernet <[email-masked]>
Date: Mon, 22 Dec 1997 18:34:01 -0800

> -----Original Message-----
> From:	David Black [SMTP:[email-masked]]
> Sent:	Monday, December 22, 1997 3:43 PM
> To:	[email-masked]
> Subject:	Diffserv/Intserv relationship
> 
> I mostly agree with Paul and Juha.  In terms of the things we need to do
> to
> make progress, specifying the protocol that a host uses to talk to the
> edge or
> ingress router that does packet marking and the protocols used among
> network providers to coordinate marking and treatment of marked packets
> are way down the list.  
	[Yoram Bernet]  This is taking a very network-centric view. Today,
we cannot use Microsoft's leased line to Euope, to carry IP voice calls. We
can't do this, because our voice packets don't stand a chance on our
congested line. If we could prioritize voice above data, we could probably
solve this problem. 

> I think many of the initial deployments of diffserv can and will be
> sufficiently coarse grained (e.g., all traffic to this site, all
> connections
> initiated by this host, VPN link) that these protocols do not have to be
> specified initially. 
	[Yoram Bernet]  Again - a network centric view. You can use
mechanisms like this to give company X better service than comany Y, or
perhaps even to give subnet A in company X, better service than subnet B in
company X, but - from an application and host  OS provider, please be
informed that I need to be able to express "Give my mission critical SAP
traffic higher priority across the backbone than web surfing, unless it's
the CEO that's surfing the web, and by the way - voice is not as important
as SAP but it is more important than web surfing."

> In particular, Yoram's assertion that we need a standard set of service
> types
> like intserv's is no longer obvious to me.  The beginnings of a
> counterexample
> is that videoconferencing equipment is variable bandwidth, and our long
> distance carrier allows us to select the bandwidth for an individual call
> via a
> dialling prefix in 128k chunks.  
	[Yoram Bernet]  This is a poor counterexample. Intserv flowspecs
include *both* servicetype *and* token bucket parameters. Your
videoconferencing app probably needs a different service type from your
web-surfing app, regardless of how efficient it is at using bandwidth. It's
bandwidth is expressed via the token bucket parameters that you supply with
the service type.

> -- What's left --
> 
> Even with all of the above, I agree with Roch and Yoram that there's no
> point
> in reinventing wheels because we didn't like the car they were on last
> time.
> In particular, IF we find ourselves needing concepts of filterspecs and
> flowspecs in diffserv, THEN we should look to the work done on these
> topics
> in intserv as an obvious starting point.
	[Yoram Bernet]  I don't have an issue with the separation of
diff-serv work and the signaling protocol work. In fact, I think that they
are very separable. The point I am making is that the signaling protocol
pretty much exists and that it can pull together the requirements of
end-stations, those networks that *do* support RSVP and those networks that
support diferentiated services. I think that we can make substantial
progress on how RSVP maps to differentiated services, *without* delaying
diff-services. The interface between the two can be abstracted to some
mapping from intserv service type (be it an existing service type or a new
set) to diff-serv service types. Given that there is such a mapping, work in
diff-serv and work in RSVP could proceed separately. When they're both done,
there will be a compelling end to end QoS story. Note that this does not
require any of the devices within the diff-serv network to understand RSVP
or any other signaling proitocol, much less to deal with the scalability
problems of RSVP.

> --David
	[Yoram Bernet]  Yoram

> ==========================================================================
> ==
> David L. Black            THE OPEN GROUP     Voice: +1 (617) 621-7347
> The Open Group                                 Fax: +1 (617) 621-8696
> Eleven Cambridge Center      RESEARCH       E-Mail: [email-masked]
> Cambridge, MA  02142        INSTITUTE
> http://www.opengroup.org/~dlb/
> ==========================================================================
> ==

---

From: David Black <[email-masked]>
Date: Tue, 23 Dec 1997 12:44:41 -0500

Yoram provides several scenarios to attempt to motivate the immediate need for
use of RSVP to communicate diffserv requirements.

(1) Priority for IP voice on a leased line.
(2) Priority for SAP traffic over voice over web surfing.
(3) CEO's web surfing is an exception and should be high priority.

I disagree.  (1) and (2) can be handled via static configuration based on
destination port number.  (3) can be handled staticly via the IP address of the
CEO's host or proxy, but requires support for receiver based marking -- let me
know if I should repost a plausible solution for that problem to the list.

Popping up a level, let me remind everyone that I'm not arguing that static
configuration will solve all possible configuration problems.  I agree with
Yoram's point that manageability will be a problem if we get a trend towards
smal granularity dynamic requests for differentiated services.  RSVP is a
plausible solution to that problem, and I have no objection to working on it as
long as we all agree that defining what the diffserv bits mean is a precursor
to figuring out how to use RSVP to convince a box to set them.

The point of the videoconference example was not that intserv can't be used to
express videoconference requirements (of course it can), but rather that there
are more efficient ways of solving a less general problem that should also be
considered (e.g., a MIME value that says this is a videoconference with 128k
nominal bandwidth).  This efficiency may require prior arrangements (e.g., the
provider and user have a separate contract specifying how such streams will be
treated).  If people want to use RSVP to solve this problem, that's fine, but
we shouldn't rule out alternatives.

What I think I see emerging from the recent mails is movement towards an
ISSLL-like approach to dealing with the intserv over diffserv issues, namely
	(1) First, get the diffserv bit semantics defined.
	(2) Then, look at how best to realize intserv using diffserv.
The implication here is that there will likely be mismatches, and hence the
resulting service mapping document will have warts, etc.  I support this
approach in preference to demanding that diffserv be designed in such a way
that the intserv service mapping is perfectly clear and clean (a non starter,
IMHO).

--David

============================================================================
David L. Black            THE OPEN GROUP     Voice: +1 (617) 621-7347
The Open Group                                 Fax: +1 (617) 621-8696
Eleven Cambridge Center      RESEARCH       E-Mail: [email-masked]
Cambridge, MA  02142        INSTITUTE         http://www.opengroup.org/~dlb/
============================================================================

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Dec 1997 15:26:47 -0500

> destination port number.

Actually, that isn't necessarily true.  H.323 is arguably
the most widely used conferencing control protocol right
now, and it's gaining wider use.  The media stream port
numbers are *not* known in advance, but are exchanged as
part of the H.245 negotiation.

Melinda Shore
Lead Network Systems Programmer
Advanced Technology and Planning
Cornell Information Technologies
[email-masked]
+1 607 255 6460

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 23 Dec 1997 23:54:02 +0000

In message <[email-masked]>, Melinda Shore typ
ed:

 //> I disagree.  (1) and (2) can be handled via static configuration based on
 //> destination port number.
 //
 //Actually, that isn't necessarily true.  H.323 is arguably
 //the most widely used conferencing control protocol right
 //now, and it's gaining wider use.  

no - voice bridges are the widest used conferencing system followed by
ad hoc circuit setup....H323 is a toy, just like the mbone...

 //numbers are *not* known in advance, but are exchanged as
 //part of the H.245 negotiation.
 //
 //Melinda Shore
 //Lead Network Systems Programmer
 //Advanced Technology and Planning
 //Cornell Information Technologies
 //[email-masked]
 //+1 607 255 6460

 cheers

   jon

---

From: Melinda Shore <[email-masked]>
Date: Wed, 24 Dec 1997 11:26:29 -0500

> ad hoc circuit setup....H323 is a toy, just like the mbone...

The broader point here is that relying on preknowledge of
things like address and port number in order to staticly
configure bandwidth requirements into switches/routers isn't
going to work in common cases.  Some kind of signalling is
going to be required.  

Melinda Shore

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 24 Dec 1997 11:35:43 -0500

>going to work in common cases.  Some kind of signalling is

Not necessarily. It may mean, however, that some sort of
state may need to be maintained -- proxy firewalls do this
sort of thing today.

- paul

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 25 Dec 1997 22:35:25 +0200

melinda,

i'm not sure about this, since why can't a site manager figure out what
is the usual max number of simultaneous VoIP calls and subscribe a low
delay profile based on that?  if there in rare cases is more
simultaneous calls, then the excess calls are carried as low delay best
effort and the local router can do the marking so that calls from
important people will always be in-profile.

-- juha

---

From: Scott W Brim <[email-masked]>
Date: Tue, 30 Dec 1997 14:31:58 -0500

Melinda, when you say "signalling", does that include simply having
semantics for header bits, or do you mean a separate control stream?