Subject: RE: Bandwidth Brokers

From: Yoram Bernet <[email-masked]>
Date: Fri, 19 Dec 1997 08:22:02 -0800

I am not proposing the automation of the provisioning of the total service
capacity between carriers (or any big networks). However, there are two
reasons to signal: one would be to alter this provisioning. I agree with you
- let's defer that one... It's not really a host problem anyway - so - I
would be out of my league to discuss it. However, there's another signaling
problem - that of deciding which of my host generated application flows is
actually going to get put in the 'high priority band' of that carrier's
network, and which will be put in the 'low priority band'. 

We could take two approaches to this problem. The completely static aproach
is as follows: At the start of the month (or whenever I renegotiate my
agrement with my carrier), I give my carrier a list of filterspecs that I
want treated with high priority and a list of filter specs that I want
treated with low priority. These are installed in the carrier's ingress
router's tables. This approach doesn't make me happy for several reasons:

1. I need to anticipate my exact requirements and filterspecs a-priori. This
may be impossible.
2. I need to be very conservative or risk not getting the results I want -
For example, if I have two employees that should each be allowed to send 3
Mbps high priority streams through a pipe for which i've negotiated a total
of 5 Mbps 'high priority' capacity with my carrier. Then - if I tell my
carrier to classify both of them into the 'high priority' band, and they
both send at once, neither gets what they should. I could be conservative
and tell my carrier that only one of them should get the high priority
band... but then - I'm screwing the other out of use of the high priority,
even when the first is not using it.
3. The carier's going to spend their router resources classifying based on
filterspecs (when they could be policing packets with the 'higher than best
effort' TOS bits, which I expect is an easier job) instead of just
forwarding my packets quickly. I don't claim to be a router expert here, but
I suspect that this is the case...

In a year, I can safely say, that there will be a large number of end
stations that use RSVP to signal resource requests for some significant
numebr of significant apps. I would like to take adavntage of this. So - the
second approach says that there's a BB or whatever, at the boundary of the
carrier's network, that knows how much traffic the carrier has agreed to
carry from me, in each priority band. Assume there is some mapping from RSVP
PATH/RESV info to priority band (as there is a mapping from intserv service
type to 802.1p priority). Now - I dynamically signal for each application
flow, using RSVP. This signaling need not be processed anywhere within the
carrier's network. I may have a campus network which processes RSVP before
reaching the carrier, or I may not... However, I would like the BB to be
able to review this resource request and determine whether the provisioned
capacity for the appropriate priority can accommodate the flow i'm trying to
get permisison for. If it can, the RESV will eventually return to the
sender, and I can set the priority bits int he IP header to the appropriate
mapping from the RSVP parameters I initially requested.

Note that RSVP still gets carried transparently through the carrier's
network. RSVP messages do get inspected at the BB, for the purpose of
admission control, but - neither the BB, nor the ingress routers need to
keep per flow state. All they need to track is the total amount of bandwidth
admitted to each of the diff-services priority bands...(or classes of
service or whatever). The routers are only requried to police to the total
negotiated cpacity at each priority level (based on TOS bits, etc). This
achieves the policing function of protecting the carier's network. It pushes
back to the egress router (or the hosts, ultimately), the need to handle per
flow policing/shaping.

I expect that this is not at all complicated or unrealistic to implement in
the next year, at least for the model of point-to-point, leased line service
from the carriers.

Yoram

> -----Original Message-----
> From:	Geoff Huston [SMTP:[email-masked]]
> Sent:	Thursday, December 18, 1997 4:48 PM
> To:	Paul Ferguson
> Cc:	Tom Lemaire; [email-masked]
> Subject:	RE: Bandwidth Brokers
> 
> 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
> 
> 
> 
> At 04:34 PM 12/18/97 -0500, Paul Ferguson wrote:
> >At 01:38 PM 12/18/97 -0500, Tom Lemaire wrote:
> >
> >> 
> >> >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.
> >> 
> >
> >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
> >
> >
> >
> -- 
> 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/

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 19 Dec 1997 21:51:06 +0200

yoram,

you don't need to tell the carrier how to classify your flows.  you can
do it in your own router.

-- juha