G. A. Ramanujan, Amit Thawani*, V. Sridhar Applied Research Group, Satyam Computer Services Ltd, 3rd Floor SID Block, IISc Campus, Bangalore, INDIA 560012 {Ramanujan_GA, Amit_Thawani, K. Gopinath Department of Computer Science and Automation IISc Campus Bangalore, INDIA 5600012 From IWCMC 07 August Shing-Guo Chang
+ Intruduction + System Goals + Algorithm design + Experiment + Results + Conclusion
+ Thin client computing has been in computing niches until the desktop computing model emerged stronger in early 1990 s. + Some key benefits of thin clients. Reduction in desktop maintenance cost. Reduction in bandwidth costs for server centric applications.
+ More recently,computing in general has moved towards multimedia applications. + Thin client computing still has remained In graphic based circumstance. + For example: Receiving live feeds from a video conference while mobile and simultaneously receiving updates of weather condition and live entertainment audio feed from satellite radio depending on the current position as update by GPS.
Thin client feature rich thin client
+ The performance of TCP connection is heavily affected by UDP. Traditional data application such as http,ftp and telnet employ TCP. Real-time multimedia application such as video conferencing prefer UDP. + Need fairness and minimal QoS. Intermediate routers employ the appropriate packet scheduling mechanisms such as Class-Based Queuing. All router should employ the same scheduling mechanism with same parameter.
+ An alternative and easier way is to apply the admission control algorithm to UDP and TCP connection,for example: To provide users with meaningful and effective video presentation,the admission control interval should be long enough to avoid frequent video quality fluctuations. + Receiving minimal QoS Control TCP flows by obtaining state info. From receivers using receiver window control available in TCP
+ Make sure that packet loss ratio of UDP flows are reduced and throughput of TCP flows are either increased or remain same without applying the enhancement. Model a feature rich thin client capable of supporting many current and emerging technologies. Ex: Bluetooth,IPTV,GPS etc. As emerging technologies are moving toward multimedia content which have intrinsic requirements of low delay,low packet loss and less tolerable error.
We propose to study the interaction between TCP and UDP when the end system receiving data is a CPU resource constrained thin client. System is designed with the goal of achieving fairness among flows and yet guaranteeing a minimal QoS for flows.
+ Start with calculating the statistics number of TCP and UDP packets received and sent in that second. Make sure long enough interval and obtain a fair knowledge of the current dynamics. + Execute admission control algorithm and depending on whether there is more or less data than can be processed.
+ All the statistics of packet loss ratio and end to end delay given by α (current_values) + (1 α) (old_values) + Five case Case1:determine the number of available UDP packets. Case2 :severely lossy UDP flows. Case3 :Either severely lossy TCP flows or TCP flows whose end to end delay are more than the maxmum acceptable delay by the application.
Case4:UDP flows are lossy and the total number of packets received. Lost by its lossy nature. Case5:TCP flows are lossy and the total number of packets received. Lost by its lossy nature. + Case2 to case5 are under the condition of available UDP packets is less than CPU can process.
+ Let PUDP = Packet loss ratio of UDP flows, PTCP = Packet loss ratio of TCP flows, ETCP= End to end delay of TCP flows, Win = Receiver window size, MaxPKT_UDP = Maximum allowable UDP packets ThUDP = Threshold for acceptable UDP loss, ThTCP = Threshold for acceptable TCP loss T = current time, TPKT = Timestamp in packet, MaxPKT_TCP = Maximum allowable TCP packets RecvUDP = No of received UDP packets, RecvTCP = No of received TCP packets, + Max perceivable delay =Maximum tolerable delay by the specific applications + Available processing =Amount CPU resources available to process incoming packets. + Max packets =Maximum packets processable by the system in 1 sec. + AdmitPKT_TOTAL =Total number of packets available for processing after admission control. + K = 2 = constant factor mentioning the difference in processing UDP versus TCP packets.
+ If: RecvUDP > MaxPKT_UDP + AdmitPKT_UDP = MaxPKT_UDP + Else:....Case (1) + AdmitPKT_UDP = RecvUDP + PUDP = total dropped UDP/total sent UDP + PTCP = total dropped TCP/total sent TCP + ETCP = T - TPKT + If (Admitpkt_udp > Available processing) + If: PUDP <= ThUDP + Do nothing + Else:...Case (2) + PerINCREASE = (RecvTCP/MaxPKT_TCP) + Win = Win + (Win * PerINCREASE) + (The receiver window size changes is communicated implicitly by TCP protocol) + If: PTCP <= ThTCP && ETCP < Max perceivable delay + Do nothing + Else:.Case (3) + PerDECREASE = (RecvTCP/MaxPKT_TCP) + Win = (Win - (Win * PerDECREASE))/K + (The receiver window size changes is communicated implicitly by TCP protocol)
+ If: PUDP >= ThUDP && RecvUDP > RecvTCP + && AdmitPKT_TOTAL > Max packets...case (4) + PerINCREASE = (RecvTCP/MaxPKT_TCP) + Win = (Win + (Win * PerINCREASE))/K + (The receiver window size changes is communicated implicitly by TCP + protocol) + Else if: PTCP >= ThTCP && RecvUDP < RecvTCP + && AdmitPKT_TOTAL > Max packets Case (5) + PerDECREASE = (RecvTCP/MaxPKT_TCP) + Win = Win - (Win * PerDECREASE) + (The receiver window size changes is communicated implicitly by TCP + protocol)
Compute: Calculate the no of packets received from each flows. Assign an initial higher priority to UDP flows Monitor flows for every 1 second interval Repeat: go to compute after every 1 sec to get new aggregate statistic and evaluate changes. The above defined calculations are carried out for every flow and adjustments are sent to every flow.
+ Using network simulator NS-2.30. + Ten servers stream. Contain up to ten streaming multimedia data and Contain up to ten streaming transmitting TCP data. + Connection contained a mix of wireless and wired links, also contained a mix of real time and non real time flows. + CPU considered 500MHz.
TCP overflow condition : five TCP sources each sending data with three wired and two wireless. Two of wired soures had a link capacity of 20 Mbps while one had a link capacity of 50 Mbps. The wireless sources had mobility enabled and where in transmission range for 75% of simulation time. UDP overflow condition : Three UDP sources streaming real time data with two wired sources,each of capacity 20 Mbps and a wireless source with a propagation delay of 100 ms.
The UDP packets are controlled through admission control and TCP sources without any loss. Fig 3 and Fig 4 show the results for case1 and case2
UDP flows are either almost zero or they are effectively controlled to ensure complete reduction in packet loss. Fig 5 and Fig 6 show the results for case 3 and case 4
The transmission of data with the algorithm is delayed due to the applied controlling factor, however on the average case the reduction in packet loss ratio is achieved. Fig 7 show the result for case 5
Fig 10.Some resource out of transmission range. Fig 11.the algorithm allows or enables the transmission of a burst of data. Fig 9,Fig 10 and Fig 11 show the results for delay variations
+ The algorithm does not affect the normal performance of thin client and provides a fair distribution of bandwidth across flows and satisfy minimal QoS regardless of the condition of either overflow or underflow.