Subject: RSVP Admission Control issue

From: "Fabrizio Salvatore" <[email-masked]>
Date: Wed, 15 Sep 1999 18:27:58 +0200

Hello!
In rsvpd/linux/tc_linux.c we find in function "is_admission_strategy" the
following lines:

f->ai.peakrate = f->policer.rate.rate +
		(double)f->policer.burst / f->qi->ai.time_const;
	if (f->policer.peakrate.rate) {
		int prate = f->policer.peakrate.rate +
			(double)f->policer.mtu / f->qi->ai.time_const;
		if (prate < f->ai.peakrate)
			f->ai.peakrate = prate;
	}

It seems that "f->ai.peakrate" is the rate on which Adm.Ctrl. in the CLS
case is based.
So, according to S.Floyd's paper, it should be the Token Bucket peakrate
from the FlowSpec object.
It seems to us that the condition "prate < f->ai.peakrate" is almost never
verified in practice, so the Adm. Ctrl. value is always the average rate. Is
it correct? Any comment is welcome.
Thanks in advance for your patience.
Fabrizio

--
Fabrizio Salvatore
CoRiTeL  http://www.coritel.it  MAILTO:[email-masked]
tel.: +39 06 20410040   ICQ number: 28879275   :-)

---

From: [email-masked]
Date: Wed, 15 Sep 1999 21:08:37 +0400 (MSK DST)

Hello!

> it correct? Any comment is welcome.

In practice peakrate in Tspecs is never set. (Just because not real-time
OSes are not able to hold finite peak rate at sender side, it requires
good OS latency).

But if sender really specified a peakrate it allows to get
better estimate for necessary buffer space and we have no reasons
to omit this information.

Alexey

---

From: [email-masked]
Date: Thu, 16 Sep 1999 21:09:47 +0400 (MSK DST)

Hello!

> The observation is that, even if the sender specifies a peakrate, the
> "f->ai.peakrate" remains unchanged (i.e. it contains anyway the average rate, even
> if a peakrate value is provided). To update the value in "f->ai.peakrate" we
> should probably change the condition from "if (prate < f->ai.peakrate)" to "if
> (prate > f->ai.peakrate)". Is this right, or am I misunderstanding something ?

Peakrate and rate of doubly leaky bucket is not real rate yet.

Real rate measured over time inteval T is:

r_real = min(r+b/T, p+M/T)

Cited chunk of code calculates exactly this value.

For small sampling interval peak rate gives better estimate,
but it is not always true.

Alexey

---

From: Roberto Mameli <[email-masked]>
Date: Thu, 16 Sep 1999 09:45:33 +0200

> to omit this information.

Yes, I agree with you. If the sender specifies a peakrate then we have to use this
information for better buffer allocation.
The observation is that, even if the sender specifies a peakrate, the
"f->ai.peakrate" remains unchanged (i.e. it contains anyway the average rate, even
if a peakrate value is provided). To update the value in "f->ai.peakrate" we
should probably change the condition from "if (prate < f->ai.peakrate)" to "if
(prate > f->ai.peakrate)". Is this right, or am I misunderstanding something ?

Regards
Roberto

--
Roberto Mameli
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni

EMAIL : [email-masked]   URL     : http://www.coritel.it
TEL   : +39-06-20410038     ADDRESS : Via di Tor Vergata, 135
FAX   : +39-06-20410037               00133 Roma - ITALY