[thought] Rate-Control TCP (RC-TCP)

---------- Forwarded message ----------
Date: Tue, 21 Aug 2001 16:24:20 -0500 (CDT)
From: "Mitchell D. Theys" <mtheys@expedition.eecs.uic.edu>
Reply-To: mtheys@uic.edu
To: Shashank <shashank@evl.uic.edu>
Cc: evlnet@evl.uic.edu
Subject: Re: Need comments on ...RC-TCP


All:

I think in some cases the sender can cheat.
It depends on what type of service was purchased. If a minimum
guarantee was bought, then the user may at times exceed this.
If an average guarantee was given, of course it would
go below and above the average rate at any given time.

Something that needs to be considered here, is that such 
an infrastructure will not likely ever be completely in place
(Due to costs, existing infrastructure, etc.) I always think
of hdtv as a good example, people are not going to get rid of their
current television just because a better broadcast is coming now.
And they will be really mad if they have to get new hardware 
to watch television.

This doesn't mean the research discussed shouldn't be considered
or performed. But since you are in the planning stage you might
want to think about where the intelligence should reside.
Is there enough resources for decisions to be made in the routers?
ethernet connections? what about the edges? Maybe some distributed
scheme where intelligence appropriate to the location could exist, 
where more work is done on the edges and little adjustments reside
in the network. If this were the case, do we really need special hardware?
Can it be built ontop of the existing TCP networks?

Just a few thoughts.

Mitch



Shashank wrote:
*
*Hi All, 
*I just though of the below, and would appreciate if you can send me some
*comments regarding 
*--if something like this already exists,
*--if this is a workable solution
*etc..
*
*Its just a one page summary.. so please read it.
*
*Thanks and regards
*Shashank
*
*-----------------------------------------------------------------
*
*Rate Controlled TCP for Next Generation Internet
*-- Shashank Khanvilkar
*
*Traditionally TCP has played a very submissive role, when it comes to
*congestion. In other words, if congestion is detected, TCP will
*automatically reduce its transmission bandwidth to reduce the overall
*congestion in the network. In the current generation Internet, this
*behavior is necessary, failing which the network might go into unstable
*state leading to extreme variations in congestion.
*The result is that the end-consumer is the ultimate sufferer, while the
*network enjoys getting away without giving the right kind of service. This
*was acceptable till now, since all the traffic was treated as best effort,
*but this has to change in future. There has to be a paradigm shift from
*the traditional network-centric view to the consumer-centric view if QoS
*is to be guaranteed.
*For networks claming to support QoS, and having charging differentiation,
*consumers rights will need to be protected when it comes to achieving the
*bandwidth that they have payed for. The same old TCP thus cannot be used
*in this case, as the consumer will remain at a disadvantage when it comes
*to congestion. A new TCP-kind of protocol is needed which will be more
*aggressive when it comes to achieving the bandwidth that was purchased. 
*Let us call this new TCP, the Rate Controlled TCP or RC-TCP, whose main
*function will be, to guarantee that the purchased service is utilized to
*the fullest extent. With QoS architectures coming up, the end-consumer
*should no longer be concerned for congestion related outages, as it now
*falls upon the network provider to make sure that this kind of situation
*does not arise more often. 
*The RC-TCP will aggressively try to achieve the purchased bandwidth by
*possibly adopting different mechanism like: increasing window size, or
*send buffer size, or even opening another parallel socket etc.. If a
*congestion is encountered for a brief amount of time, then this protocol
*will make up for the lost period by sending more than the purchased
*bandwidth, but maintaining the average rate. Of course, since the
*bandwidth achieved is commensurate with the price paid, the consumer will
*not be able to cheat by sending more than what was purchased.
*The same idea might be applied to UDP streams or almost to any transport
*layer protocol. I am still thinking about how this can be introduced in
*the sessions layer, which will then be responsible for all these
*functions.
*
*
*
*
*
*


-- 
--------------------------------------------------------------------------
|  Mitchell D. Theys, PhD   |  Department of Computer Science (MC 152)   |
|    Assistant Professor    |  University of Illinois at Chicago         |
|  Email: mtheys@uic.edu    |  1120 Science and Engineering Offices      |
|  Phone: (312) 413-9267    |  851 South Morgan Street                   |
|  FAX:   (312) 413-0024    |  Chicago, IL 60607-7053, USA               |
--------------------------------------------------------------------------