Subject: [NSIS] qos-nslp: query and response request

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 May 2004 08:54:47 +0200

Dear qos-nslp authors,

the response_request mainly serves to transport 
an RII. It further distinguishes a Query from a 
PATH(Query) message in the case of a receiver 
initiated reservation.

The RII must be created and maintained locally. 
If there's just a single dialogue at a time 
requiring a response, the RII could be omitted 
and a local timer could control the response 
process. This would reduce the number of 
parameters to be signaled (a flag bit will do) 
and further reduce the state to be maintained 
(the timer is foreseen anyway, but no RII must 
be created, stored or processed).

Do you expect multiple simultaneous message 
dialogues requiring response messages? 
If so, could you describe one?

Regards, Rudiger

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 May 2004 11:23:47 +0200

Hi Rudiger

> be created, stored or processed).

Georgios: I am not sure what you mean by "created and maintained locally."
The RII is not created and maintained locally. It can be used to send
RESPONSE messages
back to a node that initiated a QUERY/RESERVE message and  required to
receive
a RESPONSE message from the last node in the downstream path.  A downstream
node that desires
responses may keep track of this RII to identify the RESPONSE when it
passes back through it.

In particular, regarding the QUERY message, see Section 5.4.2 of the
QOS-NSLP draft,
a RESPONSE message is sent back to the node that required the RESPONSE, only
by the last downstream
node that has to process the QUERY message, see some text from the draft:

"If this is last node to process this QUERY message (either because it
   is the last node on the path, or because of scoping), and a
   RESPONSE_REQUEST object is present, then a RESPONSE message MUST be
   generated and passed back along the reverse of the path used by the
   QUERY."

> If so, could you describe one?

Georgios: No, I don't think so

Best Regards,
georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 May 2004 15:20:27 +0200

Hi Rudiger

In addition to what I have mentioned before, maybe I misunderstood your below question:

"Do you expect multiple simultaneous message 
dialogues requiring response messages? 
If so, could you describe one?"

If your question is:
Is it possible to send QUERY/RESERVE messages within one session, where each of them might request a RESPONSE message.
Then the answer is yes. Please note that any RESERVE messages used to initiate/refresh/release a reservation state and any QUERY messages that are sent by any downstream nodes within one session may request a RESPONSE message.

Best Regards,
Georgios

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 May 2004 16:26:13 +0200

Hi Georgios,
 
the meaning is "multiple simultaneous message dialogues 
referring to one session requiring response messages by 
one originatior".
 
Regards, Rüdiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Georgios Karagiannis
Sent: Wednesday, May 19, 2004 3:20 PM
To: [email-masked]
Subject: Re: [NSIS] qos-nslp: query and response request

Hi Rudiger

 
If your question is:
 
Best Regards,
Georgios

---

From: "McDonald, Andrew" <[email-masked]>
Date: Thu, 20 May 2004 10:28:22 +0100

> referring to one session requiring response messages by

I think it is impossible to exclude this.

As one example, what happens if a RESPONSE message is lost on route (e.g. dropped because of overload/congestion)? In this case we could send another QUERY/RESERVE (which might contain different parameters), and subsequently get a RESPONSE. Is this for the original QUERY/RESERVE or the second one? Without a unique identifier (the RII), you can't tell them apart.

regards,
Andrew

> Is it possible to send QUERY/RESERVE messages within one session,
> where each of them might request a RESPONSE message. 
> Then the answer is yes. Please note that any RESERVE messages used to
> initiate/refresh/release a reservation state and any QUERY messages
> that are sent by any downstream nodes within one session may request
> a RESPONSE message.   
> 
> Best Regards,
> Georgios

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 24 May 2004 08:44:58 +0200

Hi Andrew,

|Geib, Ruediger wrote:
|> the meaning is "multiple simultaneous message dialogues
|> referring to one session requiring response messages by
|> one originatior".
|
|I think it is impossible to exclude this.
|
|As one example, what happens if a RESPONSE message is lost on 
|route (e.g. dropped because of overload/congestion)? In this 
|case we could send another QUERY/RESERVE (which might contain 
|different parameters), and subsequently get a RESPONSE. Is 
|this for the original QUERY/RESERVE or the second one? Without 
|a unique identifier (the RII), you can't tell them apart.

The above holds if the session ID remains unchanged, meaning 
you refer to an active session. The RESPONSE message 
carries a QSPEC object which should be interpreted by the 
originator of the QUERY/RESERVE. Which other QoS NSLP contents 
could be changed without being identifiable by a RESPONSE 
without RII?

Regards,

Rudiger

---

From: "McDonald, Andrew" <[email-masked]>
Date: Mon, 24 May 2004 16:47:00 +0100

Hi,

Geib, Ruediger wrote:
>> As one example, what happens if a RESPONSE message is lost on
>> route (e.g. dropped because of overload/congestion)? In this
>> case we could send another QUERY/RESERVE (which might contain
>> different parameters), and subsequently get a RESPONSE. Is
>> this for the original QUERY/RESERVE or the second one? Without
>> a unique identifier (the RII), you can't tell them apart.
> 
> you refer to an active session.

Yes.

> The RESPONSE message
> originator of the QUERY/RESERVE.

There are cases where I wouldn't expect a QSPEC to be included in the RESPONSE. An "I don't understand your QSPEC" error, or an "Unsupported object in QoS NSLP message" error probably don't need one.

Also, the QSPEC in the RESPONSE may well be different to that in the RESERVE. E.g. it may describe available resources, because the requested resources could not be satisfied.

> Which other QoS NSLP contents

In principle, anything could change. Most things (REFRESH_PERIOD, BOUND_SESSION_ID, RSN, SCOPING, etc) aren't echoed back in the RESPONSE.

As one example, authorization data (POLICY_DATA) may change since the previously used credentials have just expired. The RESPONSE does not contain the POLICY_DATA sent in the RESERVE/QUERY.
(Even flow routing information could change. However, in the current GIMPS draft the RESPONSE comes with sufficient information to identify the applicable FRI.)

regards,
Andrew