Subject: [Diffserv] Questions regarding PDBs

From: "Mohamed El Gendy" <[email-masked]>
Date: Sun, 13 May 2001 00:56:30 +0300

Hello,

I have two questions to the list on PDBs:

1. Assume that two microflows f1, f2 are crossing two consecutive DS domains 
and assume also that f1 and f2 were within the same traffic aggregate in the 
first domain and handled by the same PDB. Now, how can I classify packets 
from these flows at the edge between the two domains to be handled by 
different PDBs in the second domain?
The reason for two different PDBs in the second domain is different QoS 
requirements for both flows in the second domain. Assume also they have the 
same egress point in the second domain not to have differences in routing to 
destinations.

2. It has been mentioned in the draft-ietf-diffserv-pdb-def-03.txt, section 
4.2, fourth paragraph, that multiple PDBs may use on the same PHB, yet 
should provide same transit performance for their traffic aggregates.
Does this include the case of two PDBs running on the same PHB with the same 
attributes, but differ in Ingress/Egress nodes? Will they be considered one 
PDB or two different PDBs?
What about the classification requirements at the edge if these two 
"identical" PDBs share the same Ingress node?

I appreciate your answer.

Best regards.

--
Mohamed El Gendy
----------------
University of Michigan, Ann Arbor
Ph.D. student, GSRA, RTCL Laboratory, EECS-CSE
Home Tel.:      (734) 665-2347
Office Tel.:    (734) 763-5363
E-mails:        [email-masked]
                [email-masked]
Homepage:       http://www.eecs.umich.edu/~mgendy

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2001 11:17:38 -0500

> different PDBs in the second domain?

If you run an MF classifier at the ingress to the second domain, then 
it can classify f1 and f2 differently. Of course, by definition a BA
classifier cannot distinguish f1 from f2. 

> "identical" PDBs share the same Ingress node?

Firstly please refer to RFC 3086 which is the final document. Secondly the
text does not say "should", it says "the transit performance of traffic aggregates of
these PDBs will, of necessity, be the same." This is a mathematical fact - if two
PDBs are handled by the same PHB, by definition they share the properties of
that PHB and they will (statistically) see the same performance. The fact that
the two PDBs happen to be created by different classifiers doesn't affect that;
it's as if you have a blue PDB and a yellow PDB that are identical in every
way but the color. Viewed that way, whether they share ingresses or egresses
makes no difference.

It's another question whether more than one PDB per PHB is useful; that's
an operational choice.

Regards

   Brian

---

From: Mariano Korman <[email-masked]>
Date: Mon, 14 May 2001 19:08:29 +0300

A simple question regarding the AF PHB.

The corresponding RFC (sorry, I don't remember its number) indicates
that there should be 4 AF classes with 3 drop priorities each.

It has been recently posted here that this means 4 different "automata"
running an AF algorithm (maybe with different parameters).

My question is "why four?". Is there any logical explanation of why "4"
was chosen as the numer of AF classes to be implemented? (The RFC
mandates that if a router is to implement AF behaviour, it should
include al 4 classes and 3 DP's). And, of course, "why three?". Why 3
DP's in each class and not two or four?

Regards,

	Mariano

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2001 13:01:02 -0500

Mariano,

Four classes simply seemed to match what various ISPs thought they needed.
However, it is entirely consistent with RFC 2957 to configure
fewer or more than 4 AF classes; that is the main reason why DSCPs are
mapped rather than being fixed.

  Brian