Subject: RE: Bandwidth Brokers

From: Paul Ferguson <[email-masked]>
Date: Fri, 19 Dec 1997 14:30:06 -0500

At 08:22 AM 12/19/97 -0800, Yoram Bernet wrote:

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

You know, I get this nagging feeling that we are talking past one
another on this issue, and this is also another example of why I
think a separate working group should be chartered to handle the
diffserv work -- I keep hearing you use the reference 'filterspec'
which implies (to me, anyway) that you are determined to factor
in the intserv semantics and message formats into diffserv from
Day 1. Spinning the diffserv work off into a separate working
group would, at the least, provide the distinction that this
work need not be tied to intserv fundamentals (whether it is or
not, in the end, is another matter entirely).

Again, I'd like to clarify that I do not think this is
such a bad idea in the long term, but making assumptions
that people will, or will not, use intserv semantics and
RSVP to signal differential services is beyond the scope
of the charter, methinks. (If we determine that this might
be one of the mechanisms which is useful, then fine, but
there are certainly other ways to provide packet marking.)

Instead of addressing the other issues in your e-mail
(which were elided for brevity), I'm very much in favor
of asking the IESG to consider spinning this work into
a separate working group for several reasons.

First, vendor implementations & product plans are all
well and good, but should not drive working group priorities
based on this fact -- these should be based on the technical
merit of the particular proposal.

Secondly, I do not agree that diffserv *must* be based on
prior intserv fundamentals.

I could on and on with reasons, but I'll stop here since
I wanted to make at least one more opinionated comment on
something you mentioned earlier (paraphrasing) concerning
thousands of users desiring to signal the edge router for
differential services.

Worst case: each users has different service levels, requiring
individual considerations at the edge router. Scales linearly
with the number of users (considerations).

Best case(s): traffic can be classified by transport layer
identifiers (tcp or udp port, or perhaps even IP protocol number)
at the edge router, requiring very few considerations. Or, only
a few individual users need individual considerations, in addition
to transport layer classification. Scales linearly with the number
of considerations.

Somewhere in between: Combination of all things above, to some degree.
Scales linearly with the number of considerations.

Again, I'm not trying to poo-poo the idea of using RSVP to signal
an edge device to classify diffserv considerations for user traffic.
Insofar as convenience is concerned, I think this sounds great. On
the other hand, a diffserv implementation that *requires* this in
the short term is, in my opinion, not in the best interest of getting
a workable solution deployed tomorrow.

End of soapbox mode.

- paul

---

From: Roch Guerin <[email-masked]>
Date: Mon, 22 Dec 97 09:00:30 -0500

Paul,
A couple of quick comments regarding some of the points you make.

>there are certainly other ways to provide packet marking.)

I agree that there are a number of *new* issues that the diffserv
work needs to address and that were not part of the intserv charter.
However, I also believe it is important to try to maintain some 
form of consistency from the beginning.  If we don't do that,
it is a safe bet that we'll end-up with inconsistent (incompatible)
solutions.  If you believe that the intserv semantics and approaches 
are wrong or not useful, then it is not a problem, but I don't think 
you do (at least, I haven't heard you say that) and then chartering
a separate working group is likely to make it more difficult to 
ensure compatibility.  So, I'm personally not really in favor of a
new working group.

Roch

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 22 Dec 1997 19:45:44 +0200

roch,

what do you mean with "solutions inconsistent with int-serv"?  for
example, are you suggesting that the profiles isps define whould be
compatible with controlled load, guaranteed, etc. int-serv defined
services?

you remember when i tried to introduce a new service called protected
best effort?  if i remember correctly, it was killed by the int-serv
gurus because its semantics for best effort traffic was not consistent
with control load's best effort traffic.

i still feel that protected best effort makes much more sense than
int-serv controlled load and in fact would be a perfect fit with the
diff-serv's model of in and out of profile traffic.  so as a diff-serv
profile i would be delighted to junk controlled load in favor of
protected best effort and i should have a freedom to do so.

-- juha

---

From: Roch Guerin <[email-masked]>
Date: Mon, 22 Dec 97 13:18:21 -0500

Juha,

>compatible with controlled load, guaranteed, etc. int-serv defined

What I mean by that is that I would like the intserv and diffserv services
to be able to coexist.  That means that we should try to incorporate 
the ability to support intserv flows across networks that only provide the
potentially coarser mechanism that diffserv requires.  For example, this 
may mean having a queue (set of TOS bits) that can be mapped to CL or GS
flows in backbone routers that do not support per flow classification.

>with control load's best effort traffic.

I do remember the PBE draft.  I think it happened a little before the Committed
Rate we submitted and which also got "deferred".  I think the reasoning put
forward at the time was that the CL specs could be viewed as allowing things
with a similar flavor, and before introducing new services it was decided (in
Montreal, if I recall correctly) to gain experience with the two service that 
had been proposed, so that their shortcomings could be identified and used 
when defining the next round of services.

>protected best effort and i should have a freedom to do so.

I think that's perfectly fine and certainly did not mean to imply that this
should be precluded in the name of consistency with intserv.  Again, what I'd
like to avoid is that we have two completely separate tracks as I think they
each represent a subset of the overall requirements that need to be supported.
Therefore, I'd much rather spend some time up front to make sure they can
interoperate, rather spend much more time later fixing things.

Roch

---

From: Geoff Huston <[email-masked]>
Date: Tue, 23 Dec 1997 07:45:59 +1100

In a followup to Roch's email arguing in favour of continuation
of the int-serve WG and charter in developing diff-serv
mechanisms, I'd like to argue the counter case.

I'm not sure that we should 'for the sake of consistency" adopt
a priori the intserv structures associated with the RSVP
approach within the diff serv architecture.

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. For such a adoption community the
inherant scale problems of RSVP (RSVP aggregation
notwthstanding)  are an effective nbarrier to adoption.

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.

regards,

   Geoff Huston

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