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

From: Radhakrishna <[email-masked]>
Date: Tue, 11 Jul 2000 15:43:26 +0530

Since this is an area under ISSLL working group,
I am moving these dicussions to ISSLL mailing list.
However, see my answers inline.

Thanks for your inputs and looking forward to get more.

....RK

> -----Original Message-----
> From:	Tarik Alj [SMTP:[email-masked]]
> Sent:	Monday, July 10, 2000 9:16 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> 
> >From: "Ronaldo Salles" <[email-masked]>
> >To: "Radhakrishna" <[email-masked]>
> >Cc: <[email-masked]>
> >Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> ...
> >
> >Dear RK,
> >
> >On page 6 you say: "As shown in figure3, policing and admission control
> is
> >done *only* in edge/boundary nodes."
> >
> >On page 3 you say:"Each intermediate node along the path checks the
> >availability of resources on receipt of ResvConf message and passes the
> >ResvConf message to next node if resources are available ..." Isn't it
> >admission control? If yes, your first statement is wrong.
> >
> >regards,
> >rms.
> >
> 
> I support this remark. Furthermore I would like to ask, how would an 
> "intermediate node check the availability of ressources"?
> 
> I would have expected, given the DiffServ context, that admission control
> would 
> happen only at the edge; having the intermediate nodes make themselve
> heard by 
> the edge only if ressources become scarce.
> 
> This sort of session establishment looks a lot like a "simplified
> IntServ", 
> while it could be adequate for EF; isn't it too restrictive for AF
> service? 
> 
	[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.

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

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

> Regards,
> 
> Tarik.
> 
> 
> >
> >----- Original Message -----
> >From: Radhakrishna <[email-masked]>
> >To: <[email-masked]>; <[email-masked]>
> >Sent: Monday, July 10, 2000 6:12 AM
> >Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> >
> >
> >The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for
> >signaling and admission control in DiffServ networks. It also
> >defines the required RSVP objects. The use of RSVP as described
> >in this document simplifies the processing and can be used by
> >end hosts to signal the required PHBs to the network. It is also
> >useful to the network for admission control purposes and does not add
> >any overheads in data path. It also reduces the processing overheads of
> >RSVP messages.
> >
> >Please let me know whether anybody has similar idea and whether we
> >can improve this draft for adding admission control mechanisms to
> >DiffServ networks.
> >
> >Thanks,
> >.....RK
> >
> >The draft is available at -
> >>  http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt.
> >>
> >
> ...
> >diffserv mailing list
> >[email-masked]
> >http://www1.ietf.org/mailman/listinfo/diffserv
> >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> Tarik Alj
> 
> INRS-Telecommunications
> Place Bonaventure
> 900 De La Gauchetierre Ouest
> Niveau C, Case Postale 644
> Montreal, Qc, H5A 1C6
> Canada
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/