Subject: RE: questions about draft-rk-diffserv-rsvp-sig-00

From: Radhakrishna <[email-masked]>
Date: Wed, 13 Dec 2000 08:58:47 +0530

Roberto Winkler,

Thanks for going through this I-D and the comments. I will be
putting a new revision of this I-D and hope it will address all
your questions. Attached below are the discussions we had in the
past, which I think addresses some of your questions.
I will try to answer others within couple of days.

I look forward for more comments.

....RK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 12, 2000 10:46 AM
To: [email-masked]
Subject: questions about draft-rk-diffserv-rsvp-sig-00

hello,

I maybe late, but I have some questions about your I-D in subject. Hope you
don't mind to receive them and to get clarifications from you.

1 - throughout the paper: is the sending sode (which the IP address in the
session identifier refers to) the source of the data flow or ER1/BR1 ?

3 - second paragraph on page 3 states that '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 the resources are
available' Is this intermediate node RSVP-able or what else ? More, with
reference to the same sentence, what's the reason (apart from reduced
processing inside the core) for letting Path and ResvConf messages flow
hop-by-hop, whereas Resv messages are edge-to-edge ?

4 - have you removed refresh timers both at the edges and in the core
DiffServ network ?

5 - why do you impose that 'Each DiffServ node allows a pre-configured
number of sessions' ?

6 - is R2 in Fig. 2 an RSVP-capable router inside the DiffServ domain ? If
not, then I fear I have understood nothing of your proposal. If yes, then
what's the advantage of your model wrt the one considered by ISSLS WP for
intserv over diffserv (with some RSVP-capable node in the Diffserv region)?
I may guess that you gain something in scalability for the reduced
processing burden (RSVP RESV are not processed inside the core) and the
probably faster scheduling (PHB-oriented), but is the effort of modifying
RSVP worth the goal ?

7 - where is the admission control module in figure 3 ?

8 - are the usual TSpec parameters in the PHB_PARAM element used for
admission control purposes ?

9 - are DS_SESSION and DS_FLOWSPEC objects created by the receiver or by
ER2/BR2?

This was lonfer than I thouth. Thank you very much for your patience and
best regards

Roberto Winkler
Senior Researcher
Fondazione Ugo Bordoni
Via B. Castiglione, 59
00142 Rome Italy

tel +39 0654803411
fax. +39 0654804404
e-mail [email-masked]

Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
From: Radhakrishna <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Radhakrishna <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Mon, 17 Jul 2000 18:41:22 +0530

See my response inline.

....RK

> -----Original Message-----
> From:	Rute C. Sofia [SMTP:[email-masked]]
> Sent:	Thursday, July 13, 2000 9:32 PM
> To:	Radhakrishna
> Cc:	[email-masked]'; [email-masked];
> [email-masked]'; [email-masked]'
> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> > >
> > > - you mention that the receiver, when getting the Path message,
> creates a
> > > DS
> > > session and generates an Resv that has info on the PHB. So, you
> suppose
> > > that
> > > the receiver (edge) has info on the PHB??  How will it know about it,
> > > shouldn't
> > > the sender be the one to have access to this information? Wouldn't it
> be
> > > better
> > > if the sender (edge *or* client host), knowing what it needs, asked
> > > (probed)
> > > the network for resources (bw, delay, etc)) according to services
> agreed
> > > and
> > > then classified the flows, thus already having the reservation
> > > established?
> >         [Radhakrishna]
> >         Even though you create a session on getting Path message, actual
> > reservation
> >         (allocation of resources) happens on the receipt of ResvConf
> > message.
> >         Since this is DiffServ domain, the edge node and the hosts on
> the
> > receiver
> >         side are aware of what PHBs are available (if they are not
> aware, it
> > does not
> >         matter. They can always request standard PHB suited for their
> > traffic and if the
> >         network does not support the request will be rejected), but they
> > won't know the
> >         actual resources (bw, buffers). Hence the receiver will signal
> the
> > required PHB
> >         along with the parameters through Resv message. The model is
> same
> >         as RSVP, but only difference is resource allocation happens with
> > ResvConf
> >         message. By doing this, there is no issue with the multicast
> because
> >         reservations are initiated by the receivers.
> >
> >         The sender can signal the desired PHB (PHB_ID), but it can not
> > signal the PHB
> >         parameters as it is not aware of what is there on receiver side.
> > Since the receivers
> >         are the ones to choose the PHB parameter values, it is better
> the
> > choice of PHB
> >         should be left to the receiver. This provides greater
> flexibility in
> > terms each
> >         receiver (say in case of multicast) can request PHB depending on
> its
> > capability.
> >
> 
> So, if I can understand, you intend to use RSVP as it works (receiver
> based) to
> do admission control on a model that needs this process on the edges of a
> defined domain, specially, that needs the edge on the sender side to know
> before any forwarding about services available...
	[Radhakrishna]  
	Yes, this model uses RSVP as it works and adds those capabilities
that
	are needed for PHB signaling and admission control.

