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

From: Radhakrishna <[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