Subject: RE: Bandwidth Brokers

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

We're actually providing something very similar to the BBs' described. We
call it ACS (for admission control server). I won't claim to understand
exactly what the authors of the draft had in mind when describing their BB,
but I will offer our view on how an ACS would do this job...

First of all, the service offered by the ACS would start out quite modest
and would gradually increase in levels of sophistication, much as the BBs do
from example to example.

In the simplest case, one can imagine a single 'leased line' type of service
offered by each carrier, from point A to point B. A carrier agrees to carry
X bandwidth of trafic from point A to point B, for a certain other carrier.
Probably, they also agree to provide two or more levels of prioritization
within the 'leased line'. This is an easy problem to solve. The ACS at the
egress point from my network and at the ingress point to the next carrier's
network, is provisioned to know how much bandwidth I have negotiated with my
carrier, from point A, to point B. In our case, we use RSVP signaling to
carry the resources required, the policy element (user ID), the standard
RSVP 'routing information' (session address). So - for a simple topology
such as this, I can provision dumb, static routing tables (much like a
default gateway) in the ACS to recognize, based on RSVP session adress,
whether the resource request is for resources on the pipe from A to B.

I can take this a step further, and extend my tables to acommodate multiple
leased lines, with multiple egress points. Of course, this si still
staticaly provisioned and is osmewhat of a nuisnace to manage, but I think
it offers a compelling level of fucntionality. In addition, this is easier
for unicast, than for multicast.

This all works if the service model is a set of 'leased lines' with defined
ingress and egress points and provisioned capacity on those lines.

