RE: [NSIS] list of discussion points

["Georgios Karagiannis (ELN)" <[e-mail]>]

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

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