Subject: RE: [NSIS] QoS NSLP -- 4.7. Reduced State or Stateless Interior Nodes

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 18 Sep 2007 09:48:00 +0200

Hi Hannes

Thank you very much for your comments!
Sorry for the delay!

Please see in line!

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: donderdag 9 augustus 2007 11:06
> To: [email-masked]
> Subject: [NSIS] QoS NSLP -- 4.7. Reduced State or Stateless 
> Interior Nodes
> 
> I do not quite understand how the stateless interior nodes work.
> 
> I understand that you do not store GIST state for reverse 
> routing. I also understand that there is a desire not to 
> install per-flow reservations.
> 
> But if there is no state stored at all, as mentioned in 
> Section 4.7 of the QoS NSLP, then what's the point of signaling?

Georgios: Signaling is usefull even when a node does not support state,
e.g.,
measurement based admission control schemes. Furthermore, signaling is also
usefull for schemes 
That are using reduced states.

> 
> I also believe that Section 4.7 is missing an important point:
> 
> If a reservation request fails then the RESERVE message is 
> forwarded until it hits the egress node. In standard QoS NSLP 
> operation a RESPONSE message would be returned immediately 
> when an error is detected.

Georgios: You are right this procedure is missing, but is inluded in other
sections of this draft,
The QSPEC template draft and in QOS models drafts, such as RMD-QOSM.
We could also mention it in this section.

> 
> Here is a figure:
> 
>          Please view in a fixed-width font such as Courier.
> 
>           QNE             QNE             QNE            QNE
>         ingress         interior        interior        egress
>     GIST stateful  GIST stateless  GIST stateless  GIST stateful
>            |               A               B              |
>    RESERVE |               |               |              |
>   -------->| RESERVE       |               |              |
>            +--------------------------------------------->|
>            | RESERVE'      |               |              |
>            +-------------->|               |              |
>            |               | RESERVE'      |              |
>            |               +-------------->|              |
>            |               |               | RESERVE'     |
>            |               |               +------------->|
>            |               |               |  RESPONSE'   |
>            |<---------------------------------------------+
>            |               |               |              | RESERVE
>            |               |               |              +-------->
>            |               |               |              | RESPONSE
>            |               |               |              |<--------
>            |               |               |     RESPONSE |
>            |<---------------------------------------------+
>    RESPONSE|               |               |              |
>   <--------|               |               |              |
> 
> Assume that the RESERVE' message fails at node A. Then, a 
> RESPONSE cannot be sent back to the ingress but instead the 
> message continues its way towards the egress node.

Georgios: right!

> 
> It is, however, necessary to mark the message in a way that 
> subsequent nodes (in this case node B) does not attempt to 
> make a reservation but just forwards the message as is.

Georgios: right!
> 
> When the egress node receives the message it then constructs 
> a RESPONSE' 
> message indicating the failure of the reservation attempt.

Georgios: right!

> 
> This procedure requires additional protocol mechanisms to support
> a) marking a message as failed
> b) allow the state machine to forward the message in this 
> particular mode even though the reservation failed.

Georgios: The above mechanisms can be accomplished, since they 
are already described in Section 5 and in the QSPEC template draft!
However, it will make this section more clear if we will add 
the above steps also in this section!

Best regards,
Georgios

> 
> I don't see any of these things in the document. A bug or intention?
> 
> Ciao
> Hannes
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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