Subject: Re: [NSIS] list of discussion points

From: [email-masked]
Date: Mon, 17 Dec 2001 13:51:11 +0100

I would suggest to add CPU use and manageability to the scalability
concerns

Sven.

Roland Bless <[email-masked]> on 17/12/2001 13:40:32

  To:          Marcus Brunner <[email-masked]>          
                                                              
  cc:          [email-masked](bcc: Sven VAN DEN                
               BOSCH/BE/ALCATEL)                              

  Subject      Re: [NSIS] list of discussion points           
  :                                                           

Marcus Brunner <[email-masked]> wrote:
> - scalability: in what???

This is an essential feature. I would suggest:
 - in number of (transit) signaling messages
 - in number of installed reservation states

> -signaling across multiple administrative domains
>    (Karagiannis (no), others (yes)
>    out of scope of NSIS?

I think that this is definitely required.
For many admission control scenarios it should be
possible to have real end-to-end signaling which
spans multiple domains.

> -independence of data and signaling path (or not?)

IMHO independence should be preferred, but in this case
the control plane should know what the actual data path
is. It would be nice to remove the signaling processing
burden from routers and to keep the "signaling processing
nodes" out of data path processing.

Regards,
 Roland

[looking forward to the meeting minutes...]

--
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097

_______________________________________________
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: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 17 Dec 2001 17:41:06 +0100

Hi Michael 

Some comments on your remarks!
GK = Georgios Karagiannis
MT = Michael Thomas

GK > Therefore, we should first identify the scenarios where the 
GK > RSVP (version 1) cannot be applied.
GK > >From the different proposals I can distinguish some scenarios already:
GK > * Mobile IP;
GK > * PSTN gateways;
GK> * IP-telephony
GK > * Radio Access Networks
GK > * QOS for IP-sec Virtual Private networks

MT>   "Cannot apply" is awfully broad. 

Agree, it should be "cannot be efficiently applied"!
 
MT>  I'm pretty 
MT>   sure that RSVP can be used in many or all of the
MT>   scenarios you mention. 

People that are working with these scenarios have a different
opinion!

MT>   Far better at this point would be to enumerate
MT>   *actual* problems in deploying RSVP for *actual*
MT>   situations. I do not think that there's any 
MT>   consensus about what is actually broken/inadequate
MT>   with RSVP right now, and I know for sure there's
MT>   a lot of FUD surrounding the topic.

These "actual" situations are the scenarios I have mentioned!

 GK > General comments: 
 GK  > In my opinion we should:
 GK > * first: specify the scenarios where the NSIS QoS protocol will be used;
 GK > * second: per scenario define the QoS requirements;
 GK > * third: per scenario collect mandatory and optional requirements;
 GK  > * fourth: create a modular QoS signaling toolkit that will contain 
 GK >   these mandatory and
 GK >   optional requirements;
 GK > * fifth: specify how the protocol functionality should be separated in 
 GK >   building blocks and define a minimum set of mandatory reservation 
 GK >   options/features that should be processed by interior/intermediate nodes;

MT>  I'm afraid that until we tease apart what the
MT>   current state of affairs is with RSVP and the 
MT>   new uses we'd like to apply signaled QoS, it's
MT>   rather pointless to talk about toolkits, requirements,
MT>   and how a potentially new signaling protocol should
MT>   work. 

Many people agree that for certain scenarios 
a new QoS signaling protocol is needed!
See for example the outcome of the NSIS BOF at IETF'50!
This is summarized in the draft written 
by Scott Bradner and Allison Mankin entitled:
"Report of the Next Steps in Signaling BOF" and located at:      
 http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt

MT>   It's certainly possible that some inadequacies of
MT>   RSVP stem from design assumptions which cannot
MT>   be broken at this point with RSVP. However,
MT>   before we posit any new signaling protocol, it
MT>   must be shown which design premises RSVP made
MT>   led to unfortunate/problematic behavior in 
MT>   important scenarios/deployments, and how by 
MT>   changing that premise we could design an NSIS
MT>   which better accommodated those scenarios. 
MT>   Also: we would also need to determine whether 
MT>   the engineering tradeoffs cause inadequacy in
MT>   other areas.

Agree!
   
GE > >> -Authentication of reservation
GE > >>	-who needs to be authenticated (host, IP interface, user)?
GE > >>	-to whom (proxy, one or multiple networks)?
GE > I think the interior/intermediate nodes do not need to 
GE > perform any security, accounting, charging functionality.
GE > Other specific entities, such as access nodes, edges, proxies
GE > may do!

MT>   This is unclear. The current cross-realm
MT>  authentication mechanism is not clear. This
MT>   is unfortunately a generally applicable
MT>   statement, but it is one of the big things
MT>   on my list of things that needs to be settled
MT>   here.

I think that security, accounting and charging functionality 
may be performed by specific entities, such as access nodes, 
edges, proxies, but not by interior/intermediate nodes!

 GE > >> - Multicast (greis, pan) <-> no multicast (others)
 GE > 
 GE > I think that the first version of RSVP provides multicast.
 GE > The NSIS protocol should be much more simple therefore, 
 GE > I would skip the multicast feature!

MT>   Are you sure? Wireless is very interested in 
MT>   preserving bits in the air, and multicast
MT>   definitely provides that capability for many
MT>   content classes which may very well be
MT>    interesting for wireless devices. 

Not on IP layer multicasting!

Best regards,
Georgios

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 18 Dec 2001 14:33:01 +0100

Hi Hemant

I did not mean that we should go for a completely different 
signaling protocol.
What I meant is that the NSIS QoS protocol should not be a replacement 
of the RSVP (version 1) protocol. If the NSIS QoS protocol would be a replacement
of the RSVP (version 1) then it will mean that the 
NSIS QoS protocol will be more complex, heavier and 
slower than RSVP.

We might use RSVP (version 1) as a starting point for the design
of this NSIS QoS protocol that will be for example,
simple, scalable (see definition on my e-mail from yesterday)
very fast, sender initiated, unicast, bi-directional, adapts to 
severe congestion, ....

Best regards,
Georgios 

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:[email-masked]]
Sent: maandag 17 december 2001 20:57
To: 'ext Georgios Karagiannis (ELN)'; Marcus Brunner; [email-masked]
Subject: RE: [NSIS] list of discussion points

