Subject: Re: Peak rate parameter [p] in Tspec handling rule.

From: [email-masked]
Date: Thu, 30 Jul 1998 13:51:09 +0900

> Date: Thu, 30 Jul 1998 12:24:02 +0900
> From: Ping Pan <[email-masked]>

> > I would like to reinforce my understanding about [p] parameter in Tspec.
> > According to relating RFC documents(*1), legal range of [p] must be
> > "0 < p < 40 (Tera byte)" or "Positive Infinity".
> > 
> >         (*1) RFC2210, RFC2211, RFC2212
...

> During flow merging, I remember the default rule is:
> 
> 1. Receiver-spec = LUB(Resv-flowspec-1, Resv-flowspec-2)
> 2. Sender-spec = Sum(Path-Tspec-1, Path-Tspec-2)
> 3. Final-merged-flowspec = GLB(Receiver-spec, Sender-spec)

Ping,

Thanks for your quick response.
Yes, I'm fully aware of above rules, though I have forgotten to
list up RFC2205 here.

> Just curious, why do you care about "positive infinity" or bandwidth in
> the range of TeraByte/sec for peak rate? :-)

Well, my main concern is not

    "Peak rate may exceed TByte/sec order or not",

but

    "Any network elements can set [p] parameter of Tspec to infinity,
     if unknown or no better value is available, even though the real
     figure may at most 2MByte/sec (or even 300bps) or so".

That is, as long as [p] can be infinity, we should always be aware of
this special case, no matter what the handling service will use this
value or not. Upperbound value has no significance here.

Okay, let's think again by Ping's scheme, assuming exactly the same
arithmetic rule for [p] calculation is applied.
Here also assumes that controlled load service is specified.

CASE.1 (comparison)
--------------------

       Flowspec(cl).Tspec.p = 2e6   Flowspec(cl).Tspec.p = Infinity
                               |                 |
                               V                 V
> 1. Receiver-spec = LUB(Resv-flowspec-1, Resv-flowspec-2)

     ===> Receiver-flospec.tspec.p = Infinity?

                  Tspec.p = 1.5e6   Tspec.p = 3e7
                          |                 |
                          V                 V
> 2. Sender-spec = Sum(Path-Tspec-1, Path-Tspec-2)

     ===> Sender-spec.tspec.p = 3.15e7   (Quite simple :-)

                                  Infinity?       3.15e7
                                      |             |
                                      V             V
> 3. Final-merged-flowspec = GLB(Receiver-spec, Sender-spec)

     ===> Final-merged-flospec(cl).tspec.p = 3.15e7 (this should be 2e6)

CASE.2 (summation)
------------------

       Flowspec(cl).Tspec.p = 1.5e6   Flowspec(cl).Tspec.p = 3e7
                               |                 |
                               V                 V
> 1. Receiver-spec = LUB(Resv-flowspec-1, Resv-flowspec-2)

     ===> Receiver-flospec.tspec.p = 3e7

                  Tspec.p = 2e6     Tspec.p = Infinity
                          |                 |
                          V                 V
> 2. Sender-spec = Sum(Path-Tspec-1, Path-Tspec-2)

     ===> Sender-spec.tspec.p = Infinity?

                                     3e7        Infinity?
                                      |             |
                                      V             V
> 3. Final-merged-flowspec = GLB(Receiver-spec, Sender-spec)

     ===> Final-merged-flospec(cl).tspec.p = 3e7 (this should be 2e6)

Don't you feel this strange?
----------------------------------------------------------------------------
Masahiko ENDO / Surigiken Co.,Ltd.