Subject: RE: question: DiffServ versus RSVP

From: Jay Wang <[email-masked]>
Date: Thu, 14 Sep 2000 18:32:37 -0700

> -----Original Message-----
> From: Youhao Jing [mailto:[email-masked]]
> Sent: Thursday, September 14, 2000 5:51 PM
> To: Jay Wang
> Cc: Lloyd Wood; jie yang ee stnt; [email-masked]; [email-masked]
> Subject: RE: question: DiffServ versus RSVP
> 
> 
> >On Thu, 14 Sep 2000, Jay Wang wrote:
> >
> > 
> > 
> > > -----Original Message-----
> > > From: Youhao Jing [mailto:[email-masked]]
> > > Sent: Thursday, September 14, 2000 12:44 PM
> > > To: Lloyd Wood
> > > Cc: jie yang ee stnt; [email-masked]; [email-masked]
> > > Subject: Re: question: DiffServ versus RSVP
> > > 
> > > 
> > > On Thu, 14 Sep 2000, Lloyd Wood wrote:
> > > 
> > > > On Thu, 14 Sep 2000, Youhao Jing wrote:
> > > > 
> > > > > >On Thu, 14 Sep 2000, jie yang ee stnt wrote:
> > > > > > 
> > > > > > I agree with RSVP is a signaling protocol, But I can't 
> > > agree that
> > > > > > Diffserv doesn't need RSVP. Actually at edge router, it 
> > > absolutely needs
> > > > > > a signaling protocol. RSVP maybe a good choice. 
> > > > > 
> > > > > DiffServ is intented to provide edge-to-edge QoS, not 
> > > end-to-end as RSVP
> > > > > does.
> > > > 
> > > > RSVP does not provide end-to-end QoS. It's a signalling 
> > > protocol, not
> > > > an enabling mechanism.
> > > 
> > > Agreed. What I meant was RSVP/IntServ.
> > > 
> > > -Youhao
> > > 
> > 
> > In any case, I don't think the comparison is meaningful.
> > Diffserv and RSVP are apple and orange.
> 
> Jay, please see the full version of my original response. The
> message I wanted to convey is both DiffServ and RSVP/IntServ
> have their limitations, and there has been work going on trying
> to integrate them to get end-to-end QoS. 
> 
> -Youhao
> 

Youhao, I did not feel the exchanges were fruitful because
for one thing, I don't think this end-to-end vs. edge-to-edge 
argument makes much sense. There is nothing, IMHO, in Diffserv
architecture that prevents us from having a DS domain that covers
"end-to-end". Can a CPE, connected to an "edge" through a 
point-to-point or switched technologies, adopt a network processor 
that is DS enabled, absolutely yes. 

On top of that, Diffserv was created to get Intserv-like effect 
without per-flow (hence very stateful) signaling. It is done, instead,
by way of an aggregated, and per-hop, manner.  That is why someone 
else had pointed out that the spirit of Diffserv is to alleviate the 
burden of flow-based signaling using things like RSVP, but this does 
not means that Diffserv can not work with RSVP. RSVP is a more of a 
choice of convenience than necessity (particularly when it comes to a 
bandwidth-ridden MPLS-LSP setup). In other words, it is MPLS-LSP setup 
which needs RSVP (or the like) signaling support. To get the desired 
QoS for the LSP does not necessarily have to. 

cheers,

- Jay

> > 
> > - Jay
> > 
> > > > 
> > > > L.
> > > > 
> > > > 
> > > 
> <[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
> > > > 
> > > > 
> > > 
> > 
>

---

From: Youhao Jing <[email-masked]>
Date: Fri, 15 Sep 2000 08:11:03 -0700 (PDT)

> that is DS enabled, absolutely yes. 

Just to make my point clear:

DiffServ, by aggregating flows into classes and dealing them with
PHBs, avoided IntServ/RSVP scaling problems, thus became
attractive to service providers. By using a consistant
queuing/dropping treatment for each aggregate from backbone network
ingress edge where flow classification occurs to egress edge, DiffServ
provide Class of Service at per-aggregate level. However, as a trade-off,
it's my understanding that DiffServ lost or at least difficult in
providing fine quality control between senders and receivers of each
flows. That's what I meant by "end-to-end" QoS.

> not means that Diffserv can not work with RSVP. 

Indeed, as I pointed out in my original email, people have been
investigating the ways to make DiffServ works with RSVP to achieve
end-to-end QoS.

-Youhao

> RSVP is a more of a