Hi Georgios:

I agree with the view that new protocol should be designed only if RSVP
(v1 + enhancements such as RFC 2998) is deemed inefficient for certain
scenarios. However, it may be useful to study if additional
modifications to RSVP can solve the problem, before going for the
completely new protocol. For this, it might be worthwhile to create a
wish list of the modifications to RSVP to solve these problems. If the
wish list can be fulfilled with practical mechanisms, well and good.
Otherwise, we have to go for a completely different signaling protocol.

Hemant

-----Original Message-----
From: ext Georgios Karagiannis (ELN)
[mailto:[email-masked]]
Sent: Monday, December 17, 2001 9:22 AM
To: Marcus Brunner; [email-masked]
Subject: RE: [NSIS] list of discussion points

Hi Marcus

Before going into the discussion of the points you sent, 
I would like to emphasize that the NSIS QoS protocol should not 
be a replacement of the RSVP (version 1).

RSVP (version 1) is a very good protocol that can be used in many
scenarios 
and for many applications.
In my opinion the NSIS QoS protocol should be used in the scenarios
where the RSVP (version 1) cannot be applied.

Therefore, we should first identify the scenarios where the 
RSVP (version 1) cannot be applied.
From the different proposals I can distinguish some scenarios already:
* Mobile IP;
* PSTN gateways;
* IP-telephony
* Radio Access Networks
* QOS for IP-sec Virtual Private networks

Just some quick remarks on the points you sent 
earlier this week!
General comments: 

In my opinion we should:
* first: specify the scenarios where the NSIS QoS protocol will be used;
* second: per scenario define the QoS requirements;
* third: per scenario collect mandatory and optional requirements;
* fourth: create a modular QoS signaling toolkit that will contain 
  these mandatory and
  optional requirements;
* fifth: specify how the protocol functionality should be separated in 
  building blocks and define a minimum set of mandatory reservation 
  options/features that should be processed by interior/intermediate
nodes;

Below some more remarks!
Best Regards,
Georgios

-----Original Message-----
From: Marcus Brunner [mailto:[email-masked]]
Sent: donderdag 13 december 2001 15:56
To: [email-masked]
Subject: [NSIS] list of discussion points

>> -Decouple the information carried from the protocol carrying it
>>	-what is the boundary, e.g., reservation lifetime,
>>	 (attribute of reservation itself <-> softness/hardness of
>>	 the state of the protocol )

I think that it will be good to have this decoupling. However, at the
moment 
we can not specify this information;

>> -Authentication of reservation
>>	-who needs to be authenticated (host, IP interface, user)?
>>	-to whom (proxy, one or multiple networks)?

I think the interior/intermediate nodes do not need to 
perform any security, accounting, charging functionality.
Other specific entities, such as access nodes, edges, proxies
may do!

