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

From: Radhakrishna <[email-masked]>
Date: Wed, 12 Jul 2000 13:09:40 +0530

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

---

From: "Rute C. Sofia" <[email-masked]>
Date: Wed, 12 Jul 2000 12:45:29 -0500

>         This uniquely identifies the session in DiffServ network.

Ok, what I meant was that you didn't explained what it was in the draft...so,
in order to have the general idea, one has to read the whole draft...a better
approach would be to explain what you meant before using the term...

>         of ResvConf message is enough to enforce admission control). All the

Yes, this reduces the amount of processing when compared to RSVP. But there are
still some issues:

- 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?

- according to this method, what happens if there's a multimedia multicast
session, and the sender doesn't yet know where to ask for the info, i.e., where
the receivers are, if there are any receivers (setup phase)? Also, the
receivers will join and leave in a dynamic way...

:-). Humm, adequate provisioning in IP networks...
Aggregation might be thinked of as not another mechanism, but as a
complementary one, that might be more efficient when thinking of the DS control
plane, no?

    Regards,
        Rute Sofia