Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt

From: Tarik Alj <[email-masked]>
Date: Tue, 11 Jul 2000 16:28:02 -0400 (EDT)

Please see comments inline. CC'ing ISSLL.

<... snip...>

>> 
>	[Radhakrishna]  
>	The first statement (page 6), I meant it only for data packets,
>where in
>	data packets are policed and conditioned for established sessions
>	(packets belonging to non-established sessions will be forced to
>	 Best Effort). May be admission control is not a right word here and
>	I will make this correction in next revision.
>
>	Regarding admission control (to establish a session or not), even
>the
>	intermediate nodes (if necessary) can be involved along with the
>edge
>	nodes. With this, the admission control will be better, but with
>some
>	signaling overheads (much less compared to standard RSVP
>processing).
>	However, there are no overheads in data path. The draft does not
>mandate
>	admission control (and RSVP processing) in every node.

	Maybe some precision about this should be added to the draft. To 
identify when such processing is necessary at intermediate nodes. 
	Also does the establishment of a session suppose the establishment of a 
path for a given session (e.g. packet of a given AF (fex) session would all 
follow the same hop by hop path)? This maybe restrictive and might not scale 
well.
	
>
>	The main intent of this draft is to -
>	(1) make end systems (hosts and access nodes) to signal the desired
>PHBs to
>	     the network (along with associated parameters), and

	Isn't this supposed to be done via DSCPs? Each packet carrying its own 
desired PHB? 

>	(2) network nodes can make use of simplified mechanisms (if
>required)
>	     to provide effective admission control
>
>	The key points to be observed in the draft are -
>
>	 (1) SESSION which is different from the ones used in IntServ. The
>session
>	      identifier assigned by the sender (host or edge node) is used
>to
>	      distinguish different sessions from the same sender. The
>sender can
>	      aggregate all the application flows that require same PHB on
>to same
>	      session and can re-negotiate the resources. The use of session
>identifier
>	      also helps to address the issue with NAT, Tunneling, etc.,
>which modify
>	      the IP headers.

	Then aggregation should be considered separatly? There are aggregation 
mechanisms for RSVP + DiffServ PDBs, these should be considered too?
	
>
>	 (2) FLOWSPEC which defines how PHBs and their associated parameters
>	      are signaled.
>
>	 (3) Less overheads, since the processing is much simplied with less
>	      messages (the intermediate nodes will process only Path,
>ResvConf
>	      and PathTear messages and does not need hop-by-hop forwarding
>	      mechanisms along the reverse path) and simplified states &
>objects.
>	      

	I think it would be interesting to do some sort of a "case study" where 
the draft would examine intra-DS-domain and inter-DS-domain use of RSVP as well 
as going through a non-DS domain. It would help clarify is really meant by "PHB 
signalling".

Regards,

Tarik.

Tarik Alj
INRS-Telecommunications
Place Bonaventure
900 De La Gauchetierre Ouest
Niveau C, Case Postale 644
Montreal, Qc, H5A 1C6
Canada

514 875-1266 #2036 (email preferred)