Subject: RE: Bandwidth Brokers

From: Yoram Bernet <[email-masked]>
Date: Tue, 23 Dec 1997 00:26:17 -0800

> Geoff responds:
> 
> I'm either blissfully ignorant or I don't see it the same way as Yoram.
> As an ISP I would like to provide a differentiated service which
> internally is triggered by packets which  indicate a desired level
> of relative precedence or packet drop (Paul Ferguson presented
> on his dfraft to this effect in the DC IETF).
	[Yoram Bernet]  Nothing you've stated here, conflicts with what I am
saying. I think you are missing my point.
	Perhaps I am not conveying it clearly.

	I *want* you, as an ISP, to provide a differnetiated service. I
*want* the service which you choose to give my packets, to be 
	determined, internal to your network. (Though I would like to
understand the services you offer). I expect that you and I will 
	negotiate, at the start of each month (or some other period), a
service agreement. In this agreement, you will agree to provide me
	a couple of service types, say a high priority service type and a
low pritority service type and just plain old no-priority. (Call them
	service types HP, LP and NP). You'll agree to carry a certain amount
of traffic in each service type, and what I send in excess,
	you have the right to treat however you like. Also - we're gonna
agree on how I tell you which service type I want each packet to be treated
	with. Let's say i'll mark something in the IP TOS bits or the
precedence bits and we agree on some coding.

	Now, let's consider the following scenario: I have two hosts, each
of which reside on
	a small campus, RSVP aware, network, in different cities. They are
connected by your carrier network, which provides differentiated 
	services, but is RSVP unaware. At the egress point from my network
to yours, I have placed an RSVP aware thing (call it an ACS
	or a BB), which is a box we are building (but hopefully would be
available from router vendors sometime soon). 

	Conider the simple case in which the connection provided by your
network looks like a point to point leased line, and I am only 
	interested in unicast sessions.

	My sending application issues a request for a particular service
type (using the intserv flowspec, in an RSVP message). The smaller,
	campus networks process the RSVP message, doing the appropriate RSVP
thing. Your network carries the RSVP messages through, 
	transparently. My ACS thing, on the egress point of my campus net
(and close to the ingress point to your net) has been provisioned 
	with a copy of the service agreement which you and I have
negotiated. My ACS thing also gets to review the RSVP messages which my 
	hosts are exchanging. It looks at the service type I am requesting,
and it looks at the amount of bandwidth (from the token bucket 
	parameters) that this particular application flow wants to consume
of the service type specified. It compares that aginst the provisioned
contract.
	If enuff is available in the contract, and, if my ACS policy decides
that the requesting user is entitled to get this much bandwidth in the given

	service type, then - it 'accepts' the RSVP reservation (by letting
the RESV message make it all the way back to the sender, unhindered (of
course
	it also has to do a little acounting to deduct the bandwidth
requested from the bandwidth available at this time, for that service
type)). 
	The sender now considers this permission to mark the packets (with
whatever marking you and I agreed), such that they will get the service 
	type that was specified in the intserv flowspec of the RSVP message
(remember that I'm assuming a mapping from intserv service type to HP,
	LP and NP, and I know how to mark the packets accordingly. 

	At this point, the sender marks the packets so that they get the
service the sender asked for (in the diff-serv part of the network). They'll
get RSVP service
	in the RSVP aware parts of the net. I'm actually marking packets at
the end stations, which saves the need for routers to clasify anywhere else.
You don't have
	to apply any filter specs other than to monitor the traffic that i'm
submitting at each service level to make sure I don't exceed my contract.
I'll be worrying about 
	shaping my traffic flow by flow, so that I cna get the finer grain I
need for my different apps and different users. You police me in aggregate
to protect your network and
	enforce our contract.

> The model with my customers is that I will account for and
> honour queue precedence and drop precedence fields up to
> a contracted max value, and may also apply a traffic shaping
> to the entire customer traffic profile as per a contract.
	[Yoram Bernet]  Yeah - you can shape me if you like. I guess that by
shaping all my
	traffic in aggregate, I get a marginal benefit, but - it's much more
important to me, to shape 
	my traffic on a flow by flow basis. I don't expect you to do that
for me. I'll do it at the hosts
	and maybe at some key nodes where my network is still small enough
that this is not a scaling 
	nightmare. If I scew up my flow by flow shaping - that's my problem.
If I violate the contract at
	your ingress point - you can discard my packets indiscriminately.

>  The issue
> here is providing a mechanism to provide to the customer
> differentiated service levels, rather than absolute guaranteed
> levels, which is what I thought was the critical discriminant of
> the diff-serv effort.
	[Yoram Bernet]  I made no mention of absolute guarantees anywhere in
this mail thread. Absolute
	vs. guaranteed is completely orthogonal to the mechanism I have been
discussing.

> >	[Yoram Bernet]  i'm not opposed to a dierent wg. what i am arguing
> >for, is that there must be a wg, that, in parallel, decides how the users
> >are going to make use of (or invoke) the diff services that they need
> (you
> >do want users using this - correct?). i'm also further urging, that we
> >consider allowing the users to use rsvp to do so.
> 
> Geoff responds:
> I must admit that I was looking more at packet marking rather than
> RSVP in my mental model, but thats neither here or there.
> I would see a diff-serve WG looking at both the semantics of
> a differentiated serive environment and looking at the singalling
> structures which allow differentiated service requests to be passed
> between different administrative network domains. Rather than
> 2 parallel WGs as you may be suggesting I see no real difficulty
> in a single WG with a charter which includes both topics.
> 
> regards,
> 
>    Geoff
> 
> -- 
> Mailto: [email-masked]          Technology Manager , Telstra Internet
> Phone: +61 2 6208 1908
> PGP public key:
> http://pgp.ai.mit.edu:11371/pks/lookup?op=vindex&search=[email-masked]
> 
> See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

---

From: Jean-Yves Le Boudec <[email-masked]>
Date: Tue, 23 Dec 1997 19:24:53 +0200

Thank you Yoram for this clear explanation. A small detail: I believe you
need to shape the aggregate flow out of your campus network. Shaping n
flows individually and policing the aggregate will cause some problems, a
well known thing which happened with early ATM trials.
JY