Subject: Re: [NSIS] How to request a RESERVE with full QSPEC?

From: "Markus Ott" <[email-masked]>
Date: Tue, 20 Dec 2005 05:01:23 -0500

Hi all,
Because I have not received any answers or proposals to my questions until now I'm asking myself:
"Are my questions too complicated or are they outside of the scope of this discussion?".
As Jukka proposed "In general, I would really appreciate that if people send
comments/questions about unclear/wierd parts of basically any I-D, they
would also send the proposed text that fixes the problem. Thanks." I'm sending now my proposal to the solution of my question:
Instead of 

> .......
> When a QNE receives a RESERVE message with an unknown SESSION_ID, it
>     MAY send a NOTIFY message to its upstream peer, indicating the
>     unknown SESSION_ID. If the message was meant as a refresh, the reply
>     indicates a downstream route change to the upstream peer.  The
>     upstream peer SHOULD send a complete RESERVE on the new path (new
>     SII).  It identifies the old signalling association (old SII) and MAY
>     start sending complete RESERVE messages for other SESSION_IDs linked
>     to this association.
> -------------

I would propose the following:

"When a QNE receives a RESERVE message with an unknown SESSION_ID and 
this message contains no QSPEC because it was meant as a refresh then the
node MUST send a RESPONSE message with an INFO_SPEC that indicates a 
downstream route change to the upstream peer. The upstream peer SHOULD 
send a complete RESERVE on the new path (new SII).  It identifies the old 
signalling association (old SII) and MAY start sending complete RESERVE 
messages for other SESSION_IDs linked to this association."

Of course there must be an appropriate error code added in the draft.
The sending of RESPONSE message instead of NOTIFY is more consistent with the
draft because the following part says:

5.4.4.  NOTIFY Messages
..........................

NOTIFY messages are sent asynchronously, rather than in
response to other messages.

.........................

In my proposal the phrase "...the node MUST send a RESPONSE message..." can
be replaced with "...the node MAY send a RESPONSE message..." if we take into 
consideration that the upstream node will receive a NetworkNotification (with the new SII handle) 
from GIST after sending the RESERVE message and so it will detect the route change before 
receiving the RESPONSE message.

Regards,
 
Markus Ott.

----- Original Message -----
From: "Markus Ott" <[email-masked]>
To: [email-masked]
Subject: [NSIS] How to request a RESERVE with full QSPEC?
Date: Wed, 14 Dec 2005 11:13:59 -0500

> 
> Hi all,
> 
> I've got one more question relating to the internet draft of QoS NSLP:
> 
> it relates to the part
> 
> "5.4.1.  RESERVE Messages".
> 
> -------------
> .......
> When a QNE receives a RESERVE message with an unknown SESSION_ID, it
>     MAY send a NOTIFY message to its upstream peer, indicating the
>     unknown SESSION_ID. If the message was meant as a refresh, the reply
>     indicates a downstream route change to the upstream peer.  The
>     upstream peer SHOULD send a complete RESERVE on the new path (new
>     SII).  It identifies the old signalling association (old SII) and MAY
>     start sending complete RESERVE messages for other SESSION_IDs linked
>     to this association.
> -------------
> The questions to this paragraph were already sent by Roland Bless.
> Just one more issue:
> In the sentence "If the message was meant as a refresh, the reply
>     indicates a downstream route change to the upstream peer.": how
>     is the indication of a route change done? Is it done with help
>     of INFO_SPEC? If so then in the list with error values of all error
>     classes there is no appropriate error value to signal this
>     information. The only one (not very suitable for this) is the
>     protocol error with code 0x04: "Mandatory object missing: an
>     object required in a message of this type was missing." But I
>     think we need in this case a special code to notify this. Or what
>     a node must state in this case? Empty message - because the detection of
>     route change is done with help of SII handle?
>     Or is this done in another way? Which one?
> 
> Regards,
> 
> Markus Ott.
> 
> --
> ___________________________________________________
> Play 100s of games for FREE! http://games.mail.com/
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 20 Dec 2005 12:14:44 +0200 (EET)

Hi Markus,

Your suggestions sounds pretty good to me. What error code would you like 
to see? Could you send that suggestion too, thanks.

Regards,
Jukka

---

From: Roland Bless <[email-masked]>
Date: Tue, 20 Dec 2005 18:05:47 +0100

Hi Jukka,

> to see? Could you send that suggestion too, thanks.

We would propose to use something like
Transient (0x04) and within that class (0x11): "Full QSPEC required"
(or "Re-send RESERVE with full QSPEC"?)
BTW: is it intentional that the code is increased like 0x08, 0x09, 0x10
instead of 0x08, 0x09, 0x0A, 0x0B, and so on?

>>messages for other SESSION_IDs linked to this association."

New proposal:
"When a QNE receives a RESERVE message with an unknown SESSION_ID and
this message contains no QSPEC because it was meant as a refresh then
the node MUST send a RESPONSE message with an INFO_SPEC that indicates a
missing QSPEC to the upstream peer ("Full QSPEC required"). The upstream
peer SHOULD send a complete RESERVE (i.e. one containing a QSPEC) on the
new path (new SII)."

I'm not sure about the correctness of the following approach:
"It identifies the old signalling association (old
SII) and MAY start sending complete RESERVE messages for other
SESSION_IDs linked to this association."

So I'm not sure about the applicability of this statement, because
a rerouting event may only affect a particular flow, thus
it is not guaranteed that other sessions are also re-routed
along the new association?

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 20 Dec 2005 22:56:16 +0200 (EET)

Hi Roland, Markus,

Your suggestions sound, yet again, good to me. The statement about other
flows may follow the new route sounds like a "possible" optimization, but
I don't think we want to imply that within this spec - as you said, flows
should be independent by default. The only case I can see where the
session relation could happen is when you have used the BOUND_SESSION_ID
object. But I'm happy leaving that statement out.

Cheers,
Jukka