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

From: Radhakrishna <[email-masked]>
Date: Thu, 13 Jul 2000 13:24:09 +0530

See my response inline.

....RK

> -----Original Message-----
> From:	Rute C. Sofia [SMTP:[email-masked]]
> Sent:	Wednesday, July 12, 2000 11:15 PM
> To:	Radhakrishna
> Cc:	[email-masked]'; [email-masked];
> [email-masked]'; [email-masked]'
> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> > > 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.
> >
> 
> 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...
	[Radhakrishna]  
	Good input. I will add it in next revision.

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

> - 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...
	[Radhakrishna]  
	Since the reservation is receiver intiated, you don't have these
issues.
	Also one thing we can do is to base setup on ResvConf message for
	intermediate nodes so that the session will not be established for
the
	receivers that are not up.

> >
> 
> >         may not be required to enforce admission control (in the case of
> > adequate
> >         provisioning). Aggegation is another mechanism to address the
> 
> >
> 
> :-). 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
> 
>

---

From: "Rute C. Sofia" <[email-masked]>
Date: Thu, 13 Jul 2000 11:01:35 -0500

>         receiver (say in case of multicast) can request PHB depending on its

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

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

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.

    Regards,
        Rute Sofia