Subject: RE: Diffserv/Intserv relationship

From: Paul Ferguson <[email-masked]>
Date: Tue, 23 Dec 1997 20:18:14 -0500

At 11:25 AM 12/23/97 -0800, Yoram Bernet wrote:

>
>	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.
>

Well, this is all well and good, and I think this is most definitely a
capability that should be examined.

However, by the same token, there may also be network ingress points
(routers) which won't care about listening to RSVP, and will simply
police traffic based on statically configured token-bucket thresholds.

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.

$.02,

- paul

---

From: Yoram Bernet <[email-masked]>
Date: Wed, 24 Dec 1997 09:41:07 -0800

> -----Original Message-----
> From:	Paul Ferguson [SMTP:[email-masked]]
> Sent:	Tuesday, December 23, 1997 5:18 PM
> To:	Yoram Bernet
> Cc:	[email-masked]
> Subject:	RE: Diffserv/Intserv relationship 
> 
> 
	[Yoram Bernet]  I get the feeling that you're not hearing me. We are
not
	relying on network ingress points to listen to RSVP. I have stated
this several times 
	already.

	In our scenario, there is a BB like device which *we are shipping in
NT 5*, that sits at the
	egress point of our network (and the ingress point of our carrier's
network). This thing is
	configured with the tables which describe the capacity which we have
negotiated with
	the carrier, for each traffic class in each of several 'leased line'
circuits. This thing does
	talk RSVP. This thing will not pass our PATH or RESV messages (but
will reject them
	instead), if the resources requsted (as determined by a mapping of
the service type in
	the RSVP flowspec, to a traffic class within the network) exceed the
resources available.

	So - for the hundredth time - this allows us to dynamically signal
for resources, from our hosts.
	The only things that we require to support RSVP are our sender, our
receiver, and our BB that
	sits at the boundary of our carrier's network. 

	Now - admittedly, things could be made much better and more general,
and resources could
	be manged more efficiently, if router vendors incorporated similar
functionality as the BB described,
	into their routers, but - this can be done on an evolutionary
timescale, if and when router vendors 
	decide that this is something worth doing.

---

From: Yoram Bernet <[email-masked]>
Date: Wed, 24 Dec 1997 09:50:53 -0800

Repeatedly and adamantly denying the value of having hosts invoke per flow
(where a flow is per user/per application) QoS, is akin to repeatedly
denying the value of users having their own PCs rather than a big mainframe.
I understand your concerns wrt scalability and the impact this may have on
the network, but - as has been discussed for the last few days - there are
ways to accommodate per flow QoS at the periphery of the network, while
maintaining aggregate and scaleable QoS at the core. 

Yoram

> Sent:	Wednesday, December 24, 1997 8:36 AM
> To:	Melinda Shore
> Cc:	[email-masked]
> Subject:	Re: Diffserv/Intserv relationship 
> 
> At 11:26 AM 12/24/97 -0500, Melinda Shore wrote:
> 
> >
> >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.  
> >
> 
> 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