Subject: Re: [NSIS] input (over RMD) for NSIS Analysis draft

From: "karagiannis" <[email-masked]>
Date: Fri, 18 Jul 2003 09:54:24 +0000

Hi Roland

Thank you very much for your comments.

Please see my comments in line:

>I think it should be emphasized that RMD is an _intra-domain_ 
>resource management scheme.
 
We tried to emphasize that it is an edge to edge resource management
scheme.
Would it be okay for you if we change the following sentence from:

`Resource Management in Diffserv (RMD) [WeCs02] represents a QoS
framework
that extends the Diffserv principles with new ones necessary to provide
dynamic resource management and admission control in Diffserv domains.`

Into:

`Resource Management in Diffserv (RMD) [WeCs02] represents an edge to edge

(intra-domain) QoS framework that extends the Diffserv principles with new

ones necessary to providedynamic resource management and admission control

in Diffserv domains.`

>What about the number of messages that has to be processed 
>per interior node?

You are right:
We would like to add the following sentece:

`The number of required refresh messages in the RMD protocol is the same 
as the number of required refresh messages in RSVP [RFC2205].` 

>
>> Regarding the deployability issues, RMD is an edge to edge protocol. 
>                                              ^^^
>                                               intra-domain
>

Will the following change be okay:
From:
`Regarding the deployability issues, RMD is an edge to edge protocol.`

INto:
`Regarding the deployability issues, RMD is an 
edge to edge (intra-domain) protocol.`

>Wouldn't it be good to mention special requirements for the signaling
>protocol to make your scheme work?

What do you mean by special requirements?

Best Regards,
Georgios

Dr. ir. Georgios Karagiannis
Group: Design and Analysis of Communication Systems (DACS)
University of Twente
The Netherlands

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

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Sat, 19 Jul 2003 09:36:33 +0200

Hi,

I've read the draft of proposal for RSVPv2 NSLP. I have some
questions.

- For bi-directional reservation, you call NI (sender) and
NR(receiver), it makes me confused because both of end hosts can be
receiver and sender. Supposing the bi-directional reservation between
A (and RSVPv2 aware) and B (another RSVPv2 aware end host) is
initiated by  A (NI) . The two  reservation can be established on two
different paths. The announcement of reservation success (A -> B) is
carried by packet Path(NslpPathInit) from B to A. Because of asymmetry
of routing, it is possible that the intermediate NTLP stateful nodes
between A and B don't receive this message to know the success of
reservation. They will only know it after receiving the refresh
message from sender. In case unidirectional reservation, the
intermediate nodes know it by receiving the NslpResvInit. Why is there
this difference ? Is it useful ?

- I don't understand how the NTLP stateless node can support the
routing change. No state is established when NTLP stateless receives a
Path(NslpPathInit) message. When NTLP stateless receives a
Path(NslpPahInit), it adds the new required reservation units of  a
traffic class. When it receives a PathTear(NslpPathTear), it will
subtract the required resource. As previous mail, you said
"simultaneously maintained RMD reservation states in the interior
nodes is equal to the number of the supported traffic classes", that
means if there is a routing change, a deletion of a flux can delete a
required resource on a intermediate NTLP stateless node which was not
previously on the data path.

- I don't understand refresh mechanism for the interior NTLP stateless
node either. How does a interior NTLP stateless nodes know a refresh
message belongs to a specific flux of a traffic class ? If there is
not the refresh for a flux in the NTLP stateless nodes, what does the
refresh mean here ?

- For the severe congestion handling, interruption of a flux which is
reserved doesn't seems interesting to me. If I want to reserve
resource for a VoIP communication, it's better if network refuses the
connection before I can begin the conversation rather than disrupt my
communication.

Nary Tra
ENST, Paris