Subject: RE: Diffserv/Intserv relationship

From: Yoram Bernet <[email-masked]>
Date: Tue, 23 Dec 1997 11:25:42 -0800

David:

Thank you for this level headed assesment of the current state of the
discussion :-)... comments below.

> -----Original Message-----
> From:	David Black [SMTP:[email-masked]]
> Sent:	Tuesday, December 23, 1997 9:45 AM
> To:	[email-masked]
> Subject:	Re: Diffserv/Intserv relationship 
> 
> 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.  
	[Yoram Bernet]  OK
> (1) and (2) can be handled via static configuration based on
> destination port number.
	[Yoram Bernet]  Sometimes, for certain applications. However:
	1. In general - you will not know the ports used by the application
until the session is in progress.
	2. Even if you did, there's a significant drawback to this scenario
over the alternative I proposed. If
	I statically provision a certain capacity with my carrier, in a
certain service class, then I still need to 
	coordinate all my hosts that are running apps that will end up
consuming resources in this service class.
	Otherwise, they may all try to consume resources in the service
class at the same time, which compromises
	the integrity of the service. I can invent a new protocol, on an app
by app basis, to coordinate among them, 
	based on whatever I happen to have provisioned along the path... or
- I can use RSVP (unbeknownst to you, the carrier).
>   (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.
	[Yoram Bernet]  Or - I can put my ACS or BB or whatever it is, at
the egress point
	of my network (where I have negotiated the servie contract) and use
RSVP.

> 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.
	[Yoram Bernet]  As a representative of an application and host OS
vendor, I claim
	that we will get this trend. It'll hit us all at once, when the next
versions of our OSs
	ship, sometime next year.
>   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.
	[Yoram Bernet]  Can we agree on:

	"Defining the diffserv bits and the usage of a protocol which allows
hosts to designate
	diffserv services, are both urgent tasks which can proceed in
parallel?"

	Also - a point which seems to get repeatedly missed, is that, the
OSs we will be releasing,
	will set the bits themselves - so we're not necessarily figuring out
"how to use RSVP to
	convince a box to set them" so much as "how to use RSVP to let the
network tell a host whether it can
	set the bits". I claim that with this approach, you can reduce the
burden on your ingress routers (by not
	requiring them to classify based on 'filterspecs', but rather having
them police based on diffserv class specified)
	and that you can continue to protect the ingress points of the
network while worrying only about aggregate classes
	of service, and pushing the burden for controlling the fine grain
flows, to the user.

> 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).
	[Yoram Bernet]  If someone made such demands - I missed them. 

> --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: David Black <[email-masked]>
Date: Wed, 24 Dec 1997 14:19:05 -0500

Yoram Bernet asks:

> Can we agree on: 
> 	hosts to designate diffserv services, are both urgent tasks which can
> 	proceed in parallel?"

My opinion matches Paul's $.02:

> Therefore, we need to ensure that we maintain equity on both types
> of implementations. I would suggest that the latter case (not listening
> to RSVP) situation already exists pervasively, and will continue on
> into the near future (only the ration of RSVP-listeners to non-RSVP-
> listeners is in question, and I don't think anyone has a crystal ball
> they can peer into to foresee the future). In that vein, the more
> immediate need is to cater to the non-RSVP-listeners first, then
> define a RSVP/diffserv interworking framework later.

If we agree not to quibble over the precise meaning of "urgent",

============================================================================
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: Wed, 24 Dec 1997 14:23:15 -0500

> If we agree not to quibble over the precise meaning of "urgent",

then I think we agree (both tasks can proceed in parallel).

--David