Subject: [NSIS] Review of "Analysis of Existing Signaling Protocols"

From: [email-masked]
Date: Mon, 7 Jul 2003 14:55:48 +0300

Hi all,

In preparing for IETF 57, I am trying to make a quick review of many of the
documents under discussion.

http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-02.txt

Overall, I think that this document is looking quite good.  I am happy with
the overall tone & structure of the document.  I think there are still some
places for improvement, I hope that we can have some discussion of this document
and then a revision before we start the WG last call on it.

Minor nits:

End of Section 3.1:

Text:

   In summary, in trying to introduce reliability in RSVP, we are
   getting closer to reinvent TCP. Furthermore, if head of line blocking
   is likely to occur, SCTP can be used. Certainly, if TCP, SCTP or
   similar protocols is the transport protocol for RSVP, the message
   reliability would not have been an issue.

should be:
   a similar protocol is the transport protocol for RSVP, the message
   ^                 ^
   reliability would not have been an issue.

Section 3.2:

Text:
   According to RSVP [RFC2205], each RSVP message can only contain
   information for one session. In a network that has a reasonably large
   number of RSVP sessions, this constraint imposes a heavy processing
   burden on the routers. Many router OS is based on UNIX. [IP-OPT]

should be:
   According to RSVP [RFC2205], each RSVP message can only contain
   information for one session. In a network that has a reasonably large
   number of RSVP sessions, this constraint imposes a heavy processing
   burden on the routers. Many router OSes are based on UNIX. [IP-OPT]
                                        ^^ ^^^ 
More stubstantial comments.

Section 3.5

I don't completely disagree with the text here, but I don't agree with it completely
either.  I don't think the authors have proven that:

   If a new transport protocol is needed, the protocol must be able to
   handle the following:
   - reliable messaging;

   - message packing;

   - the MTU problem;

   - small triggered message volume.  

I think that the authors should not make such bold statements unless they provide
more text to back-up their claims.  I think it would be more reasonable to say that
if reliability, fragmentation, etc. are determined to be problems for NSIS, then
they should be solved using known techniques.  Further, I would strike the final
paragraph completely, unless there was some documentation to back-up the claims.

Section 6.2.1 says:

   It was proven that YESSIR one-pass reservation model has better
   performance and lower processing cost, comparing with a regular two-
   way signaling protocol, such as RSVP.

A reference to where this was proven would be needed.

7.  Summary needs improvements.  Also, this is where any conclusions drawn in
the document should be placed.

8.  Security Considerations needs improvement.  Perhaps Hannes could provide
a paragraph or two summarizing some of the conclusions from the RSVP Security
Properties & Threats documents.

References need to be split - I could provide the authors some clues off-list 
on how to do this.

Finally, I think the appendix is not needed, I suggest it be deleted.

thanks,
John

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