Hi Stefano,
I have been enjoying reading your draft, because I think it brings
the SLS discussion really forward. However, I would like to make the
following two comments and would welcome some discussions on these.
In the premium mission critical predefined SLS type, the darft
assumes that (page 12)
"applications are assumed to implement some kind of congestion
control mechanism whose aggressiveness is somewhat similar to
the one of TCP",
but you are also suggesting a double token bucket traffic
conformance testing on the peak rate and the sustainable rate.
Now, while both congestion control and the double token bucket
control make sense on their own separately, it would need to be
further specified how the two work together.
For instance, if it is oly the double token bucket that is used for
policing, and the congestion control is only used to inform the user
on the instantaneously available bandwidth in the network, then the
user has little incentive to stick to the congestion control
algorithm. This is because the network has no means to maintain
fairness between 2 users behaving differently; one who respects the
congestion control (like a TCP user would) and one that does not
(like UDP).
In fact, for similar reasons, ATM networks have introduced the
dynamic GCRA (dynamic token bucket) for the ABR service. The dynamic
token bucket combines the congestion control signal and the token
bucket parameters, thereby ensuring that the token bucket is always
adjusted to the currently available bandwidth in the network.
----
Another issue again, (I have raised it in connection with
the TEQUILA draft as well) is related to the service schedule
section, where the draft introduces (quite properly !) the notion of
start time, and end time along with the concept of admission control
(section 3.4), but there is no mention of the blocking probability,
which is needed in order to allow "effective admission control" and
network dimensioning. On the other hand a user needs to have at least
a rough indication on the expected blocking probability (we may call
it the Grade of Service).
-----
Hope these comments prove to be constructive.
Cheers /Gabor
>
> Date: Tue, 07 Nov 2000 18:07:42 +0100
> From: Stefano Salsano <salsano@coritel.it>
> X-Mailer: Mozilla 4.51 [en] (Win95; I)
> X-Accept-Language: en
> MIME-Version: 1.0
> To: sls@ist-tequila.org
> Subject: [tequila/sls] [Fwd: I-D ACTION:draft-salsano-aquila-sls-00.txt]
> Content-Type: multipart/mixed; boundary="------------661E921731681EB542C1DECA"
> Sender: owner-sls@ist-tequila.org
> Precedence: bulk
> Reply-To: sls@ist-tequila.org
> X-Lines: 137
> Status: RO
> Content-Length: 4442
>
> --------------661E921731681EB542C1DECA
> Content-Type: text/plain; charset="us-ascii"
> X-Sun-Content-Length: 584
>
> Dear all,
>
> here is another draft on SLSs:
> "Definition and usage of SLSs in the AQUILA consortium"
> it is a result of the work of the AQUILA IST project.
>
> It represents a positive feedback to the draft proposed
> by TEQUILA project. The approach followed by AQUILA consortium
> is described. The concept of "predefined SLS types" is
> proposed in order to simplify SLS usage.
>
> The draft is available both on IETF directory (see below)
> and on AQUILA URL http://www-st.inf.tu-dresden.de/aquila/
> (follow the link to standardization activity).
>
> Your comments are welcome !
>
> Best regards,
> Stefano
>
Gabor Fodor, PhD
Ericsson Research
Sweden
This archive was generated by hypermail 2b29 : Thu Nov 16 2000 - 23:30:05 CET