Subject: RE: [NSIS] list of discussion points

From: "Chaskar Hemant (NRC/Boston)" <[email-masked]>
Date: Mon, 17 Dec 2001 14:57:01 -0500

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!

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

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

_______________________________________________
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: Behcet Sarikaya <[email-masked]>
Date: Mon, 17 Dec 2001 17:35:59 -0600

Hi Hemant,
  I agree with your comments. However, I kind of think that we are slipping
the attention further away from the main tasks of NSIS.
  The meeting at SLC was very positive as a first meeting and if we continue
and correctly scope the work, I think that the success is almost guaranteed!

  What I am getting at is that there has been several presentations on
various requirements which set the stage for a good requirements document
(including Marcus' contribution).
  Reducing the scope of requirements to RSVP v1 I think would be wrong. That
should come up at the solution step.

Regards,

--
Behcet