>> -Modularity
>>	-a single solution with components  (selection can be
>>	 negotiated)
>>	-a single solution with components that can be selectively
>>	 ignored without harming interoperability (at some reduced
>>	 level of performance/whatever)
>>	-a toolbox out of which solutions can be created to match
>>	 individual scenarios (e.g. adding QoS to MIP, adding QoS
>>	 so seamoby ?)

This is related to:
* create a modular QoS signaling toolkit that will contain 
   mandatory and optional requirements;
* specify how the protocol functionality should be separated in 
  building blocks and define a minimum set of mandatory reservation 
  options/features that should be processed by interior/intermediate
nodes;
  The same can be applied for access nodes, edge nodes, proxies, etc.,

>> - Multicast (greis, pan) <-> no multicast (others)

I think that the first version of RSVP provides multicast.
The NSIS protocol should be much more simple therefore, 
I would skip the multicast feature!

>> - integration with layer 2
>> 	-prevent duplication of functionality
>> 	-initiator is not directly connected to the link (NSIS
>> 	 signalling has to carry some link related information)
>> 	-the initiator is directly connected to the link, we might
>> 	 end up with the same logical information being signalled
>> 	 semi-consistently at two layers in the system, making life
>> 	 very hard for the implementations

I do not know what you mean here? Integration with layer 2
will introduce additional complexity and it will depend on
the type of the layer 2.

>> - integration with application signaling
>>	-prevent duplication of functionality
>>	-SIP/SDP interworking with NSIS

I do not know what you mean here? Integration with application 
signaling? Would you want to integrate SIP into the NSIS QoS 
protocol? I disagree!

>> - scalability: in what???

Well, scalability can be roughly defined as the feature that
shows how the performance of a system is affected by increasing the 
number of users. Related to resource reservation protocols, the main 
issue that affects scalability is the number of reservation states.
In the ideal situation, the number of reservation states is independent
of 
the number of users.
There is a new concept, that we developed called Resource Management 
in Diffserv (RMD) where the interior/intermediate nodes just keep 
one reservation state independent of the number of users. 
Thus even if there will be one million users there will just be 
one reservation state.
However, the RMD concept performs per flow management!

>>	(Karagiannis (no), others (yes)

I think that both scenarios should be considered, i.e., in a 
single domain and across multiple administrative domains!

>> -number of signaling protocols
>>	-one
>>	-more
>>	-one signaling transport plus toolbox

We can decide this after we identify the scenarios and the 
requirements per scenario!

>> -simplicity
>>	-Greis emphasises simplicity in mobile hosts (processing
power)
>>	-Karagiannis emphasises simplicity in the network

We should go for simplicity in 
the interior/intermediate nodes;

>> -layer alignment
>>	-Greis emphasises closeness to applications
>>	-Karagiannis implies ease of mapping within interior nodes,
>>	 i.e. at lower layers, forcing more interpretation work
>>	 into the initiators

I do not know what you mean here!
In our draft we emphasized that simplicity within interior/intermediate 
nodes is very important. We are not relating this simplicity with 
lower layers!

>> -independence of data and signaling path (or not?)

I totally disagree with the requirement of having 
independent data and signaling path!
If this feature  is adopted it will make the NSIS QoS 
protocol inapplicable on 
at least the following scenarios: 
Mobile IP, Radio Access network, IP telephony, ....

--------------
What about other requirements, such as 
* uni-directional versus bi-directional;
* fast resource reservation (required for fast handoff);
* adaptation to severe congestion 
* manageability;
* on demand versus static;
* sender initiated versus receiver initiated;
* .....

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 20 Dec 2001 14:15:33 +0100

Hi Marcus

These scenarios impose certain requirements on the QoS 
signaling protocols.

We are now trying to make a list of these requirements.
However, I do  not know if this list will be ready before the 
Christmas holidays.

best regards,
Georgios

-----Original Message-----
From: Marcus Brunner [mailto:[email-masked]]
Sent: donderdag 20 december 2001 13:58
To: Michael Thomas; Georgios Karagiannis (ELN)
Cc: [email-masked]
Subject: RE: [NSIS] list of discussion points

--On Monday, December 17, 2001 8:07 AM -0800 Michael Thomas <[email-masked]> 
wrote:

> Georgios Karagiannis (ELN) writes:
>    "Cannot apply" is awfully broad. I'm pretty
>    sure that RSVP can be used in many or all of the
>    scenarios you mention. Of the things you mention,
>    the only one that seems problematic is mobility
>    with fast handoffs, which is just a subset of
>    mobile IP applications.

Goergios, any everybody else.
Can you refine the problems in the particular scenarios you mentioned. I 
think Mike is right, as it stands here it does not help.

Marcus

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155