> And what if we are speaking of sender/edge receiver/edge on different
> domains,
> the most likely case? How will this work with PHB, has you mention that
> the
> receiver will now about them? Also, if you mention that the receiver
> "will"
> find out about the SLA and PHB, then you are using simply a signaling
> protocol,
> but you still have to have something like a BB to mantain all the info
> about
> services...so, you withdraw from BB the process of edge configuring, but
> will
> not avoid having them...
	[Radhakrishna]  
	The receiver will request the required PHB through PHB_ID (RFC2836)
which
	works across domains. The edge nodes in different domains have do
appropriate
	remarking/mapping. The receiver does not need to know SLAs. If there
are appropriate
	SLAs exist to service the the request, it will be admitted,
otherwise it will be rejected.

> Another thing about your draft is that you always think of sender/receiver
> as
> being on the edge. What happens if sender/receiver are host clients?? How
> can
> they know about PHB? That is not mentioned in the draft, but in the DS
> model,
> it is clear that clients might be able to do traffic classification.
	[Radhakrishna]  
	The sender/receiver could be edge or host client. Since the
reservation is based on PHB_ID,
	it should work for both. In case of host client, the edge node has
to just do admission
	control based on SLA and the resources requested by the host client.

>     Regards,
>         Rute Sofia

Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
From: Radhakrishna <[email-masked]>
To: 'Ronaldo Salles' <[email-masked]>, Tarik Alj <[email-masked]>
Cc: [email-masked], [email-masked], Radhakrishna <[email-masked]>
Date: Wed, 12 Jul 2000 17:13:00 +0530

Your are right. The admission control procedures in the core
should be simple and scalable. However, by having limited sessions
and using them only for those applications which would benefit them
(for example VOIP applications where you can provision for few hundreds
voice calls in each node) will help to reduce the management burden.
One of goal of this draft to simplify the management of such sessions,
if at all they are required. For other applications, you could use simple
statistics based approach which may not be 100% accurate, but
better than nothing. Aggregation is other solution.

I think you missed some earlier discussions on these issues and have
attached them below.

Regards,
.....RK

> -----Original Message-----
> From:	Ronaldo Salles [SMTP:[email-masked]]
> Sent:	Wednesday, July 12, 2000 4:36 PM
> To:	Tarik Alj
> Cc:	[email-masked]; [email-masked]; Radhakrishna
> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> My point of view is that admission control procedures at the edges
> "should"
> indeed differ from the ones performed in the core (if any). According to
> the
> DiffServ's main concept each node in a DS-domain (ingress/egress/core) has
> different resposibilities and therefore intermediate nodes can not manage
> sessions/connections even in the "control plane". If we go in this
> direction
> we'll be moving from DiffServ to ... (IntServ?). Signaling is
> *definitively*
> not an issue carried out on  the DiffServ WG.
> On the other hand, a real DS-domain can not discard admission control and
> the work on "draft-rk-diffserv-rsvp-sig-00.txt" is very important in this
> sense.
> I think the question is more general: what's the role of core
> (intermidiate)
> nodes regarding admission control in a DS-domain?
> 
> regards,
> rms.
> 
	-----Original Message-----
	From:	Radhakrishna [SMTP:[email-masked]]
	Sent:	Wednesday, July 12, 2000 1:10 PM
	To:	[email-masked]'; Radhakrishna; [email-masked];
[email-masked]'
	Cc:	[email-masked]'
	Subject:	RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt

	See my response inline.

	.....RK

	>From: Jay Wang <[email-masked]>
	>To: "'Tarik Alj'" <[email-masked]>,
	[email-masked]
	>Cc: [email-masked], [email-masked]
	>Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
	>Date: Tue, 11 Jul 2000 12:26:29 -0700
	>MIME-Version: 1.0
	>
	>Well, I think the author's intend was to stress that the
	>admission control is "administered" or "coordinated" at 
	>the edge.  So that the application, such as the service 
	>management system, needs to ONLY interface with the edge 
	>nodes to enforce admission control.  Also for the question 
	>regarding how an intermediate node would check its resource 
	>availability, I am not sure how this is different from an 
	>edge node? When a session is set up, say by RSVP, along the 
	>way if the edge nodes know how to handle the accounting 
	>with respect to its resource, why can't the intermediate 
	>node do the same thing?

	I agree, but then, doesn't this adds complexity (scale, etc) to
session
	set-up?
		[Radhakrishna]  
		Yes, it does add some complexity when the intermediate nodes
are
		involved in admission control, but much less compared to
standard
		RSVP processing. If the network is adequately provisioned,
only
		edge nodes are enough to enforce the admission control.
		The resource availability is checked against the PHB and its
	parameter
		values requested in FLOWSPEC.

		The intermediate node is not very different from edge node
in terms
	admission
		control. But its role is only in keeping sessions and the
accounting
		information (how much bandwidth available for various PHBs),
so that
		it can involve in admission control. It is also possible
that
	edge/intermediate
		node can aggregate sessions that belong to same PHB based on
the
		destination address of the receiver edge node (the address
in
	ResvConf message).
		I know the aggregation mechanisms are not well explained in
the
	draft and I will
		add that in next revision. But the main intent of the draft
is to
	provide PHB signaling
		and admission control mechanisms with sub-set of RSVP
