Subject: Aggregating RSVP : the needs .

From: Arioli Carlo <[email-masked]>
Date: Mon, 19 Jan 1998 12:03:34 +0100

I' m  a student developing a project for my own degree thesys.
I've been studing so far RSVP problems and the proposed solutions.  I've
read many
papers  and found many interesting things ,especially in  the  articles
of
Mr. Berson , Mr. Guerin and Mr. Pan  : so I directly refer to these
people,
 but direct this mail to the mailing list also.
 I wanted to ask some question that, due to my lack of experience,
 I ' m not able to clear myself.

 In all the articles is mentioned RSVP scalability but there aren't any
number
  to support how much it could be.   I'd like to discuss a couple of
things and to ask
  Your  experienced opinion.

  1)  I do think that there's a scalability problem for sure . But
usually, this is an
   assumption that doesn't examine well wheter it is rsvp the cause or
the model
   of IIS  itself. In this sense Mr. Berson 's draft is quite
interesting and on the point.
   There it is stated that the problems will surely be with scheduler
and classifier.
   The solution is aggregation , but not only of  classifier state and
class of service
    for the scheduler  in a node , but also of rsvp state.   How did it
came out ?
    Did Mr. Berson consider the Rsvp problem  was real and decided that
it was better
    to aggregate also the protocol  basing this on data ?  Have you
considered
    the possiblity that the protocol, even if quite  resource intensive,
might be
    affordable for the net or you didn't even take this chance at the
beginning because
    there was already the need to aggregate the other two ( sched and
class. ),
    and so it was better to do it toghether with rsvp .
     ( I do understand that early tagging is really useful and necessary
for
       scheduling, but rsvp per flow state  would be necessary for
policing ?? )
      I do ask to Mr. Guerin also if  your experience on designing  an
RSVP
       router  has proved any practical number explainig  the need for
aggregation .

 2) rsvp problems.
     Surely it is clear that rsvp is really heavy, but how much heavy ?
      I mean, I do agree with what Mr. Pan says in many of  the RSVP
complexity
      issues in  His article about YESSIR  .   My problem is that I
need an idea of
      RSVP scalability in absolute , thta means just by itself and not
compared to other
      protocols.

         a)   Soft state quantities.  Mr. Pan reports soft state of
guaranteed reservation
           for a unicast FF session  being  about 580 bytes ( in an old
letter here ) .
            Doing more or less what also Mr. Guerin reports in his draft
, let's take it
           supposing to use an OC12  link  and to use all its bandwidth
( 620 Mbit /s) to
            reserve many 64 Kbit/s . This would mean  9700 flows ( more
or less)  and that
            would mean an amount of  soft state necessary   of  6 Mbytes
for EACH  oc12 link of
            the router.   Considering  a backbone router  ( and here we
are  talking about  620 Mbit
           links, not  small ones , so top routers) this quantity of
memory is  likely to be too much
           considering the  others things a router has to keep or not ?
Soft state is necessary
           to be kept at single interfaces of router or in the central
memory ?
           How big is this problem for you ? Unfortunately I ain't got
the experience you
            have in building routers , so for me there is no way to say
if it is a lot or no.
           I understand this is much more than normal routing,  but here
we are talking about
           reserving bandwidth for someone who is likely to contribute
economically to
           the net itself. Is is a matter of technology or economy ?

          b)   Still citing  Mr. Pan on an oc3 link of 155Mbit/s , there
would be ( still considering
          64 kbit/s flows )  an overhead of the portocol of  230
Kbit/sec .  I've done something similar
         and the results are more or less the same.
         This cannot be considered too much can it?

           c) the last problem reported is  complexity. Here no data
exists. What is Your personal
            feeling ?

 Thank you very much for the help and my best reagards to all of you,

 Carlo

  Ps.  Should any info stated above prove to be incorrect , I do
aplogize with the author and
   beg him to specify or correct it for clarity .

 --
