Subject: RE: Bandwidth Brokers

From: Yoram Bernet <[email-masked]>
Date: Mon, 22 Dec 1997 10:33:02 -0800

Let me jump in here, partly in response to Paul' sstatements, partly in
response to the thread in general. Paul questioned the wisdom in adhering to
the intserv model (it seems he specifically tuned in to my use fo the term
'filterspec'). Roch questioned the wisdom in "inconsistency", which I take
to be, to some degree, a recommendation to salvage what is possible form the
intserv work (maybe i misinterpreted). 

My opinion is that the intserv model was developed over time, by consensus,
by a group of smart people, and that we should try and maintain it, and
apply it to the diff-serv work, to the dgree that makes sense. In
particular, the diff-serv work does talk about offering services to users,
and the intserv flowspec carries a service type. It may very well be that
controlled load and guaranteed are not the right services to offer. If so -
that's fine, but that does not break the intserv model - rather - it means
that we need to define some new services, within the intserv model. 

Other information carried in the intserv flowspec, include the token bucket
parameters. The token bucket parameters will likely continue to be useful,
so - here again - we can continue to use this aspect of intserv.

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?

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.

Yoram

> -----Original Message-----
> From:	Juha Heinanen [SMTP:[email-masked]]
> Sent:	Monday, December 22, 1997 9:46 AM
> To:	[email-masked]
> Cc:	[email-masked]; Yoram Bernet; [email-masked];
> [email-masked]
> Subject:	Re: Bandwidth Brokers
> 
> 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 14:07:52 -0500

Yoram,
Pretty much agree with all what you say.  Specifically,

[snip]
>Roch questioned the wisdom in "inconsistency", which I take

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.

>that we need to define some new services, within the intserv model.

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.

>so - here again - we can continue to use this aspect of intserv.

Definitely, unless someone can explain why this is the wrong set of parameters.

>we not continue to use the same notion of filterpsec to define patterns for

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

>with the service type and the token bucket model.

To this I would probably add support/mapping for intserv services in the 
diffserv framework.

Roch

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 22 Dec 1997 21:47:13 +0200

>with the service type and the token bucket model.

i don't like at all the controlled load as a service type and definitely
don't want to support that in my network nor to constraint my diff-serv
profiles to those defined by int-serv.  the isps should be given the
freedom to define their own profiles.  it has been the assumption on
this mailing list from the very beginning that the profiles are not to
be standardized and i don't like to change that.  it is enough that the
semantics of the bits in the packet header are agreed upon.

-- juha

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 22 Dec 1997 14:52:07 -0500

At 09:47 PM 12/22/97 +0200, Juha Heinanen wrote:

> it is enough that the

Ditto (at least for now).

Baby steps,

- paul

---

From: Ping Pan <[email-masked]>
Date: Mon, 22 Dec 1997 14:54:58 -0500

Yoram Bernet wrote:
> It may very well be that

Agree 100%. In addition, I feel that many IntServ works, such as OPWA
(may need to collect different set of parameters now), will still be
useful in the context of DiffServ. In the last IETF, John Wroclawski
mentioned that we need a framework document. Why don't we have that
first? 

- Ping Pan

---

From: David Black <[email-masked]>
Date: Mon, 22 Dec 1997 18:43:03 -0500

I mostly agree with Paul and Juha.  In terms of the things we need to do to
make progress, specifying the protocol that a host uses to talk to the edge or
ingress router that does packet marking and the protocols used among
network providers to coordinate marking and treatment of marked packets
are way down the list.  IMHO, mapping of CL and GS to diffserv is putting
the cart before the horse, and hence should be out of scope for now.

-- Protocol to talk to router, and bandwidth broker protocols --

I think many of the initial deployments of diffserv can and will be
sufficiently coarse grained (e.g., all traffic to this site, all connections
initiated by this host, VPN link) that these protocols do not have to be
specified initially. For the sake of argument, I believe that carrier pigeons
(or more realisticly manual configuration techniques) suffice to get started.