There are a number of axis on which one could get more sophisticated. One of
these is to allow the bandwidth on these 'leased lines', to change on demand
(as opposed to being pre-provisioned). Then it would be necessary for the
ACS at my egress point to negotiate the increased resources required, with
the BB (or equivalent) at the carrier's ingress point. Another axis is the
acomodation of cloud topologies, in which I am not limited to some
provisioned set of egress points. This would benefit from a solution to the
previous problem (dynamic negotiation with the carrier's BBs) and would
require more sophisticated signaling among BBs within the carrier's netowrk
(or a combination of overprovisioning and use of heurisitcs).

Yoram

> -----Original Message-----
> From:	Octavio Medina [SMTP:[email-masked]]
> Sent:	Wednesday, December 17, 1997 6:32 AM
> To:	[email-masked]
> Subject:	Bandwidth Brokers
> 
> I'm having some problems understanding how the Bandwidth Brokers defined
> in draft-nichols-diff-svc-arch-00 are going to work.
> 
> In the examples, when a new Premium connection is to be established, 
> the domain BB asks the next domain BB in order to "reserve" 
> a fraction of the negotiated bandwidth. The text says:
> 
> "...In Figure 7, V wants to transmit a flow from LBL to D at MIT at 10
> Kbps. 
> As in figure 6, a request for this profile is made of LBL's BB. LBL's BB 
> authenticates the request and checks to see if there is 10kbps left in its
> 
> Marked allocation going in that direction."
>                   ^^^^^^^^^^^^^^^^^^^^^^^
> 
> My question is: How does the BB know the path of the flow? More exactly, 
> how does he know which will be the next domain crossed by the flow?
> 
> How much routing information will be required in BBs to make them work?
> 
> 
> -Octavio Medina
>  ENST Bretagne, France.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 18 Dec 1997 09:19:33 +1100

>but I will offer our view on how an ACS would do this job...

   [...]

Thanks for the additional explanation, and its helping...!

But in my humble opinion Octavio's original query remains - in a large and
well meshed topology, where the scope of the BB is such that there are
multiple internal paths to multiple exit points to the next BB-scope
how does the locally-scoped BB figure out how much reservable space
is avilable on a routing-determined transit path through the local BB-scope,
and how is this state maintained?

IF the answer is 'RSVP', then given the apparently admitted scaling
problems with RSVP the next question is how is the BB model relevant
in other than smaller-scale network infrastrucures?

thanks,

  Geoff

-- 
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: Yoram Bernet <[email-masked]>
Date: Wed, 17 Dec 1997 15:03:20 -0800

below...

> From:	Geoff Huston [SMTP:[email-masked]]
> Sent:	Wednesday, December 17, 1997 2:20 PM
> To:	Yoram Bernet
> Cc:	Octavio Medina; [email-masked]
> Subject:	RE: Bandwidth Brokers
> 
	[Yoram Bernet]  well - if you use RSVP to carry around the
reservation/policy messages, then you can co-locate bbs with key routers in
the network cloud. if you do this, then each bb really needs to understand
the topology only between itself and the next bb. so - you can segment the
cloud into reasonable size pieces (hopefully). because the bbs are colocated
(or at least correlated) with the routers, they have implicit knowledge of
the topology...

> in other than smaller-scale network infrastrucures?
	[Yoram Bernet]  the scaling problems with rsvp fall into a number of
categories (which were described nicely in one of the recent drafts, perhaps
steve berson's). one of them, and probably the most worrisome, is the need
to keep per flow rsvp state in routers and to classify packets, in routers
to one of some very large number of flows... the bb, as i understand it,
keeps aggregated state, which is significantly less than a full rsvp
implementation. Furthermore - it's implemented only at key nodes in the
network. The per flow classification requirement for internal nodes - just
goes away... I'm fairly convinced that this works for unicast. I need to
think further about the multicast case.

---

From: Jim Boyle <[email-masked]>
Date: Wed, 17 Dec 1997 22:49:48 -0500

>think further about the multicast case. 

Yoram, you are correct, RSVP has some problems in many areas.  I'm less
concerned about the per-flow stuff (which could *easily* be resolved by use
of tunnels ;) as I am with the shared reservation (which to my
understanding requires per-reservation classification at each node).  If we
lived in a world of fixed filters, though, I think we could come up with
something that Geoff *might* be interested in.

regards,

Jim

---

From: Yoram Bernet <[email-masked]>
Date: Wed, 17 Dec 1997 20:14:45 -0800

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.

Yoram

> From:	Jim Boyle [SMTP:[email-masked]]
> Sent:	Wednesday, December 17, 1997 7:50 PM
> To:	Yoram Bernet; Geoff Huston

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 18 Dec 1997 07:11:10 -0500

>required only for the purpose of policing.

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.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 18 Dec 1997 11:39:15 -0500

At 06:37 AM 12/18/97 -0800, Yoram Bernet wrote:

>Diffserv requires conveying some degree of policing (or classifying)
>information and requires some degree of admission control. With no admission
>control, there is no integrity ot the 'high-priority' class.
>

I fail to understand why having admission control requires the use
of some sort of additional (or complementary) protocol. Having said
that, if you'll recall earlier remarks, I have never said that 
the use of a signaling mechanism to set up a differentiated service,
and perhaps associated admission control mechanisms, is not
interesting.

What I have said, however, is that there are immediate needs for
some sort of simple diffserv implementation (the definition of
'simple' is admittedly subjective). 'Simple' is relative. My
suggestion is that the more complex the diffserv implementation,
the longer the deployability time frame. This can become somewhat
self-defeating.

Therefore, I liked the framework timeline that John Wroclawski
presented in Washington for issues which need to be examined
insofar as diffserv is concerned -- separate issues into
'short-term', 'mid-term', and 'longer-term' issues. I think is
fair and objective. Now, the we need to go through the
exercise of determining what deserves examination, and where
they fit into the framework within the timeline.

If John would be so kind as to post this, we could have a
point of reference.

>So - I claim that you need some kind of protocol to admit flows to the
>various classes of differentiated services. Preferrably, this protocol has
>some clue of the topology that the admitted flows are traversing. Various
>draft's on differentiated services have also made this claim. 
>

Sorry, I disagree. I don't argue that a classification scheme is
needed, but I don't agree that a signaling protocol is required,
at least in the short term, to provide this function. 

>What protocol are you planning on using?
>

I don't prescribe one. I do think, however, that RSVP/diffserv
interworking is important in the long-term (assuming that RSVP
is even a valid mechanism when we get there), but not in the
short-term.

- paul

---

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

> 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).
> 
	[Yoram Bernet]  So - i need to visit every edge router in the path,
and configure which of each 
	of the ten thousand employees originating from my site get the
higher priority and which get the
	lower priority... oops... but - i'm using dhcp, so - i may have to
call you every few days and ask you
	to reconfigure the list i gave you the other day. and - oh yes - the
application i wanted to get
	high priority actually uses different ports from time to time.
should i call you every time i launch the 
	application and it uses a different port?

> 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.
> 
	[Yoram Bernet]  Who is designing a diffserv model that requires a
signaling protocol? What's being discussed here is 
	the following: we *will* be deploying hosts that signal their
requirements, dynamicaly, using RSVP. We *will* be providing
	something akin to bandwidth brokers that *will* sit at the
boundaries of *our* network, and determine based on the resources requested
	and the priority at which they have been requested and the capacity
at that priority that we have negotiated with our carrier, whetehr to let
	the RSVP message pass unhindered or whether to reject it. 

	This general approach will work with any diff-serv solution. It does
not *require* anything from diff-serv, nor does diff-serv require anything
from it.
	It's just a natural complement to diff-serv. It's not particularly
complciated (for the limited but very compelling case of point to point
unicast services).
	We are building it. Our version of the BB will be simplistic. I'm
inviting you to be a part of this, since I think that, in the long run,
there are people who can do a much better job of building BBs than us.

> 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: [email-masked]
Date: Fri, 19 Dec 97 09:03:57 PST

*> Yoram, you are correct, RSVP has some problems in many areas.

Confuscius say: People who shoot from hip often miss target.

Bob Braden

---

From: Yoram Bernet <[email-masked]>
Date: Fri, 19 Dec 1997 13:38:26 -0800

this is exactly my point.

> From:	Juha Heinanen [SMTP:[email-masked]]
> Sent:	Friday, December 19, 1997 11:51 AM
> To:	Yoram Bernet
> Cc:	[email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject:	Re: RE: Bandwidth Brokers
> 
> yoram,
> 
> you don't need to tell the carrier how to classify your flows.  you can
> do it in your own router.
> 
> -- juha

---

From: Yoram Bernet <[email-masked]>
Date: Fri, 19 Dec 1997 14:56:14 -0800

I hope you do not construe our exchange as a criticism of RSVP. The snippet
below is quoted out of context. 

We view RSVP as a very useful protocol for hosts to use to signal their QoS
requirements to the network and to their peer hosts at the other ened of the
network. In fact, the excerpt above was taken from a discussion advocating
the use of RSVP to negotiate with those parts of the network that do not
support RSVP but do support some type of class of service or differentiated
service.

For various reasons, some no doubt legitimate, some not - there are parts of
networks we are interested in that do not directly support RSVP at this
point in time...

Yoram

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, December 19, 1997 9:04 AM
> To:	[email-masked]
> Cc:	[email-masked]

---

From: Yoram Bernet <[email-masked]>
Date: Mon, 22 Dec 1997 11:18:13 -0800

below...

> From:	Roch Guerin [SMTP:[email-masked]]
> Sent:	Monday, December 22, 1997 11:08 AM
> To:	Yoram Bernet
> Cc:	Juha Heinanen; [email-masked]; [email-masked];
> [email-masked]
> Subject:	Re: Bandwidth Brokers 
> 
> [snip]
> Definitely.  Also want to make sure that users/apps that start using RSVP
> and
> requesting intserv services are able to easily operate across clouds that
> are
> built around diffserv mechanisms.
	[Yoram Bernet]  I have to agree here. We're going to be providing
many of these apps and network OS components on hosts that run these apps.
These will use RSVP to request intserv mechanisms. We can easily change the
service type definitions. We can't easily change the notion that a service
type can be requested using RSVP signaling.

> >somewhat vague on exactly what intserv encompasses. In any case, why
> should
> >we not continue to use the same notion of filterpsec to define patterns
> for
> >classification?
> 
> Agree again.  Actually, the fine granularity of RSVP filters specs has
> often
> been mentioned as one of its problem wrt scalability, but it seems that
> this
> then calls for defining new filter specs.  
	[Yoram Bernet]  I'm not sure that this requires defining new
filterpsecs, at least not at the host/network boundary. I think that the
scalability problems of RSVP, are not necessarily related to the granularity
of filterpsec directly, but rather to the need to program classifiers to
differentiate flows at such a fine granularity. I think that the diffserv
work (and various other proposals for aggregation within the network) allow
the classifiers in the routers to be coarser grain, but do not preclude the
use of fine grain filterspecs at host/network boundaries.

> >In summary, I think that we should, for the sake of consistency (and
> because
> >it seems to make sense), continue to apply the intserv model, at least at
> >the host/network boundary. This means (to me):
> >
> >- Using a set of service types.
> >- Defining our offered traffic (or requested traffic) using the token
> bucket
> >model.
> >- Providing filterspecs to describe the packets which should be
> associated
> >with the service type and the token bucket model.
> 
> To this I would probably add support/mapping for intserv services in the 
> diffserv framework.
	[Yoram Bernet]  Yes - of course. 

> Roch

---

From: Raj Yavatkar <[email-masked]>
Date: Mon, 22 Dec 1997 12:06:08 -0800

See below ...

At 02:07 PM 12/22/97 -0500, Roch Guerin wrote:
>
>Definitely.  Also want to make sure that users/apps that start using RSVP and
>requesting intserv services are able to easily operate across clouds that are

I think we are beginning to see the apps being commercially available that
will use this capability.
>
>>
>
>Absolutely.   Furthermore, the RSVP and intserv models were developed
under a 
>certain set of assumptions and to satisfy a number of requirements.  It may 
>well be that those assumptions and requirements turned out not to be the
most 
>pressing ones, but I think many remain valid and they do represent a
reasonable
>fraction of the space we eventually want to cover.  Discounting all this and
>assuming that the current set of goals are the only ones that matter, would
>in my opinion be a mistake.  This is my motivation for a *consistent*
approach.

I agree. I think some of the commotion around diff-serv is disturbing in
the sense that it is advocates throwing away what has been learned over
past so many years in the context of both ATM and int-serv models (refer to
Andy Campbell's email a couple of weeks back). I believe diff-serv only
build on what has been done in terms of solving the scalability problems in
the backbone.

>
>
>>As for the filterpsec - I was using 'filterspec' in a generic form to refer
>>to a pattern which is used to classify packets to flows. I did not realize
>>that 'filterspec' was considered part of intserv, per-se. In fact, i'm
>>somewhat vague on exactly what intserv encompasses. In any case, why should
>>we not continue to use the same notion of filterpsec to define patterns for
>>classification?
>
>Agree again.  Actually, the fine granularity of RSVP filters specs has often
>been mentioned as one of its problem wrt scalability, but it seems that this

I disagree. Filterspecs themselves do not create the scalability problem.
Majority of the apps will end up suing fixed filter for unicast apps and
(may be wild card) for multicast. However, that is not what is the root of
the scalability problem as long as diff-serv defines how to aggregate
reservations so that we don't have to do per-flow filltering or
classification in backbone routers. From end app's poin of view, filter
specs continue to serve the same purpose.

As a matter fact, Jim Boyle had made
>such a proposal a while back for such an extension, i.e.,
>            J. Boyle.  RSVP extensions for CIDR aggregated data flows,
>            (draft-rsvp-cidr-ext-00.txt).  Internet draft (work in
>            progress), Internet Engineering Task Force, February 1997.
>such extensions would definitely be of value.  Alternatively, you can achieve
>that level of aggregation using RSVP to setup layer 2 (e.g., MPLS as Tony Li
>has mentioned on a number of occasions) or even layer 3 tunnels.
>
>>In summary, I think that we should, for the sake of consistency (and because
>>- Defining our offered traffic (or requested traffic) using the token bucket
>>model.
>>- Providing filterspecs to describe the packets which should be associated

well put.

Raj

>To this I would probably add support/mapping for intserv services in the 

-----------------------------------------
   Raj Yavatkar                                       
   Communication Architecture Lab           [email-masked]
   Intel Corporation, JF3-206                     voice -- 503-264-9077
   2111 NE 25th Avenue,  Hillsboro, OR 97124

---

From: Yoram Bernet <[email-masked]>
Date: Mon, 22 Dec 1997 16:58:11 -0800

Follow up to Geoff's mail...

	[Yoram Bernet]  snip... 
> The possibilites for diff serve encompass a larger set of
> adopters within the ISP community who are vintally interested
> in the deployment of  simple service level differentiation
> on their infrastructrure. 
	[Yoram Bernet]  are they interested in selling these services to
customers? are customers going to forever have to call in lists of
privileged users that the isps should configure into their devices? if not -
are you telling me that the user will never be able to provide different
service levles for to different users/apps? what i'm getting at, is that
ultimately, the users are going to have to invoke the services you offer.
either there's a host based protocol for doing so, or there's some static
provisioning mechanism, which will becoem a managemnt nightmare.
> For such a adoption community the
> inherant scale problems of RSVP (RSVP aggregation
> notwthstanding)  are an effective nbarrier to adoption.
	[Yoram Bernet]  we've already shown, a number of times, how rsvp can
be used to signal to the network boundary, at which point thi ssignaling can
cause the appropriate diffserv things to happen. in the unicast case, this
avoids burdening the network core with rsvp scalability issues. in the
multicast case, it almost does, and could be made to do so, with some
additional work.

> So I find that I don't believe that 'consistency" is paramount to
> 'applicability' in this debate, and accordingly I'm of the opinion that
> it would serve the IETF well if the Area Directors seriously
> considered the chatering of a diff-serve WG to focus
> on the particular issues which are intrinsic to the 
> potential deployment base of such mechanisms.
	[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 Huston
> PGP public key:
> http://pgp.ai.mit.edu:11371/pks/lookup?op=vindex&search=[email-masked]
>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 23 Dec 1997 17:14:18 +1100

[geoff wrote]
>> adopters within the ISP community who are vitally interested

>provisioning mechanism, which will becoem a managemnt nightmare.

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

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

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

---

From: Yoram Bernet <[email-masked]>
Date: Tue, 23 Dec 1997 10:48:52 -0800

maybe we should look at committed rate and pbe again. the way i see this, is
that - as we looked into the services that could
be provided, from the diff-serv viewpoint, we concluded that they are of a
slightly different nature than the services that we
wanted from the intserv viewpoint. that's ok. they're still services and
there still can be a mapping from intserv services (whichever
valid ones end up being defined), to diff-serv services.

y

> From:	Wu-chang Feng [SMTP:[email-masked]]
> Sent:	Tuesday, December 23, 1997 9:15 AM
> To:	[email-masked]
> Cc:	[email-masked]
> > ....[discussion of controlled-load service deleted]..
> > proposed.  I believe that it now explicit states that preserving packet 
> > ordering is preferred (although not mandated).  
> 
> If this is the case, then compliant and non-compliant packets of the same
> flow see similar delay.  How is this any different than protected
> best-effort
> service, then?
> 
> It seems peculiar to me that two of the services which are currently
> being proposed for diffserv (premium and assured) are minor variants of
> intserv services (committed rate and protected best-effort) which were 
> already looked at and discarded.  Did the use of priority bits 
> somehow change the services we want out of the network?
> 
> Wu

---

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

Agreed. As far as I see it though, the 'problems' will be my problems, and
will be isolated. My 'problems' will not impact the provider's other
customers. If I am wise, I will shape at several points in my local network,
possibly at varying granularity, such that, when I reach the provider's
network, I am reasonably in line with what I have contracted. 

Yoram

> From:	Jean-Yves Le Boudec [SMTP:[email-masked]]
> Sent:	Tuesday, December 23, 1997 9:25 AM
> To:	Yoram Bernet; [email-masked]
> 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
> 
> 
> >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.
> >
>

---

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

Exactly my picture. The only hook I need for this to work, is an agreed upon
mapping of intserv
service type to bits in packet headers (much as has been done to map service
types to 802.1p
bits, in the Smith/Crawley/Seaman draft).

> Sent:	Wednesday, December 24, 1997 4:55 AM
> To:	Paul Ferguson
> Cc:	Roch Guerin; [email-masked]
> Paul,
> >Cool. I think we agree (?).
> 
> I think we do, but to make sure ;-) let me draw a small picture.
> What I'd like to be able to have without too much headache is the
> following:
> 
>    ------        ----------------        ------
>   /RSVP  \      /                \      /RSVP/ \
>  /IntServ \    /                  \    /Intserv \
>  |enabled |----| Diffserv Backbone|----|enabled |
>  \network /    \                  /    \network /
>   \      /      \                /      \      /
>    ------        ----------------        ------
>      AS1              AS2                  AS3
> 
> where hosts in AS1 and AS3 which use RSVP can setup an end-to-end RSVP
> connection between them and crossing the Diffserv backbone AS2 without
> too much headaches.  That means that I would like to have the ability
> of using the diff-serv mechanisms in AS2 to make sure I can give the
> "right" level of service to my RSVP flows between AS1 and AS3. 
> This can initially be a "PVC" like solution where you have a provisioned
> diffserv pipe between AS1 and AS3 across AS2 and you manage things at
> the boundaries, and can eventually evolve (if needed) to an SVC type
> solution where the size of the pipe between AS1 and AS3 can be adjusted
> as flows come and go (note that it is still a diffserv pipe, even in this
> case).
> 
> I had a brief discussion with Yoram on this in D.C., and I think he has a
> similar picture in mind (Yoram, I don't mean to put words in your mouth,
> so
> feel free to amend this as needed).  
> 
> An important point is that the aspect of managing the mapping of
> RSVP/Int-Serv
> requests to the diffserv pipe is *NOT* something I'm asking diffserv to
> worry
> about.  This will be the responsibility of the entity at the boundary
> (whatever
> we call it), and I just want diffserv to give me some simple hooks so that
> I
> can provide this functionality.
> 
> Roch
> 
> 
> 
>

---

From: "Kenneth Peirce"<[email-masked]>
Date: Thu, 25 Dec 1997 22:52:41 -0600

This picture is the same as that developed in the i2 community. It's called
the "burnt marshmallow" because the QoS guarantees are hard on the outer
edges and soft in the middle.  I am interested in having the WG come up
with just such a mapping as is requested by Yoram.

Ken Peirce
3COM
My Opinions, not 3COMs', does not include applicable taxes or titles, offer
good only in NJ on February 31st. Contest ends 12/31/76. Contest not open
to sentient beings.

Yoram Bernet <[email-masked]> AT Internet on 12/24/97 09:46:32 AM

To:   Roch Guerin <[email-masked]> AT Internet@ccmail, Paul
      Ferguson
 <[email-masked]> AT Internet@ccmail
cc:   [email-masked] AT Internet@ccmail
Subject:  RE: Bandwidth Brokers

Exactly my picture. The only hook I need for this to work, is an agreed
upon
mapping of intserv
service type to bits in packet headers (much as has been done to map
service
types to 802.1p
bits, in the Smith/Crawley/Seaman draft).

> I think we do, but to make sure ;-) let me draw a small picture. > What
I'd like to be able to have without too much headache is the
> where hosts in AS1 and AS3 which use RSVP can setup an end-to-end RSVP >
connection between them and crossing the Diffserv backbone AS2 without >
too much headaches.  That means that I would like to have the ability > of
using the diff-serv mechanisms in AS2 to make sure I can give the > "right"
level of service to my RSVP flows between AS1 and AS3. > This can initially
be a "PVC" like solution where you have a provisioned > diffserv pipe
between AS1 and AS3 across AS2 and you manage things at > the boundaries,
and can eventually evolve (if needed) to an SVC type > solution where the
size of the pipe between AS1 and AS3 can be adjusted > as flows come and go
(note that it is still a diffserv pipe, even in this > case).
> can provide this functionality.

Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP
  (IMA Internet Exchange 2.02 Enterprise) id 4A1DA300; Wed, 24 Dec 97
  21:59:44
-0600
mail3.microsoft.com with Internet Mail Service (5.5.1960.3)
 id <ZFR0VLQ4>; Wed, 24 Dec 1997 09:46:35 -0800
Message-ID:
<[email-masked]>
From: Yoram Bernet <[email-masked]>
To: Roch Guerin <[email-masked]>, Paul Ferguson
  <[email-masked]>
Cc: [email-masked]
Subject: RE: Bandwidth Brokers
Date: Wed, 24 Dec 1997 09:46:32 -0800
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: [email-masked]
Precedence: bulk

---

From: Yoram Bernet <[email-masked]>
Date: Fri, 26 Dec 1997 06:58:44 -0800

below...

> From:	Paul Ferguson [SMTP:[email-masked]]
> Sent:	Friday, December 26, 1997 5:21 AM
> To:	Roch Guerin
> Cc:	[email-masked]
> There are, of course, a couple of ways to handle this situation:
> 
>  1. Create RSVP-interserv/diffserv mappings, such that the
>     Sender TSpec can be mapped with relative equity to a
>     diffserv QoS level at the interdomain boundry,
> 
>  2. Tunnel RSVP through the non-RSVP cloud.
	[Yoram Bernet]  I don't really see it as one or the other. As data
passes through the network, it may encounter regions of soft mashmallow and
regions that are crisp. In the mechanism I envision, RSVP is signaled end to
end, interpreted in those burnt regions that wish to and passed
transparently through those soft regions that do not.

> Again, I don't disagree that (1) is beyond the scope of 
> the diffserv charter -- just trying to prioritize things.
> I think this is where we disagree -- I don't attach an
> immediate need for (1), simply based on the fact that
> RSVP is not widely deployed today (and there are questions
> on whether it will tomorrow).
	[Yoram Bernet]  And diff-serv *is* widely deployed today? You *will*
see RSVP on many, many hosts, within a year. I envision both deployed and
both interoperating.

	yoram

> - paul
> 
> 
> At 07:54 AM 12/24/97 -0500, Roch Guerin wrote:
> 
> >
> >we call it), and I just want diffserv to give me some simple hooks so
> that I

---

From: "Rao, Viswanatha" <[email-masked]>
Date: Tue, 30 Dec 1997 15:51:02 -0600

>From:	c=US;a= ;p=COMPAQ;dda:ZID=<yoramb(a)microsoft.com>; 
>Sent:	Friday, December 26, 1997 8:59 AM
>To:	Rao, Viswanatha; c=US;a= ;p=COMPAQ;dda:ZID="Paul Ferguson"
><ferguson(a)cisco.com>;; c=US;a= ;p=COMPAQ;dda:ZID="Roch Guerin"
><guerin(a)watson.ibm.com>;
>Cc:	c=US;a= ;p=COMPAQ;dda:ZID=<int-serv(a)ISI.EDU>;
>[Rao, Viswanatha]  Enablng RSVP in a O/S does not mean that applications will
>be deployed in many many hosts within a year or even in future. 
>	yoram
>
>> - paul
>> 
>> 
>[Rao, Viswanatha]  
>Systems Enginner
>COMPAQ

---

From: Yoram Bernet <[email-masked]>
Date: Tue, 30 Dec 1997 14:35:04 -0800

> >be deployed in many many hosts within a year or even in future. 
	[Yoram Bernet]  I'm not sure what you're trying to add to the
discussion here... Are you saying that no applications will be deployed in
hosts? Do you mean QoS aware applications won't be deployed?

	In any case, we will be providing QoS aware applications, and we are
working with third-party application vendors to make sure that they provide
QoS aware applications. Furthermore, we (and other ISVs) are working on
management utilities that will allow non-QoS aware (legacy) applications to
enjoy the benefits of QoS in the OS...

	So - I agree with you, that there are no guarantees... but I prefer
to base my decisions on statistical probability...  It is probable that QoS
aware applications will be deployed incrementally and that they will take
advantage of QoS aware OSs.

	Yoram