---------------------------------------------------------
  Arioli Carlo                          Network systems

  Organization: Cefriel
  Phone:  +39-2-23954-243/260

  Mailto:[email-masked]        http://www.cefriel.it
---------------------------------------------------------

---

From: Steven Berson <[email-masked]>
Date: Wed, 21 Jan 1998 14:48:29 -0800 (PST)

On Mon, 19 Jan 1998, Arioli Carlo wrote:

[Note - I have reformatted Carlo's article for easier reading ... ]

Carlo,

> I' m a student developing a project for my own degree thesys.  I've
> been studing so far RSVP problems and the proposed solutions.  I've
> read many papers and found many interesting things ,especially in the
> articles of Mr. Berson , Mr. Guerin and Mr. Pan : so I directly refer
> to these people, but direct this mail to the mailing list also.  I
> wanted to ask some question that, due to my lack of experience, I'm
> not able to clear myself.

> number to support how much it could be.  I'd like to discuss a couple
> of things and to ask your experienced opinion.

> 1) I do think that there's a scalability problem for sure. But
> usually, this is an assumption that doesn't examine well wheter it is
> rsvp the cause or the model of IIS itself. In this sense Mr. Berson 's
> draft is quite interesting and on the point.  There it is stated that
> the problems will surely be with scheduler and classifier.  The
> solution is aggregation , but not only of classifier state and class
> of service for the scheduler in a node , but also of rsvp state.  How
> did it came out ?  Did Mr. Berson consider the Rsvp problem was real
> and decided that it was better to aggregate also the protocol basing
> this on data ?  Have you considered the possiblity that the protocol,
> even if quite resource intensive, might be affordable for the net or
> you didn't even take this chance at the beginning because there was
> already the need to aggregate the other two ( sched and class. ), and
> so it was better to do it toghether with rsvp .  (I do understand that
> early tagging is really useful and necessary for scheduling, but rsvp
> per flow state would be necessary for policing ?? ) I do ask to Mr.
> Guerin also if your experience on designing an RSVP router has proved
> any practical number explainig the need for aggregation.

I am actually not sure how big a problem aggregating RSVP state is.
In particular (as in the draft), I think it is worth it to keep
multicast RSVP state.  Unicast RSVP state gives you much less,
and more easily leads to aggregating.

> Surely it is clear that rsvp is really heavy, but how much heavy ?  I
> mean, I do agree with what Mr. Pan says in many of the RSVP complexity
> issues in His article about YESSIR. My problem is that I need an idea
> of RSVP scalability in absolute, thta means just by itself and not
> compared to other protocols.

> a) Soft state quantities.  Mr. Pan reports soft state of guaranteed
> reservation for a unicast FF session being about 580 bytes ( in an old
> letter here ) .  Doing more or less what also Mr. Guerin reports in
> his draft , let's take it supposing to use an OC12 link and to use all
> its bandwidth ( 620 Mbit /s) to reserve many 64 Kbit/s . This would
> mean 9700 flows ( more or less) and that would mean an amount of soft
> state necessary of 6 Mbytes for EACH oc12 link of the router.
> Considering a backbone router ( and here we are talking about 620 Mbit
> links, not small ones , so top routers) this quantity of memory is
> likely to be too much considering the others things a router has to
> keep or not ?  Soft state is necessary to be kept at single interfaces
> of router or in the central memory ?  How big is this problem for you
> ? Unfortunately I ain't got the experience you have in building
> routers , so for me there is no way to say if it is a lot or no.  I
> understand this is much more than normal routing, but here we are
> talking about reserving bandwidth for someone who is likely to
> contribute economically to the net itself. Is is a matter of
> technology or economy ?

Realistically speaking, 6MB of memory is not a lot of memory.
64MB of memory costs about $200, which is not very much compared
to the cost of a router with multiple OC12 interfaces.  And, unlike
classifier and scheduling state, RSVP state does not need to accessed
in the router fast path, so ordinary (rather than high speed cache)
memory can be used.

Steve