When we get the fundamental diffserv issues under control, THEN I think
this is an important area to get to, but there are some non-obvious issues in
here.  For example, intserv, clearly required standardization of service
identifiers and services due to the end to end setup paradigm.  That argument
does not apply to diffserv, plus there's a strong difference of opinion about
whether services should be standardized (vs. mechanisms and bits).  I used
to think that it was obvious that we needed to standardize services, and
since then the folks from MIT and MCI (among others) have convinced me
otherwise.

In particular, Yoram's assertion that we need a standard set of service types
like intserv's is no longer obvious to me.  The beginnings of a counterexample
is that videoconferencing equipment is variable bandwidth, and our long
distance carrier allows us to select the bandwidth for an individual call via a
dialling prefix in 128k chunks.  I don't know whether those dialling prefixes
are standardized, but not only do I not have to care, the manufacturer of the
equipment doesn't have to care either -- as long as I dial the prefix that my
long distance carrier understands (bilateral arrangement between me and the
carrier) everything works, and if I change carriers, I just have to enter the
new carrier's prefixes into the equipment.

-- Mapping of CL and GS services --

I think this should be out of scope initially because I think issues of how to
map CL and GS (especially CL) should have little to no bearing on the
definition of diffserv.  We have some clues about what mechanisms can be used to
build diffserv and how they might go together, and if the result of this line
of thinking leads to a situation where GS and/or CL can't be mapped, that's too
bad.  Insisting up front that CL and GS must be mappable would be wrong -- I
have no problems with an after the fact effort to map CL and GS as long as
we understand up front that such an effort may come to the conclusion that
not all of the services can be mapped all or the time (or even ever).

-- What's left --

Even with all of the above, I agree with Roch and Yoram that there's no point
in reinventing wheels because we didn't like the car they were on last time.
In particular, IF we find ourselves needing concepts of filterspecs and
flowspecs in diffserv, THEN we should look to the work done on these topics
in intserv as an obvious starting point.

--David

============================================================================
David L. Black            THE OPEN GROUP     Voice: +1 (617) 621-7347
The Open Group                                 Fax: +1 (617) 621-8696
Eleven Cambridge Center      RESEARCH       E-Mail: [email-masked]
Cambridge, MA  02142        INSTITUTE         http://www.opengroup.org/~dlb/
============================================================================

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 23 Dec 1997 19:47:35 -0500

>new carrier's prefixes into the equipment.

Yes, and part of the measuring stick that you (the subscriber) use to
measure the service quality that you have contracted the service
provider for is whether he is successful in negotiating similar
agreements with his peers.

The entire argument on whether diffserv is successful in the Internet
rests on a couple of fundamental assumptions. One, that we manage
to come up with a 'standard' semantical way to express service levels
(bit semantics) for inter-domain traffic exchange. Second (and this one
is a real kicker), is that the relative success or failure of the
whole diffserv deployment is similar in concept to the PGP 'web of trust'
model -- one weak link (an administrative domain in the traffic path
which does not honor the diffserv semantics) screws the pooch. Thus, it
behooves service providers to be semi-cooperative in the name of
economic returns.

>not all of the services can be mapped all or the time (or even ever).

Completely agree.

>in reinventing wheels because we didn't like the car they were on last time.

Completely agree here, too, but let's put the shoe on the other foot for
a moment. By reinventing the wheel, one could also suggest that ensuring
that  diffserv mechanisms be explicitly 'interoperable' with  all possible
intserv mechanisms from Day 1 (tm) would be detrimental to diffserv
deployability.

>in intserv as an obvious starting point.

I can live with that, although I'm a loooong way from being convinced
that we need either. I'm trying to stay away from per-flow semantics,
until such a time that they just plop into my lap.

Cheers,

- paul

---

From: Steven Berson <[email-masked]>
Date: Tue, 23 Dec 1997 17:55:13 -0800 (PST)

On Tue, 23 Dec 1997, Paul Ferguson wrote:

[ ... omitted ... ]

> behooves service providers to be semi-cooperative in the name of

