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

From: [email-masked]
Date: Fri, 01 Nov 2002 08:43:14 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Steps in Signaling Working Group of the IETF.

	Title		: Analysis of Existing Quality of Service Signaling 
                          Protocols
	Author(s)	: J. Manner, X. Fu
	Filename	: draft-ietf-nsis-signalling-analysis-00.txt
	Pages		: 22
	Date		: 2002-10-31
	
This document presents a review of existing protocols for signalling
the Quality of Service requirements of flows to nodes in an IP
network. Protocols are reviewed independently and not compared
against the NSIS requirements document nor to RSVP itself. The
purpose is to learn from existing work and to avoid common
misconceptions about the protocols. A further goal is to avoid to
redesign ideas already implemented in another protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nsis-signalling-analysis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Thu, 7 Nov 2002 17:28:12 +0100

Hi John,

Is this draft really an NSIS WG draft or is it just the 
name that is misleading?

Regards,
Vlora

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]]
|Sent: Friday, November 01, 2002 2:43 PM
|Cc: [email-masked]
|Subject: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt
|
|
|A New Internet-Draft is available from the on-line 
|Internet-Drafts directories.
|This draft is a work item of the Next Steps in Signaling 
|Working Group of the IETF.
|
|	Title		: Analysis of Existing Quality of 
|Service Signaling 
|                          Protocols
|	Author(s)	: J. Manner, X. Fu
|	Filename	: draft-ietf-nsis-signalling-analysis-00.txt
|	Pages		: 22
|	Date		: 2002-10-31
|	
|This document presents a review of existing protocols for signalling
|the Quality of Service requirements of flows to nodes in an IP
|network. Protocols are reviewed independently and not compared
|against the NSIS requirements document nor to RSVP itself. The
|purpose is to learn from existing work and to avoid common
|misconceptions about the protocols. A further goal is to avoid to
|redesign ideas already implemented in another protocol.
|
|A URL for this Internet-Draft is:
|http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-
|analysis-00.txt
|
|To remove yourself from the IETF Announcement list, send a message to 
|ietf-announce-request with the word unsubscribe in the body of 
|the message.
|
|Internet-Drafts are also available by anonymous FTP. Login 
|with the username
|"anonymous" and a password of your e-mail address. After logging in,
|type "cd internet-drafts" and then
|	"get draft-ietf-nsis-signalling-analysis-00.txt".
|
|A list of Internet-Drafts directories can be found in
|http://www.ietf.org/shadow.html 
|or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
|
|
|Internet-Drafts can also be obtained by e-mail.
|
|Send a message to:
|	[email-masked].
|In the body type:
|	"FILE 
|/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt".
|	
|NOTE:	The mail server at ietf.org can return the document in
|	MIME-encoded form by using the "mpack" utility.  To use this
|	feature, insert the command "ENCODING mime" before the "FILE"
|	command.  To decode the response(s), you will need "munpack" or
|	a MIME-compliant mail reader.  Different MIME-compliant 
|mail readers
|	exhibit different behavior, especially when dealing with
|	"multipart" MIME messages (i.e. documents which have been split
|	up into multiple messages), so check your local documentation on
|	how to manipulate these messages.
|		
|		
|Below is the data which will enable a MIME compliant mail reader
|implementation to automatically retrieve the ASCII version of the
|Internet-Draft.
|
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: [email-masked]
Date: Fri, 8 Nov 2002 10:11:39 +0200

Hi Vlora,

> Is this draft really an NSIS WG draft or is it just the 

It is a WG draft.  I discussed with our ADs about the lack
of progress on some of our charter items, and it was suggested
that a good editor for this work would be important, especially
a non-biased one.  As you know, RSVP has been labeled many
things (not scalable, etc) that are incorrect, so having an
unbiased editor is critical for this work.

At IETF 54, there was general consensus on moving forward
with this work, and taking Xiaoming Fu's document on Multicast
analysis into the WG document.

As I have understood, Jukka was short on time, so he may not
have solicitied input from other folks - however, now would 
be a perfect time to comment, criticize or suggest text to
the document.

thanks,
John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 8 Nov 2002 10:21:36 +0100

Hi John

We really want to contribute to the WG draft.
The draft draft-demeer-nsis-analysis-03.txt could be used as 
our contribution to the WG draft.
This draft is located at:
http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt 

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 8 november 2002 9:12
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] I-D
ACTION:draft-ietf-nsis-signalling-analysis-00.txt

Hi Vlora,

thanks,
John

---

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Fri, 8 Nov 2002 11:32:32 +0100

Hi John,

