Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Fri, 15 Nov 2002 13:46:02 +0100

Hi,

I have gone through the analysis draft and I have 
some questions/comments on it...

In general: 
1. The draft provides a good collection of references to 
extensions of RSVP. These are mentioned very briefly, however 
some of the RFC need to be explained more extensively than 
others such as [RFC3175], [RFC3209]. For this you could use the 
text from the:
http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt     

2. I find it a very good idea to include protocols developed outside
IETF, but the list in the draft can be extended. So in your question 
on adding more protocols apart from YESSIR, Boomerang, I suggest that 
you add other lightweight signalling protocols such as:
- Resource Management in Diffserv On DemAnd (RODA) PHR 
http://www.ietf.org/internet-drafts/draft-westberg-rmd-od-phr-02.txt
see also PfHSN2002, Networking2002, ISCC 2002 proceedings,etc.

- Resource Management in Diffserv Measurement-based Admission Control PHR 
http://www.ietf.org/internet-drafts/draft-westberg-rmd-mbac-phr-00.txt

I will be happy to provide you with some input on these protocols.

3. The draft tends to be an "review of existing protocols". 
However the review itself is based on several common issues such as 
Processing Overhead, Bandwidth Consumption, etc. I suggest that these 
be clearly defined and use a common terminology.
 
Specifically:
- Section 2.3 
It is not clear whether in this section you explain processing overhead 
due to signalling or scalability in terms of number of reservation states.
I consider these two as separate issues.
In the same section RSVP aggregation is explained. I believe they 
should be explained separately.    
Also the following paragraph is rather contradictory:
"
Still, for example, the implementation of the daemon can have a huge
effect on the scalability. In [KaSh01], the authors show that their
RSVP daemon is able to handle much more flows than the de-facto ISI
RSVP daemon implementation. Furthermore, the scalability concern
commonly associated with RSVP are more or less subject to
individual's views on what "scalability" is.
"
as initially you say that the daemon implementation can impact
scalability and than you continue by saying that "scalability" is 
subjective to the individual's understanding of it?!

- Section 2.4
Considering the size of signalling messages the Bandwidth Consumption 
does not seem to be important, unless we're talking about wireless 
links. What was the motivation for having it there? 

-Section 2.7
you mention "killer problems", I assume you meant killer reservation 
problems... 

- Section 3.4 and section 4.4
The issues of the reservation identifier and the refresh of the 
reservation state are common for the signalling protocols RSVP, YESSIR
and Boomerang when considering mobility support. 
However in case of YESSIR and Boomerang the refresh of the reservation
state is different than in RSVP as both YESSIR and Boomerang are
sender initiated, which means that there is no need to store backward 
routing information.  I would suggest that in Section 3.4, Section 4.4 
this is explained, instead of just referring to Section 2.5.

-Section 5.5
You focus on the signalling protocols and yet you have explained 
the ITSUMO framework. Is the idea here to include framework/architectures 
as well?
 
Regards,
Vlora

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 17 Nov 2002 20:56:38 +0200 (EET)

Hi, thank you for the comments. Below some answers:

Jukka

> http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt     

True, although it would would be good not to include too much description
about all extensions, but rather give the review of the extension - the
reader can find out more information from the reference. I fear the 
document will be horribly long otherwise...

> see also PfHSN2002, Networking2002, ISCC 2002 proceedings,etc.

Could you provide more detailed references? Which articles? Title, 
authors?

> I consider these two as separate issues.

As I see it, the processing of signalling is one thing and the scalability 
is tied to the hardware of the router you are evaluating. Thus,
evaluating the processing overhead is more generic. Still, we should try 
to avoid the words "scalability, scalable".

> subjective to the individual's understanding of it?!

yes, true, I shouldn't have used the word scalability. Something along the
processing needed to support n number of flow states - whether the number
of flows supported is high or low depends on the individuals view and
requirements.  I tried to say two different things in one paragraph...:)

> links. What was the motivation for having it there? 

Exactly that: how much bandwidth does the signalling consume, both 
initially and to keep the reservation/resources reserved. I don't see how 
bandwidth utilization is only related to wireless networks, though. I 
think this is an issue, perhaps not the most important for wired 
networks... but, the wireless ...:)

> you mention "killer problems", I assume you meant killer reservation 

You lost me...:) The point of this section was to discuss how well (or
not) a protocol could be deployed in different networks, and give some
examples of work done in the area.

> this is explained, instead of just referring to Section 2.5.

True. The evaluation of all protocols is still in a very early stage, 
especially regarding YESSIR, Boomerang, Insignia, ...

> the ITSUMO framework. Is the idea here to include framework/architectures 

This was probably a mistake. Still, ITSUMO is an example of a bandwidth 
broker (off-path signalling?) scheme, so I thought it could be there. On 
the other hand, there is not much to evaluate from a protocol POV.