Subject: C, D terms of GS

From: "Navin kumar Agrawal" <[email-masked]>
Date: Fri, 01 Oct 1999 17:15:08 +0530

Hi,

I am implementing Guranteed Services. Want to know about the
factors which influence the selection of value for the C and D
terms.

I am aware of the fact that these parameters depend heavily on the
link layer media, subnet topology, scheduling.

In my case, the link layer media is Ethernet but the it is not used in
the
conventional shared media form. Meaning, it is used in the
point-to-point
form. So I guess, there is no need to implement SBM. Please correct me
if
this statement is wrong.

My packet scheduling is simple round robin. This scheduler will
schedule maximum of the allocated bytes from a reservation class per
time slice. My time slice is of T  micro sec time.

Also, what is difference between Ctot (or Dtot) and Csum (or Dsum) from
the sender node, intermediate node and receiver node point of view?

Comment in any form will be highly appreciated.

Thanks in advance,

Regards,
Navin

---

From: Roch Guerin <[email-masked]>
Date: Fri, 01 Oct 1999 11:14:25 -0400

> time slice. My time slice is of T  micro sec time.

Your D term should depend on MTU and link speed plus any fixed
processing time.
Your C term will be a function of how you configure your wrr scheduler,
and the max number of flows you can accommodate.  Actually, from what
you describe, you probably can fold most of that into the D term as you
wont be able to control much of it through the rate of an individual
connection.

> the sender node, intermediate node and receiver node point of view?

There is quite a bit of discussion on this in rfc2212.
Sender does not know either.  Difference between the *tot and *sum terms
is that the first are for the entire path, the second are since the last
reshaping point, i.e., they are reset to 0 at each node on the path that
reshapes the traffic.  Knowing the latter is useful in that it allows a
smaller buffer bound.  Again, this is described in rfc2212.

Roch

---

From: "Navin kumar Agrawal" <[email-masked]>
Date: Sat, 02 Oct 1999 19:37:08 +0530

Hello Roch and David,

Thanks for your reply. It has clarified many doubts of mine.

However, I still have few more doubts in the context of IntServ
service classes. Is it possible for you to throw some light on it?

1. In case of GS, When the end receiver application program
receives Adspec object, How it calculates the parameter R?

As per my understanding, the application might be aware of the
maximum value of the data packet delay....depending on its memory
availability. Suppose this delay is DELAY. Also let the received total
C and D terms are Ctot and Dtot respectively.

In this case, as specified in RFC2212,  R can be calculated as

R = (DELAY - Dtot)/(Ctot + b)

This is a conservative estimate. Also the peak rate (p) is not taken in to
consideration.

Is this understanding correct?

2. In case of CLS, how does the receiver decides value of
Receiver TSpec parameter r? Would it be same as the r parameter
of the Sender TSpec?

For that matter, Would the Receiver TSpec be exactly same as
Sender TSpec?

If Receiver TSpec is same as Sender TSpec. Would not the value r
of Receiver TSpec only be used for making reservation on a network
element?

Is this understanding correct?

3. As discussed above in point 1 and 2, it looks the only difference
between GS and CLS is that in case of GS the bandwidth to be reserved
is estimated based on the some info...whereas in case of CLS there is no
estimation...

So from the implementation point of view, a network element, which
supports both kind of services i.e. CLS and GS, the difference in
implementation would differ only in the amount of bandwidth to reserve.

Begin
  If ( qos class is CLS)
  {
      req_bw = r
   }
   Else if (qos class is GS)
   {
       req_bw = R
    }
    reserve_bw (req_bw)
End

In my opinion, this would be the only difference in the implementation of
GS and CLS (Here the Slack term is being neglected and also the updating
of Adspec object is not taken up).

Is this understanding correct?

Sorry for this long mail.

Regards,
Navin