Subject: Re: [Diffserv] Assured Rate PDB

From: [email-masked]
Date: Sun, 7 Jan 2001 22:35:25 -0500 (EST)

>
>Given fairly long time intervals
>for rate measurement, it may be possible to assure a rate on a packet
>stream with delay and jitter, as long as the delay and jitter times are
>less than the measuring interval and the link speed is sufficient to accept
>the traffic.
>
>It would seem to be necessary to state some basic time relationships. I see
>that these are touched upon in section 7.0 Example Uses, but I am concerned
>that they should be stated up front and the scope or limitations of what is
>being proposed are explicit and well known.
>

Larry:

Are you saying that you would like jitter and delay values 
to be associated with the parameters that describe the PDB behaviour?
If so, we should acknowledge that aggregate behaviours based on 
the AF PHB have long been discussed soley in the context of 
assuring a rate. Your note is the first time I've seen any 
interest expressed in associating some sort of
delay and jitter with the rate for AF-based PDBs. 
The whole motivation behind the AR PDB is to provide
a service with statistical assurance - without worrying about
guarantees for time-scales on the order of a packet or two.

Of course, as you note, the rate would need to be 
associated with either a measurement time interval or bucket sizes.
The draft requires such a parameter to be specified along with the cir.
However, the draft does not constrain the particular parameter 
to be used as it will depend to some extent on the policer 
algorithm used in the edge routers for the domain.

Your note mentioned section 7 of the draft. Are you suggesting
that we flesh out that section in greater detail?

Regards,
Nabil Seddigh

_______________________________________________
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: Marcus Brunner <[email-masked]>
Date: Mon, 08 Jan 2001 15:17:25 +0100

Nabil,

I agree with Larry, that some kind of time relationship is needed. In
your draft, you basically left it to the traffic parameters. Isn't it
possible to have a time parameter, which is general enough to be used
with different mechanisms?

Marcus

-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155