Subject: RE: [Diffserv] BB and RSVP question

From: GARBISU Jean-Pierre FTRD/DMI/CAE <[email-masked]>
Date: Tue, 24 Oct 2000 17:00:20 +0200

Hi 
BB are not in the DiffServ WG's charter but I guess the question was more on
the IntServ/DiffServ capability of edge routers

To follow this question I have two comments regarding the PDB def draft :
. the abstract of the draft mentions that "A PDB is an expression of a
forwarding path treatment, but due to the role that particular choices of
edge and PHB configuration play in its resulting attributes, it is where the
forwarding path
and the control plane interact.". So one should still wonder how far the
control plane topics should be studied in DiffServ (e.g. for the definition
of future PDBs).

. § 4.4 of the draft mentions that "The edge rules might be reconfigured at
a few regular intervals during the day or might happen in response to
signalling decisions thousands of times a day.". It seems this statement is
related to the preceding question and once again how far should it be
considered in the definition of PDBs i.e what is the relathionship between
RSVP agregation and PDB building (cf. figure 2 of the PDB def draft )?

Best regards      

[email-masked] 

-----Message d'origine-----
De : Brian E Carpenter [mailto:[email-masked]]
Envoyé : lundi 23 octobre 2000 18:28
À : Mike Badil
Cc : [email-masked]
Objet : Re: [Diffserv] BB and RSVP question

Mike,

Bandwidth brokers are not in this WG's charter.

Regards
  Brian Carpenter
  diffserv co-chair

Mike Badil wrote:
> 
> Hi all,
> 
> I have read several diffserv paper which suggesting to use Bandwidth
Broker.
>   I have following question.
> 
> The papers says that:
> 
> RSVP or any other signaling protocol can be used in stub domain for
resource
> allocation. And BB allocate inter domain resource by communicating with
next
> doin BB. So far it is clear to me.
> 
> In transit domain they suggest again to use aggregated RSVP, I am not sure
> how aggregeted RSVP work here. BB in transit domain has Ingress router
> establish path trough Egress router. OK, it is fine, but when a packet
come
> to ingress router, how does the ingress router decide which aggregated
RSVP
> flow is packet belongs to. If it is destination adr.based,  that means the
> ingress router will keep all the state of flows in its forwarding table.
> Then it becomes scalibility problem exactlly as in RSVP. Because ingress
> router will keep millions of flows state in its table.
> 
> How this situation is handled.
> 
> Do they suggest to use tunnelling or what?
> 
> If any one answer it
> I will be very happy.
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Kathleen Nichols <[email-masked]>
Date: Tue, 24 Oct 2000 10:30:40 -0700

> RSVP agregation and PDB building (cf. figure 2 of the PDB def draft )?

The intent was to make it clear that we can *separate* the study of
the control plane and how the edge is configured from the mechanisms
we need in the edge and the forwarding path effects of a particular
configuration. Control Plane topics are specifially out of charter
for the Diffserv WG, but someone implementing differentiated services
in a network must configure in some fashion. As has been said in
RFCs, I-Ds, talks, and emails, we *expect* that would start out in
some static fashion (not unlike early routing) and then progress
to a more dynamic control if needed and once we learn from early
deployments. The notion is to design control functions from experiences
with "running code" not to try to decide, absent experience, what QoS
control should do and then define it in concrete and mix it up into
the forwarding path so it can't be changed. Another aspect we've been
trying to reflect is that different ISPs have different notions of QoS
and how they want to use it. This is not the time to design a one-size
fits
all control plane.

We are now in the "experimental" phase of differentiated services.

	Kathie

---

From: John Wroclawski <[email-masked]>
Date: Tue, 24 Oct 2000 20:28:32 -0400

Jean-Pierre,

At 5:00 PM +0200 10/24/00, GARBISU Jean-Pierre FTRD/DMI/CAE wrote:
>the abstract of the draft mentions that "A PDB is an expression of a
>forwarding path and the control plane interact.". So one should still wonder
>how far the control plane topics should be studied in DiffServ (e.g. for the
>definition of future PDBs).

To expand a bit on a point Kathie Nichols made earlier today - I 
think this question can be answered by invoking a couple of key 
assumptions of the diffserv philosophy. Sorry if this is restating 
the obvious..

diffserv assumptions:

1) it is possible to implement useful per-domain QoS behaviors simply 
by concatenating a string of per-hop behaviors that are operating 
correctly and within their stated traffic limits.

2) the fact that you will get the desired per-domain QoS when you 
concatenate a string of correctly operated PHB's is independent of 
how exactly you choose to do this.

Assumption one says a couple of things. One is that indeed there are 
likely to be some restrictions on how much traffic can be handled by 
a PHB, and you have to ensure that the rules are met somehow. The 
other is that the behavior of a PHB is purely local - it can't, for 
example, be expected to know how much delay is occurring at some 
other node in the net. This last point is important because it means 
that diffserv per-domain QoS cannot depend on, say, a signaling 
mechanism to carry information between PHB's.

The second assumption says that it doesn't matter _how_ you ensure 
that the PHB's are operating within their required limits - you can 
choose appropriately for your situation. If that means grossly 
overprovisioning the network with respect to the amount of EF or AF 
traffic you allow in, so that the per-hop operating rules are met 
statically and for any mix of destination addresses, then you will 
get the desired per-domain QoS statically and without having to worry 
about the traffic mix. If you instead want to more tightly allocate 
resources, and use a signaling mechanism to dynamically shuffle PHB 
capacity around to different traffic, you will obtain the same 
per-domain QoS behavior for the traffic that gets it, but the traffic 
that gets the behavior can be selected dynamically by destination, 
source, and/or whatever other selectors you pick. If you make this 
choice you will receive some benefits, but you will also add 
implementation and management complexity. Your choice.

To answer your question, it seems to me that the DiffServ WG is 
concerned with precisely those parts of the above story that don't 
change as different people make the different choices I described 
above. These include things like the behavior of PHB's, including 
restrictions and traffic limits; packet formats used to select a PHB; 
and perhaps, things like edge marking and policing functions that 
combine with PHB's to produce useful per-domain QoS, and even more 
perhaps, the definitions of some widely useful per-domain QoS's.

Conversely, stuff that different people might choose to do 
differently, like signaling or configuration management, is outside 
the scope of the group.

If in your question you meant not "the DiffServ WG" but "Diffserv in 
a larger sense", then, well, there are a lot of people trying 
different things in these areas now, and others that will do so in 
the future. It seems likely that at different points some of these 
things will show up in the IETF, though perhaps not in the DiffServ 
WG, for standardization. Others may stay proprietary or local, and 
others will just not work out so well. Without meaning to put words 
into their mouths, my impression is that it is the perspective of the 
WG chairs that this is exactly what should happen.

>RSVP agregation and PDB building (cf. figure 2 of the PDB def draft )?

Aggregated RSVP provides one way of managing traffic within a 
diffserv cloud. It can be reasonably dynamic and gives you 
destination-aware (per-path) management, and thus falls on the "more 
control, more complexity" side of the equation. Therefore, it may let 
you allocate more of your resources to high-QoS traffic, and more 
easily shift those resources between customers, but it creates some 
burdens in return. This is all about _who gets_ a PDB, not what the 
PDB is.

If you feel that the ISSLL WG documents on aggregated RSVP don't 
quite do the job for you, your comments would certainly be welcome - 
they're published RFC's already, but there is always a way to improve 
things if need be.

regards,
john