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

From: [email-masked]
Date: Wed, 24 Sep 2003 12:25:55 +0200

Hi Rudi,

Again, in-line ...

Cheers,
Sven

"Geib, Ruediger" <[email-masked]> on 24/09/2003 11:28:24

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:    [email-masked]
Subject:    RE: qos-nslp-00

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.

Sven>> It is used in the summary refresh, but this is purely a QoS NSLP
matter that is unrelated to the session ID. Note that we see the summary
refresh with RSN as a minimal case but that other objects or parameters may
be part of it.

|- 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).

Sven>> We can take it up in the discussions for the next version.

 Regards, Rüdiger

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