Subject: [NSIS] RE: qos-nslp-00

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 24 Sep 2003 11:28:24 +0200

Hi Sven,

again some in-line comments

|- Retransmitted "Reservation Sequence Numbers"
|  serve as a Session ID. Why aren't
|  the tradeoffs and benefits of combining both
|  functions discussed?
|
|Sven>> We took special care not to use the RSN for anything else but
|ensuring that QoS NSLP message reordering could be detected. 
|They have nothing to do with any session ID at the NTLP. Afaik, it is 
|an open issue how NTLP sessions will relate to NSLP message exchanges. 

[Rudi]: Section 4.2 introduces a summary refresh using the RSN to 
identify a reservation. This isn't related to reordering.

|- A table listing the maximum per session state
|  maintenance requirements is missing.
|
|Sven>> I think it is a bit early for that. I am not completely 
|sure what you mean: an analysis of the maximum amount of reservation 
|state associated with a QoS reservation maybe? That might depend on 
|the QoS model though.

[Rudi]: Leave out the QoS information you don't know. Just inform the 
reader about the state per reservation as required by the protocol 
without QoS specific information. I think state maintenance 
requirements should be considered during early protocol design. 
This may help to prevent patchwork during a later stage (consider 
IntServ/RSVP as an example how not to do it).

Regards, Rüdiger

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