Subject: RE: Bandwidth Brokers

From: Paul Ferguson <[email-masked]>
Date: Mon, 22 Dec 1997 20:33:11 -0500

[gih and sob explicitly removed from CC: as I believe
 they are both subscribed to the list]

At 04:58 PM 12/22/97 -0800, Yoram Bernet wrote:

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

I believe you are making a worst-case scenario insofar as the limitations
of static configuration here. Granted, it could certainly be a pain in
the neck if there is a different CoS profile required for each user, and
for each user's various applications, and for each user's various
applications to have different watermark thresholds, and...

You get the picture. I personally don't think its realistic, but
I'm definately not ruling out nightmares.

On the other hand, I'm optimistic because I have been listening to
several service providers who have unequivocally stated that all
they are interested in, at least for the short term, is a simple
two or three level differentiation -- best effort, better effort,
and better best effort (my semantics, not theirs). And they have
also stated that it would be done on a granularity such that static
configuration would not be a concern.

Now, having said that, I don't pretend represent all service providers
on the planet, and I certainly only use this as a simplified illustration.

As an aside, the majority of the deployed hosts on this planet do
not speak RSVP. Again, at least for the moment.

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

This is all well and good, but let's not preclude diffserv mechanisms
which do not include RSVP signaling. That would be ludicrous. If a
service provider desires his downstream subscribers use RSVP to
signal the first-hop router to set up diffserv mechanics, and if
all of his downstream subscribers speak RSVP, cool.

I believe what we are looking for here is what I have referred to
several times as 'semantics'. That is, we need to define how the
Sender TSpec will map to a diffserv bit value. Fine, but let's
not put the proverbial cart before the horse.

First, we need to define what the diffserv bit semantics will
be so that when I send traffic from my administrative domain
to your administrative domain, the bit values are interpreted
as meaning the same thing to both of us. I believe this is the
initial diffserv challenge.

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

If a diffserv working group is created, we need to consider this, of course.
We shouldn't mandate it. We should allow it, yes, and define how it will be
done.

First and foremost, however, we need to define bit semantics, i.e. drop
preference and/or delay indication.

- paul

ps. Hey. What happened to that proposed framework document?  ;-)

---

From: Roch Guerin <[email-masked]>
Date: Tue, 23 Dec 97 07:57:21 -0500

Paul, 

>configuration would not be a concern.

I think that what you describe is a perfectly valid and natural first
step given where things are in most networks.  Furthermore, upgrading
infrastructure being a slow process it is clearly desirable to provide
incremental solutions.  On the other hand, you don't want to paint yourself
in a corner and define a solution that will let you take that first step, but
will have difficulties addressing new services later on.  I think that this
is the gist of the debate we are having.  If you assume that you wont need
explicit reservations, then I agree that this will suffice.  However, I
personally don't think this will be the case.  If you are a CIO and your
bonus and your job depend on meeting some very specific expectations, you
will want to make sure that the service provider you select and negotiate
a contract with does not get you fired.  And that is likely to mean something 
quite different from getting a "better than best effort" service (or whatever 
the appropriate semantic is).

This being said, I entirely agree with the need to take a first step that
is as unencumbered as possible, and I also agree that the main requirement
is to 
  >define what the diffserv bit semantics will
The only thing I am asking is that as these semantics are defined, we keep in
mind that we will most likely want to use them (later) to support other finer 
granularity and/or more explicit services, such as those that Int-Serv and
RSVP enable.  In other words, be able to do things such as what you describe
as
  >If a service provider desires his downstream subscribers use RSVP to

Roch

---

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

At 07:57 AM 12/23/97 -0500, Roch Guerin wrote:

>incremental solutions.

I'm glad we agree on this.  ;-)

>  On the other hand, you don't want to paint yourself
>is the gist of the debate we are having.

I'm not sure I agree with your point here, but I'll play along.

>  If you assume that you wont need

I would submit that it is not within the scope of diffserv to provide these
types of 'hard' levels of QoS.

Furthermore, CIO's already have mechanisms to beat service providers over
the head with -- it's called a SLA (service level agreement). There are
simply some things that you cannot devise a protocol to handle.

As an aside, I think we need to refine this discussion to clarify
what environment we are discussing here. I think there are at least a
couple of distinctions -- the Internet (proper), a corporate network
that has outsourced it's remote office connectivity to a particular
third-party service provider (I guess you'd either call this an
'Intranet' or a form of VPN), or an altogether private network.

Not intentionally meaning to play devil's advocate here, but I
personally don't believe that 'hard' QoS such as you allude
is possible in the Internet (proper), at least for the foreseeable
future. Call me a heretic. I do believe, however, that varying levels
of best effort is indeed possible, and I also believe that this is
what we are trying to accomplish with the confines of diffserv. I
am under no illusion that there is a perfect solution lurking out
there somewhere, just waiting to be discovered -- this is going to
be a matter of compromise on everyone's behalf, the Internet
community at-large included. Compromises are sometimes hard to
swallow.

Now, having said that, the latter two categories that I mentioned above
(there are probably a couple of other examples, but these will do for
now) are cases where 'more firm' QoS distinction is possible due to the
fact that the administrative scope is fairly narrow and controllable, and
I would suggest that if 'more firm' QoS is desired in these cases, then
the intserv mechanisms, to include end-to-end RSVP, is more appropriate.

>  >initial diffserv challenge.

Agreed.

>  >all of his downstream subscribers speak RSVP, cool.

Cool. I think we agree (?).

- paul

---

From: Roch Guerin <[email-masked]>
Date: Wed, 24 Dec 97 07:54:31 -0500

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: Paul Ferguson <[email-masked]>
Date: Fri, 26 Dec 1997 08:20:42 -0500

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.

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

- paul