A Receiver-Driven Transport Protocol for the Web Rajarshi Gupta, Mike Chen, Steven McCanne, Jean Walrand UC Berkeley EECS

A Receiver-Driven Transport Protocol

for the Web

Rajarshi Gupta, Mike Chen, Steven McCanne, Jean Walrand

UC Berkeley EECS

INFORMS 2000 3/6/00Boca Raton, Florida

WebTP Project @ EECS-UC B

World Wide Web today is vast and vital

Mostly runs request-response HTTP over byte-stream TCP

WebTP is ALF-based, multi-layeredIncludes the User into the transport

control loopWe present here a proposed transport

layer that is receiver-driven


Why Receiver-Driven

Incorporating User Control

Application Controlled Retransmissions

Reduced Server State

Using processing power at Clients


Protocol Design Goals

A receiver-based schemeAmenable to ALFSits astride the IP layerInteracts well with TCP, and with other

WebTP flowsSeamless integration with higher

layers


Protocol Components

Sender-Receiver InteractionCalculating RTT at the ReceiverSender ActionsReceiver Window ControlReceiver Rate ControlRetransmission (receiver controlled)

Timeout Out-of-Order Arrivals


Sender-Receiver Interaction

Receiver is the controlling entityNo sense of connection Flow initiated by Receiver by

requesting first data objectALF-based naming mechanismFlow terminated by Receiver by not

requesting for any more objects“Soft-State” at Sender


RTT Calculation at Receiver

Sender-Based Receiver-based

S R

Packet / Ack

Timestamp

S R

heldtime

RTTs

RTTr + heldtime

SRTTnew = α SRTTold + (1 - α) RTT

heldtime2

RTTr + heldtime2


Flow Control at Receiver

WINDOW-BASED

Limits maximum amount of data in transition

Slow-StartAdditive Increase/

Multiplicative DecreaseRate of increase will be

biased by RTT

RATE-BASED

Additive Increase/ Multiplicative Decrease

Rate control based on window size rate = cwnd / srtt

Rate Control independent of cwnd rate = f (oldrate)


Sender (rate-based)

Sender Object Queue

Processor

<n,n+4>,r1 <n+5,n+6>,r2

[n][n+1]

[n+2] [n+4] [n+5][n+3]

1/r1 1/r1 1/r1 1/r2 1/r2

Sender

Receiver

[n+5 [n+6]

1/r2


Retransmission (timeout)

Occurs when no packet is received for a long period (w.r.t Current Rate)

timeout = 1/r + M. r = current rate new = old + (1-).|iat - 1/r |

M = tolerance parameter

Action: Cut window, Cut rateRequest again for first object in queue


Retransmission (out-of-order)

abcdefghijkl

hijkcdl

abcdefghijkl

Expected Object Queue (initial)

Expected Object Queue (after queue reordering)

Expected Object Queue (after out-of-order arrivals)Arrival Order

baefgRequested

Retransmissions

Retransmitted packets movedto Expected Positions

SRTT rate = 4

Expected Object Queue emulates the queue at the Sender


Experimental Setup

Used the ns network simulator

WebTP Message Agents implemented in ns

All calculations and control at receiver

Built-in TCP agents WebTP

WebTPTCP

TCP

TCP

TCP

WebTP

WebTP

Network


Single WebTP Flow

Details1.5 Mbps linkDropTail Queue

(queue limit 10)ObservationsEfficientStableNetwork-friendlyRate Plot for One WebTP Flow


Three WebTP Flows

*Efficiency* *Fairness*

Rate Plot Fairness Plot


One WebTP and One TCP Flow

*Efficiency* *Stability* *Fairness*

Rate Plot Fairness Plot


Conclusions

Motivation for WebTPArgued desirability of Receiver-driven

protocolDemonstrated a working solution to the

design problem outlinedEfficient, Stable and Fair flows - work

well when WebTP pkts are isolatedAcceptable interaction with TCP


Future Work

Need to tune various design parameters

Address performance issues across asymmetric connections

Hazards relating to server securityDynamically generated contentsExtensive testing of WebTP flow

control over Internet


Questions :-)

WebTP Home Page:http://webtp.eecs.berkeley.edu

Documents

A Receiver-Driven Transport Protocol for the Web Rajarshi Gupta, Mike Chen, Steven McCanne, Jean Walrand UC Berkeley EECS