At 11:56 AM 10/22/98 +0800, you (Tang Oo) wrote:
>>No changes should be made to TCP because of RSVP. RSVP does not guarantee
>>bandwidth or quality of service.
>why not? since call admission and resource reservation are done in RSVP, the
>
>bandwidth or QOS should guaranteed. I am not a expert in RSVP, so any ideas
>are welcome.
RSVP and diffserv are a best effort attempt to guarantee bandwidth, but you
are still sharing the bandwidth. Therefore you need congestion control.
Thus, no changes should be made to reduce or eliminate the congestion
control elements of TCP.
>>It is my understanding that RSVP will probably not be seen in the wide area
>>network and that differentiated services (diffserv) and/or a combination of
>>diffserv and ATM will reside in the WAN with RSVP at the edges.
>>(clarification and/or corrections to this statement are welcome.)
>
>>I you know you have locked up bandwidth (a VERY unique situation), you do
>>not need to have congestion control. I this case, you may wish to consider
>>other protocols instead of TCP.
>In my ouderstanding,RSVP is like ABR service in ATM, in which a certain
>bandwidth is reserved. But the application is still free to use the idle
>bandwidth whenever available. In this case, congestion control is needed and
>TCP will benefit from the reservation as well as best-effort service.
>
I agree.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:48 EST