Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt

From: [email-masked]
Date: Thu, 30 Oct 2003 15:50:32 +0100

Hi,

I am not sure if it is a good idea to filter messages out in the NTLP
because you assume the NSLP will not need them (because it believes the
message is not new). It is probably cleaner if the NTLP does not need to
know about the RSN in the first place.

Best regards,
Sven

"Thanh Tra LUU" <[email-masked]>@ietf.org on 30/10/2003 15:46:27

Sent by:    [email-masked]

To:    "Hancock, Robert" <[email-masked]>
cc:    <[email-masked]>
Subject:    Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt

hi,

I do not mean NTLP refreshes the signaling application state. It is enough
clear about this one. I did not clearly express my thought. We can consider
RSN (RSN is just a name) as a message sequential number of NSLP and NTLP
should know this number as a NTLP state number. It helps NTLP to filter
only
new NSLP message to transfert to NSLP.

Regards,

Nary Tra
ENST, Paris

----- Original Message -----
From: "Hancock, Robert" <[email-masked]>
To: "'Thanh Tra LUU'" <[email-masked]>; <[email-masked]>
Sent: Thursday, October 30, 2003 2:40 PM
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt

> hi all,
>
> a brief comment on the refresh/NSLP/NTLP question.
>
> > -To refresh a reservation, everything is done by QoS-NSLP. I don't see
the
> > any NTLP functions to support refreshment. However, in the draft of
> > R.Hancock (draft-handcock-nsis-reliability-00), NTLP can be used to
> support
> > refreshing state between NSLP peers.
>
> i think this is a misunderstanding. the draft mentioned classifies
various
> different sorts of signalling messages (and some of them are refresh
> messages). the role of the NTLP is to deliver all messages, but it
> doesn't care directly if they are refreshes or something else. in other
> words, the NTLP doesn't include specific functionality for refreshing
> signalling application state, it provides a message delivery capability
> which signalling applications can use to refresh their own state.
>
> this specific issue is further discussed in 3.2.5 of the framework.
> it was discussed on the mailing list quite intensively (around April/May
> this year).
>
> > It raises a question : "If NTLP
> > supports refreshing state, should it know the RSN to do refreshing ? "
> Note
> > that, RSN can be applied in other signaling applications, eg: the first
> > "trigger message" is marked as RSN=x, the second is x+1 and the third
is
> > x+2. If NTLP receives RSN=x+1 and then it receives this message one
more
> > time, it considers this message a refresh message. After that it
receives
> > message with RSN=x+2 (of the same session id), it knows this is a new
> > trigger message and gives NSLP this message. Somebody has answered me
NTLP
> > should not know RSN because it belongs to NSLP. According to me, NTLP
> should
> > know to support refreshing state, reason : this is a generic function
of
> > NTLP to support most of NSLP applications. Please correct me if i am
> wrong.
>
> please see above. hope this helps.
>
> r.
>
> --
> Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury,
Bracknell,
> Berkshire. RG12 8FZ
>
> The information contained in this e-mail and any attachments is
confidential to
> Roke Manor Research Ltd and must not be passed to any third party without
> permission. This communication is for information only and shall not
create or
> change any contractual relationship.
>

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

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

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Thu, 30 Oct 2003 16:07:20 +0100

hi Sven,

For NSLP can receive a message, RSN can increase. Anyway, RSN is not a
suitable name to discuss about this problem. More generally, can we suppose
that when there is a sequential number for each trigger NSLP message and it
can be used by NTLP to filter NSLP message before it is sent to NSLP. For
NSLP can receive a message, this number must be inscreased. Of course, NSLP
can refresh its own state by sending Refresh messge with a increased number.

Regards.

Nary Tra
ENST, Paris

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Thu, 30 Oct 2003 16:48:03 +0100

hi Robert,

I have the same thought as you have stated : "why not do this in the layer
that
the message is generated, rather than asking a lower layer to guess that the
message wasn't really needed? ".

However,  this function is generic for signaing applications. It avoids
implementing refresh burden (as possible) for NSLP application. Every
different NSLP types can use this one and NTLP will optimise this function.
It can filter message for many instances of different NSLPs at the same
time. In this case, NTLP state refreshing is more meaningful.

On the other hand, in the draft of Melinda, draft-shore-ntlp-00.txt, (5.5.4)
she talked about 2 mechanisms. I review the second mechanism " The second
mechanism is to periodically send full, standard NTLP with complete NSLP
payloads as appropriate.  ". I think it is good if we use the sequential
number in this case.

Regards,

Nary Tra,
ENST, Paris.

>
> this would also absolutely be my view. lower layers should not do
> thinking on behalf of upper layers. if it is possible for an entity
> to know not to send a message, why not do this in the layer that
> the message is generated, rather than asking a lower layer to guess
> that the message wasn't really needed?
>
> r.