Subject: RE: Bandwidth Brokers

From: Tom Lemaire <[email-masked]>
Date: Thu, 18 Dec 1997 13:38:22 -0500

> At 08:14 PM 12/17/97 -0800, Yoram Bernet wrote:
> 
> >By integrating RSVP with diff-services, it should not be necessary to
> do per
> >flow classification at each node. Routers at edges of the larger
> networks
> >could classify based only on IP TOS/precedence bits, and this would
> be
> >required only for the purpose of policing.
> >
> 
> Paul Ferguson responded:
> 
> >This is one of the issues (RSVP/diffserv interworking) that I
> referred
> >to during my presentation at the intserv meeting last Monday as being
> >"interesting, but not immediately important."
> 
> >Since RSVP is not widely (and some would argue that it is not at all)
> >deployed in the Internet proper, there is no compelling reason to put
> >this on the fast-track. Conversely, diffserv needs are immediate.
> 
> How will the edge routers know how to set ToS, assuming it is them and
> not
> the end-stations doing ToS stamping?  RSVP would be an excellent
> vehicle
> for differentiating traffic for purposes of stamping ToS differently.
> As for
> deployment, I understood deployment in Windows was pretty soon now.
> 
> Tom Lemaire
> Redstone Communications

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 18 Dec 1997 16:34:14 -0500

> deployment, I understood deployment in Windows was pretty soon now.

There is running code deployed today which allows the administrator
to define a token-bucket threshold on the edge router which is 
capable of marking packets that are in or out of threshold profile.
The granularity is such that the administrator can pick the marking
level for either (in or out of profile), the watermark (the profile
threshold), and the specific action to take upon exceeding bitrate
threshold (mark as lower precedence or drop completely).

Of course, this is done by hand, and works. It doesn't *require*
a signaling protocol. Designing a diffserv model that *requires*
it is, in my opinion, quite arrogant.

Again, I'm not saying that RSVP/diffserv interworking is not
interesting (haven't I already said this a couple of hundred
times?), it's just that it may very well delay the deployability
of a 'standard' method of doing something similar to what I
described above.

- paul

---

From: Geoff Huston <[email-masked]>
Date: Fri, 19 Dec 1997 11:48:23 +1100

The question as I see it is whether the creation of the
admission function which allows elevated TOS packet
into the network is an outcome of the sales force
or an outcome of the network's metrics of capability.

I agree with Paul's view that the first cut will see such admission
systems being hand configured as an outcome of the customer
making a purchase of elevated quality delivery services,
and it will be an engineering task to ensure that the core
of the network can honour the admission profile.

We are a long way from having this second step automated
in my humble view.

g

-- 
Mailto: [email-masked]          Technology Manager , Telstra Internet
Phone: +61 2 6208 1908
PGP public key: http://www.pgp.com/keyserver/pks-lookup.cgi

See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/