Tài liệu Experiences in Design and Implementation of a High Performance Transport Protocol doc

Experiences in Design and Implementation of a High Performance Transport Protocol Yunhong Gu, Xinwei Hong, and Robert L.. TCP and AIMD• TCP has been very successful in the Internet – AIM

Experiences in Design and Implementation

of a High Performance Transport Protocol

Yunhong Gu, Xinwei Hong, and Robert L Grossman

National Center for Data Mining

TCP and AIMD

• TCP has been very successful in the Internet

– AIMD (Additive Increase Multiplicative

Decrease)

• Fair: max-min fairness

• Stable: globally asynchronously stable

• But, inefficient and not scalable

– In grid networks (with high bandwidth-delay product)

• RTT bias

Efficiency of TCP

1 Gb/s link, 200ms RTT, between Tokyo and Chicago

28 minutes

On 10 Gb/s link, 200ms RTT, it will take 4 hours 43

minutes to recover from a single loss.

TCP’s throughput model:

p RTT

S

2 3

UDT – UDP-based Data Transfer Protocol

• Application level transport protocol built above UDP

• Reliable data delivery

UDT Architecture

DATA

ACK ACK2 NAK

UDT – Objectives

• Goals

– Easy to install and use

– Efficient for bulk data transfer – Fair

– Friendly to TCP

• Non-goals

– TCP replacement

– Messaging service

• Acknowledging is expensive

– Packet processing at end hosts and routers

– Buffer processing

• Timer-based selective acknowledgement

– Send acknowledgement per constant time (if there are packets to be acknowledged)

• Explicit negative acknowledgement

(  log(  ( ))   



UDT: Efficiency and Fairness Characteristics

• Takes 7.5 seconds to reach 90% of the link capacity, independent of BDP

• Satisfies max-min fairness if all the flows have the same end-to-end link capacity

– Otherwise, any flow will obtain at least half of its fair share

• Does not take more bandwidth than

concurrent TCP flow as long as

6 /

108

2 2





L SYN RTT

0 10 20 30 40 50 60 70 80 90 100 0

• Fair bandwidth sharing between networks with

different RTTs and bottleneck capacities

– 330 Mb/s each for the 3 flows from Chicago to Chicago Local via 1Gb/s, Amsterdam via 1Gb/s and Ottawa via 622Mb/s

Fairness and Friendliness

50 TCP flows and 4 UDT flows between SARA and StarLight

Realtime snapshot of the throughput

The 4 UDT flows have similar

performance and leave enough space for TCP flows

• Impact on short life TCP flows

– 500 1MB TCP flows with 1-10 bulk UDT

flows, over 1Gb/s link between Chicago and Amsterdam

• Stability index of UDT and TCP

– Stability: average standard deviation of throughout per unit time

– 10 UDT flows and 10 TCP flows with different RTTs

Implementations Issues

• Efficiency and CPU utilization

• Loss information processing

• Memory management

• API

• Conformance

Efficiency and CPU utilization

• Efficiency = Mbps/MHz

• Maximize throughput

– Use CPU time as little as possible, so that CPU won’t be used up before network bottleneck is reached

– Remove CPU burst, which can cause packet

• Minimize CPU utilization

Loss Processing

• On high BDP networks, the number of lost

packets can be very large during a loss event

• Access to the loss information may take long time

• Acknowledge may take several packets

Loss Processing

• UDT loss processing

– Most loss are continuous

– Record loss event other than lost packets

– Access time is almost constant

connect(client, (sockaddr*)&serv_addr, sizeof(serv_addr));

{

//error processing

}

• CPU usage of UDT and TCP

– UDT takes about 10% more CPU than TCP

– More code optimizations are still on going

• We explained the design rationale and implementations details in this paper

– Paper on Gridnets '04 workshop

• UDT open source project

– http://udt.sf.net

Thank you!

Questions and comments are welcome!

For more information, please visitBooth 653 (UIC/NCDM) at Exhibition Floor

UDT Project: http://udt.sf.net