The idea that "a 'standard' semantical way to express service levels
(bit semantics) for inter-domain traffic exchange" is fundamental, is
laughable.  One (better IMO) alternative is to leave how to provide
services as an intra-domain issue.  Some bits in the header could be
used to signal these services, but the bits would only have local (and
not standardized end-to-end) significance.  Agreements between
providers (and deployed at the exchange points) would allow end-to-end
services.

If it is necessary to standardize anything (which I question), then it
should be the services, and not the bits.

Steve

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 23 Dec 1997 21:09:31 -0500

>should be the services, and not the bits.

Laughable? Really.

Otherwise, I guess we'll just have to agree to disagree.

- paul

---

From: Steven Berson <[email-masked]>
Date: Tue, 23 Dec 1997 19:04:28 -0800 (PST)

> Otherwise, I guess we'll just have to agree to disagree.

Let's be clear on exactly what is being said.  You claim that standard
bit semantics is fundamental to inter-domain service.  I claim that
inter-domain service can be achieved by (among possibly many other
ways) having agreements between providers at exchange points.  If my
claim is correct, then standard bit semantics is not fundamental.  I
hope we agree up to this point.

I further say that it is a better idea to have no global bit semantics
for inter-domain service, but rather to have local bits if needed (or
desired).  This point is subject to debate.

In summary (for inter-domain service) - 

    Global bit semantics is fundamental == false

    Global bit semantics is a good idea == maybe, but I don't think so

Steve

---

From: Geoff Huston <[email-masked]>
Date: Fri, 26 Dec 1997 11:37:12 +1100

>laughable.  

This line of argument  is soooo susceptible to a reduction into absurdity:

ie:
So I assume from your words that the idea that "a 'standard' semantical
way to express the destination address for inter-domain traffic exchange"
is fundamental, is laughable? 

and taking it further:
Or indeed that the concept of standard semantics for all fields in a
packet header is also laughable? 

So lets all define private semantics for the entire packet headers and then
attempt to translate them at the edges into some other non-local
significance whch bears some vague semantic relationship to the
next hop network's service profile?

Of course it won't work, but we all will have the satisfaction
of ensuring that our private sandboxes remain well and truly
isolate from each other.

>should be the services, and not the bits.

I just do not comprehend how the approach you appear to be advocating
leads to anything other than operational chaos.

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: Steven Berson <[email-masked]>
Date: Fri, 26 Dec 1997 13:46:13 -0800 (PST)

> This line of argument  is soooo susceptible to a reduction into absurdity:

[ ... series of examples of the useful role of standards, but avoiding
      the issue of what is and is not fundamental ... ]

>   Geoff

Geoff,

My article is also susceptible to any number of non sequiturs.
Anyway, as I explained in my follow-up, the key word is fundamental.
If you believe that bit semantics is FUNDAMENTAL to inter-domain QoS,
go ahead and make a case (as I have yet to see anybody do).  If bit
semantics is not fundamental, then it is important to consider
alternative approaches.  So far, the bulk of the discussion has mostly
been that since bit semantics is fundamental, we only need to tell
people how many drop bits and how many delay bits, and then we are
done.  I think that is very short-sighted.

Cheers,
Steve

---

From: Scott W Brim <[email-masked]>
Date: Tue, 30 Dec 1997 14:40:01 -0500

>    Global bit semantics is a good idea == maybe, but I don't think so

Steve & Paul, are you two using the same semantics for "semantics"?  There
is a minimum level of globalness of the semantics which is fundamental.  It
is possible for everyone to agree on relative ordering of the treatment of
packets, along interesting dimensions, without necessarily agreeing on how
the traffic will actually be treated.  For example, if we have delay
priority bits, we must agree on which delay priority will experience less
delay (less or equal), but we don't necessarily have to agree on anything
more than that.  As usual, semantics != mechanism.

...Scott

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 30 Dec 1997 14:52:33 -0500

At 02:40 PM 12/30/97 -0500, Scott W Brim wrote:

>[...] For example, if we have delay

Yes, completely agree with all of the above. Thus, semantics are
indeed fundamental.

- paul