|It is a WG draft.  I discussed with our ADs about the lack
|of progress on some of our charter items, and it was suggested
|that a good editor for this work would be important, especially
|a non-biased one.  As you know, RSVP has been labeled many
|things (not scalable, etc) that are incorrect, so having an
|unbiased editor is critical for this work.
I understand. 

|As I have understood, Jukka was short on time, so he may not
|have solicitied input from other folks - however, now would 
|be a perfect time to comment, criticize or suggest text to
|the document.
I still haven't read the draft, but I will do that shortly. 
As Georgios said we can definitely contribute to this draft.

Regards,
Vlora

---

From: [email-masked]
Date: Fri, 8 Nov 2002 12:51:19 +0200

Hi Vlora,

> As Georgios said we can definitely contribute to this draft.

That would be great.  I think suggesting text, additional things
to consider, etc. would be extremely helpful.

thanks!
JOhn

---

From: [email-masked]
Date: Fri, 8 Nov 2002 12:52:10 +0200

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

Great.  Please read the other draft and comment on it.  If you think
you can add text, please contact Jukka and suggest ways to work.

thanks,
John

---

From: [email-masked]
Date: Sun, 17 Nov 2002 20:02:16 +0200

Hi Vlora,

> 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.

Do you have any code for these where folks could test them out?  If
you have any simulation results, etc. it would be great to get info
on them.

> -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?

I would hope we would not focus on framework or architectures as these are
somewhat tangential to our purpose.

thanks,
John

---

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Mon, 18 Nov 2002 13:10:54 +0100

Hi John,

|> 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.
|
|Do you have any code for these where folks could test them out?  If
|you have any simulation results, etc. it would be great to get info
|on them.
|

There is a prototype implementation in Linux of both protocols (RODA and RIMA) 
and also a lot of simulation results (mainly on RODA). Some of the results on 
the RODA as I mentioned are already presented in conferences. The most recent
ones are:

1. Westberg, et. al., "Resource Management in Diffserv (RMD): A Functionality
and Performance Behavior Overview", PfHSN 2002 proceedings, Berlin.

2. Czászár, et. al. "Severe Congestion Handling with Resource 
Management On Demand ", Networking2002 proceedings, Pisa, Italy.

3. Jacobsson, et.al. "Resource Management in Differentiated 
Services: A Prototype Implementation". 7th IEEE SCC 2002 proceedings, Italy.

And as we're continuously working on the protocols there hasn't been
any release of the code yet. 

|> -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?
|
|I would hope we would not focus on framework or architectures 
|as these are
|somewhat tangential to our purpose.
Agreed. 

Regards,
Vlora

---

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Mon, 18 Nov 2002 14:02:14 +0100

Hi Jukka,
 
|> 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     
|
|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...
|
I agree with you. However I think that RSVP Aggregation and RSVP-TE 
should be discussed in more detail.

|Could you provide more detailed references? Which articles? Title, 
|authors?
I already replied to John's question on this. Here are some recent 
papers:

|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".
Why should we avoid it? If there is a well defined and agreed 
terminology we could still use it. You will need to define 'Processing 
Overhead' just the same.
I think 'Scalability' (in terms of number of states, number of 
hand-offs, etc) is an important performance issue for the IP QoS 
protocols and it should not be avoided.

|> 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?!
|
|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...:)
the paragraph does talk about scalability :), which is good, but I
think it's better if you remove completely the text related to 'individuals 
view'.
repeating myself :), a good terminology/definition section will be 
helpful here.

|> - 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? 
|> 
|
|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 ...:)
Ok I see your point.

|> -Section 2.7
|> you mention "killer problems", I assume you meant killer reservation 
|> problems... 
|
|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 was more of an editorial comment to change "killer problems" into
"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.
|
|True. The evaluation of all protocols is still in a very early stage, 
|especially regarding YESSIR, Boomerang, Insignia, ...
|
Well if you need input on these and others I would gladly help.
 
|> -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?
|
|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.
I agree with you. Although interesting I do not think ITSUMO framework 
fits in this draft.

Regards,
Vlora

---

From: [email-masked]
Date: Mon, 18 Nov 2002 16:37:32 +0200

Hi Vlora,

> the RODA as I mentioned are already presented in conference. The most recent
> ones are:
> 

Any chance of weblinks for these, just to make my life easier.  Anyhow,
thanks for the references.

> any release of the code yet. 

No problem. 

> |as these are somewhat tangential to our purpose.
> Agreed. 

Good.

thanks for the comments,
John

---

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Mon, 18 Nov 2002 16:12:44 +0100

Hi John,

|Any chance of weblinks for these, just to make my life easier.  Anyhow,
|thanks for the references.
|
I'm afraid you'll have to check the proceedings as there
are no weblinks to full papers. 

Regards,
Vlora