Subject: [NSIS] Comments on draft-sarikaya-nsis-wiredreqs-00.txt

From: Dave McDysan <[email-masked]>
Date: Thu, 13 Dec 2001 16:09:24 -0500

I have the following comments and suggestions on
draft-sarikaya-nsis-wiredreqs-00.txt.

Dave

3. General Requirements

First paragraph: I don't believe this is correct, and it is not stated as a
requirement anyway. Isn't RSVP a means for L3 signaling? Doesn't RSVP follow
the routed path?

Second paragraph: Suggest making last sentence a requirement as follow:

The QoS signaling protocol and the overall architecture in which it is
implemented must minimize the threat of Denial-of-Service attacks.

Third paragraph: Suggest clarification of "errors." Do you mean lack of
resources for a request or something else?

Fourth paragraph: Some of these statements seem to be wrt RSVP and Diffserv.
Reword as requirements, for example,

- The relative amount of reservation state and messaging should decrease in
number of session increas in portions of the network.
- The signaling method and architecture should minimize manual configuration
and instead should rely on policy-based solutions.

You get the idea....

Fifth paragraph: 3000 calls per second at 5 minutes per call is almost 1
Million simultanteous calls! And this over a "low-bit-rate hop" seems like
overkill. Please clarify what you meant here. By "hard" reservation, do you
mean admission control such that if requested(required) QoS cannot be
provided then the signaled session attempted should be blocked?

Sizth paragraph: What is the motivation for signaling path setup
independentof routing? How would the signaling source get sufficient
information to specify such a path?

Seventh paragraph: Please clarify what "dip into the IP path and dip
out"means.

Ninth paragraph: What is the requirement? Extensible signaling protocol
(like RSVP)? Are you proposing something besides Intserv or Diffserv QoS
class/behaviors should be signaled?

Tenth paragraph: Would be most helpful to quantify "fast." Is delay
comparable to post-dial delay in telephony acceptable?

Elventh paragraph: Is the requirement here: In uncongested or well traffic
engineering IP network (segments)QoS signaling is not required?

Thirteenth paragraph: Simplicity may in contradiction with other
requirements. Suggest that you soften this by saying "should" instead of
"needs to be."

3.1 Stateful vs Stateless

NOt sure that you can have both hard and soft state. Also am not sure of
what function "ice cream state" that transistions from hard to soft provides
(althought it is a nice name for the concept).

3.2 Midcom

Suggest that you define the term "Midcom." I, for one, am not familiar with
it.

First paragraph: Remove last sentence (not appropriate).

Third paragraph: Per comment on section 3, para 6, is this what you mean
that a "midcom" sytem does the path signaling as proxy on behalf of an end
system? Is the requirement that the architecture and signaling protocol need
to be aware of not only the topology, but the dyanmic actual QoS delivered
over specific paths (e.g., using a measurement-based approach)?

3.3 SIP and Domains

SIP and (Diffserv) Domains are markedly different topics. Think that SIP is
an example of the extensibility type of requirement, as commented earlier.

Second paragraph: Diffserv does not have signaling or admission control. I
think that the problem is that Diffserv domains are independently operated
and may have different QoS objectives (and periods during which they are
actually met) and this is a significant challenge for a QoS signaling
protocol/architecture.

4. Security, Reliability and Privacy Related Requirements

First paragraph: Ensure "confidentiality" instead of security. What does
security of the packets have to do with QoS?

Second paragraph: Not sure what this has to do with QoS signaling.

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis