Subject: [NSIS] Summary of forthcoming QoS NSLP changes

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 10 Nov 2006 19:27:34 +0200 (EET)

Dear all,

Here is a list of the changes I intend to do to the current QoS NSLP spec. 
After those, we are ready for WGLC. The spec is looking good. If there are 
no arguments, I could do these within a week.

- Make reduced refreshes the default behavior, add a new error code for 
  "full refreshes required".

- Some clarifications needed for proxy mode (and GIST),
  object order (SHOULD use a certain, MUST accept in any order), tear 
  operation, response/notify (RESPONSE is triggered by an incoming 
  message, NOTIFY is fully asynchronous)

- Summary refresh messages: one NSLP message can refresh several 
  sessions (use a new object with SID+RSN pairs)

- Summary tear: use a new object with SIDs only.

- RSN MUST NOT be interpreted when receiving a tear. If two QNEs are not 
  in synch, what can you? Update the reservation, then tear? What if the 
  update fails? There is no reason for QNEs to be in synch, you just 
  remove the resources you had allocated.

- Re-introduce the ack-flag. This is needed in order to do diagnostics, 
  say, you want to make sure the next peer actually processed your message 
  and understood it. Also need to add a new error code that tells the 
  QNI if the "path is truncated", i.e., a peer is responding to the Ack. 
  It is a policy decision on a QNE whether it should send e.g. an 
  Ack-flaged refresh when it receives such a refresh from its upstream 
  peer. 

- [After concensus] Update the draft on "stacking".

Yell now if some of these are not right things to do.

You could also yell, if these are, that would be nice, too. :)

Jukka

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

---

From: Roland Bless <[email-masked]>
Date: Tue, 14 Nov 2006 17:13:06 +0100

Hi Jukka,

> no arguments, I could do these within a week.

Some additions for clarification. :-)

>   "full refreshes required".

We already have an error message saying "full QSPEC required" that
is used when a new node on the path was hit. "full refreshes required"
should be used when a node doesn't support reduced refreshes (and
the sending node should remember that for subsequent refreshes), so
the above description may be still a bit too similar to the already
existing one.

>   sessions (use a new object with SID+RSN pairs)

This would require that GIST implementations follow the SHOULD
in:
                                 Note that GIST if possible SHOULD use
   the same SII-Handle for multiple sessions to the same peer, since
   this then allows signaling applications to aggregate some signaling,
   such as summary refreshes or bulk teardowns.

if the implementation does not, summary refreshes are not possible
(but I guess we don't need an explicit hint from GIST about that
feature, because the NSLP will not find any identical SII-handles?

>   remove the resources you had allocated.

Yes, we discussed these issues in the hallway...maybe someone has
another view?

>   and understood it. Also need to add a new error code that tells the 
^^^^^^^^^^^^^^^^^^^^^^
Sorry to jump in, but that very text was already in there as a rationale
and I didn't get the point in the past. The essential point is that you
want to detect whether the QoS NSLP peer application is still alive
or not while GIST continues to work. It's not about reliable
transmission, it's about a faster dead peer diagnosis?
A further point was how and when
to detect the missing response. Currently retransmissions (sec. 5.2.4.)
are only defined on an end-to-end basis, not between QNEs.
So we must define approriate mechanisms, probably only
for refreshes w/o RII set (these usually go only between
adjacent QNEs).

>   QNI if the "path is truncated", i.e., a peer is responding to the Ack. 

More specifically: a QNE should notify its upstream QNE if its
downstream QNE is probably dead (not responding to that ACK)

>   Ack-flaged refresh when it receives such a refresh from its upstream 

Hm... Usually an incoming refresh (w/o RII set) doesn't trigger
an new one downstream. Or do you mean only the ACK flag setting?

> - [After concensus] Update the draft on "stacking".

Yep.

> Yell now if some of these are not right things to do.

Yelling...

> You could also yell, if these are, that would be nice, too. :)

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 14 Nov 2006 18:26:27 +0200 (EET)

Hi,

comments (acks) below. Thanks for the feedback and clarifications to my 
list.

Jukka

> the above description may be still a bit too similar to the already

That is what I meant, was just too lazy to write a long description. :)

> feature, because the NSLP will not find any identical SII-handles?

Yes.

> >   and understood it. Also need to add a new error code that tells the 

Yes. The retransmission procedure should be the same for e2e and p2p 
messages.

> downstream QNE is probably dead (not responding to that ACK)

And the upstream QNE should then send this notify further to the QNI.

> an new one downstream. Or do you mean only the ACK flag setting?

I meant, a downstream QNE does not need to send a refresh using Ack, when 
its upstream QNE did that.