Subject: Re: [Diffserv] QoSSIG BOF

From: lewis <[email-masked]>
Date: Tue, 25 Jan 2000 11:19:00 +0800

Dear professionalism:

   I am not a RSVP expert like you all, but I'd like 

the QOS network become more concrete, so that we can 

use it as soon as possible! so keep trying this better!

   I also suggest the RSVP discussion may combine with the

packet classifier / packet scheduler ,since the heart of

QOS is that part: the TSPEC will map into the class for

classifier and scheduler, they are the executors!

we all know that the experiments on RSVP+WFQ or RSVP+CBQ are

not precise as we expected.
 
  Since some seniors want to make the signaling protocol
 
more suitable for QOS requirement (hierarchy...) , maybe we can invite
DR. 

"Hui Zhang" 's Lab to provide their opinions on coping the RSVP with
their

CSFQ and HFSC.

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Ping Pan <[email-masked]>
Date: Tue, 25 Jan 2000 07:04:32 -0500

> not precise as we expected.

RSVP and other proposals (BGRP, YESSIR...) are signaling protocols to
distribute resource information between end hosts and routers. But IMO,
they do NOT apply the actual reservation, packet queuing, buffer
management, scheduling and classification.

- Ping

---

From: Tal Anker <[email-masked]>
Date: Wed, 26 Jan 2000 16:12:05 +0200 (IST)

> management, scheduling and classification.

That is correct. However, the scaling of the reservation model is not only
a matter of the signaling protocol, but it also concerned with the other
elements, mentioned above, as to how well do they scale.

Thus, it will be interesting to know, apart from the debate wether RSVP
scales or not, if the elements that need to perform the actual reservation
can scale to up to the granularity of the QoS reservation signaled by
RSVP. Otherwise, what's the sense to reserve bw/delay for a microflow, if
the scheduling element in the core network can not support the guaranteed
reservation granularity?

- Tal.
-----------------------------------------------------------
Institute of Computer Science
The Hebrew University of Jerusalem,
Givat Ram, Jerusalem 91904
Israel

Phone: +972-2-6585706
Fax  : +972-2-6585439

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 27 Jan 0 8:16:17 JST

Tal;

> elements, mentioned above, as to how well do they scale.

Right.

> RSVP.

It was an interesting research topic to confirm everything scale.

The most aggressive part was to throw away GS as an overkill (but
note that CL is underkill and useless).

> Otherwise, what's the sense to reserve bw/delay for a microflow, if

Given the uniform end to end scalability, your terminology of
"core network" is improper.

							Masataka Ohta