mechanisms, so
	that
		end hosts and edge nodes can take advantage without going
for
	complex IntServ to
		DiffServ mapping mechanisms.

		Also aggregation is not the only mechanism to address the
	scalability and complexity
		issues. We could use statistics based approach where you can
	maintain just one
		session (that has largest timeout value) per PHB and keep
monitoring
	the resource
		availability between ResvConf and Path messages of the
session.

	> From:	Rute C. Sofia [SMTP:[email-masked]]
	> Sent:	Wednesday, July 12, 2000 12:59 AM
	> To:	Radhakrishna
	> Cc:	[email-masked]'
	> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
	> 
	> Radhakrishna wrote:
	> 
	> > This draft is basically to add signaling and admission control
	> capabilities
	> > for
	> > Differentiated Services where in end hosts and access routers
can signal
	> the
	> >
	> 
	> Hi,
	> 
	> I have some questions and comments:
	> 
	> In section 1, you mention the use of a "DS session", but do not
explain
	> what
	> you mean by it...
		[Radhakrishna]  
		DS session no different from RSVP session, except that it is
	identified by
		sender address (host or edge node) and an identifier
assigned by the
	sender.
		This uniquely identifies the session in DiffServ network.

	> Also, in the same section, last paragraph where you say "unlike
standard
	> RSVP
	> processing...This simplifies the processing in intermediate
nodes...and
	> these
	> nodes mantain a simple state of whether a reservation is set up or
not".
	> 
	> So, there will still be the need of keeping status information on
each hop
	> along the way, per microflow...so, how will this scale??
		[Radhakrishna]  
		Yes, there is need for keeping status information leading to
	scalability problems,
		but the amount of information and the processing is much
simpler
	(processing
		of ResvConf message is enough to enforce admission control).
All the
	nodes
		may not be required to enforce admission control (in the
case of
	adequate
		provisioning). Aggegation is another mechanism to address
the
	scalability
		problem, where in edge nodes can aggregate the sessions (see
my
	response
		above).

	> In Section 4., aggregation and resource re-negotiation, you
mention the
	> possibility of using reservation aggregation. Shouldn't this be
more
	> explained,
	> how your model can be used considering RSVP aggregation? After
all,
	> DiffServ is
	> based in flow aggregation and so, mentioning admission control
	> per-microflow is
	> very necessary, but mentioning admission control per flow
aggregate is
	> also
	> necessary...
	> How can these new RSVP objects be integrated with the current RSVP
	> aggregation
	> work?
		[Radhakrishna]  
		Yes, aggregation is not well explained in this draft and I
will add
	more details in
		next version. The aggregation can be acheived based on
PHB_ID and
	the
		deaggregator (receiver edge node). By having edge node to
request
	for confirmation
		for all the Resv messages passing through it back to the
senders (or
	generated by it),
		any node in the network can aggregate the sessions belonging
to same
	PHB and
		destined to the receiver edge node.

		If you use statistics based approach explained above, you
don't need
	aggregation
		since will be maintaining only session per PHB (see my
response in
	the begining
		of this mail).

	> There are also some issues not mentioned on this draft, such has
behavior
	> related to path changes, possibility of duplicate reservations and
also
	> admission control in multicast scenarios, specially with
aggregation...
		[Radhakrishna]  
		Since session establishment is dependent on Path & ResvConf
message
		in forward path, and also the session is uniquely identifed
by
	sender's address
		and session identifier (assigned by the sender), as of now I
don't
	see any
		issues. But, I agree with you that these needs to be looked
in
	greater detail
		with possible scenarioes.

	> In section 7., there's a misspelling :-), "The use of ISPEC"
should be
	> "The use
	> of IPSec",
		[Radhakrishna]  
		Thanks, I will correct it the next version.

	>     Regards,
	>         Rute Sofia

> ----- Original Message -----
> From: Tarik Alj <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, July 11, 2000 9:30 PM
> Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> 
> 
> >From: Jay Wang <[email-masked]>
> >To: "'Tarik Alj'" <[email-masked]>,
> [email-masked]
> >Cc: [email-masked], [email-masked]
> >Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> >Date: Tue, 11 Jul 2000 12:26:29 -0700
> >MIME-Version: 1.0
> >
> >Well, I think the author's intend was to stress that the
> >admission control is "administered" or "coordinated" at
> >the edge.  So that the application, such as the service
> >management system, needs to ONLY interface with the edge
> >nodes to enforce admission control.  Also for the question
> >regarding how an intermediate node would check its resource
> >availability, I am not sure how this is different from an
> >edge node? When a session is set up, say by RSVP, along the
> >way if the edge nodes know how to handle the accounting
> >with respect to its resource, why can't the intermediate
> >node do the same thing?
> 
> I agree, but then, doesn't this adds complexity (scale, etc) to session
> set-up?
> 
> 
> Regards,
> 
> Tarik.
> 
> >
> >regards,
> >
> >- Jay Wang
> >
> >-----Original Message-----
> >From: Tarik Alj [mailto:[email-masked]]
> >Sent: Monday, July 10, 2000 8:46 AM
> >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?
> >
> >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/
> 
> 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)
>