Reduced TCP Window Size for Legacy LAN QoS Niko Färber July 26, 2000

Scenario: Single Switch LAN Voice is received from WAN File is loaded from file server Both have to go through buffer at output port T2 10/100 Legacy Switch Router File Server WAN bottle neck A E D C B

Outline TCP flow control basics Reduced TCP window size for legacy LAN QoS Simulation results based on ns Measurements on Stanford campus LAN Related work Future work

TCP Flow Control Basics TCP flow control based on window size W (number of packets source is allowed to send without ACK) Receiver can signal max. window size in ACK Steady state: W = BxD/N TCP does not know B, D, N! Use loss as implicit sign for congestion: B = 40 packet/sec D = 0.1 sec N = 2 connections Increase until loss Back off W=2

Reduced TCP Window Size No loss in throughput as long as output buffer is full – but a few packets are as good as many! Max. delay in LAN segment is 512 bit times TCP could operate in stop-and-wait mode (W=1)! If we allow a maximum delay of D MAX we can even be more generous, e.g., D MAX = 10 ms B = 10 Mbps 1460 Byte packets N=1 connection Advertised window in ACK can be reduced without knowledge of sender/receiver W = 8.56 packets

NS Simulation Scenario Voice traffic: UDP, 30 ms, 240 byte, 5 s Data traffic: 3 x TCP, 1024 x 1024 byte (1 MB), start after 1 s Links: 10 Mbps, full duplex, 0.1 ms delay Switch: 64 KB buffer TCP UDP switch host bottle neck

NS Simulation Results voice delay [ms] data throughput [Mbps] time [s] 64 KB 3 KB tcp start

Stanford Campus LAN elaine3 tree1 tree2 “Gateway” Campus LAN oolong 10-BASE-T Legacy Switch 100-BASE-T 10-BASE-T “File Servers” “VoIP Terminal” oolong> pftp 5555 –a –B4096 oolong> tcpdump host oolong > trace oolong> hping elaine3 –1 –i u30000 –d 240 –c 500 tree1> pftp 5555 oolong bigfile1 tree2> pftp 5555 oolong bigfile2 bottle neck

10-BASE-T Measurements voice delay [ms] data throughput [Mbps] time [s] 16 KB 4 KB tcp start

10-BASE-T Measurements (Cont) Window size = 2, 4, 8, 16, 32 KByte data throughput [Mbps] voice delay [ms] max mean min

100-BASE-T Measurements TCP window size = 4, 8, 16, 32, 64 KByte data throughput [Mbps] voice delay [ms] max mean min

Related Work Packeteer: PacketShaper Application classification (Web, SAP, …, VoIP) Bandwidth management policy Policy enforcement (TCP window size + ACK pacing) IETF: Subnet Bandwidth Management (SBM) RFC-2814, May 2000, now on standards track QoS in mixed legacy 802.3/802.3p LANs RSVP-based protocol for coordinating resource reservation between subnets and/or end systems Just signaling, not enforcement See WWW-links on project page!

Future Work More extended NS simulations Dynamic ACK modification Set window size a priori or based on delay measurements? Add traffic in reverse direction Add multiple hosts – simulate Netergy LAN Comparison with class based queuing … Look at patent by Packeteer Consider more complex LAN topologies When is cooperation between T2 modules necessary? How is cooperation done (e.g. RFC-2816)?

Conclusions Pros No changes at server or client required No changes to other hosts required No coordination between VoIP terminals required No/little loss in throughput for data Simple Cons Requires modification of ACKs depending on IP address and number of current connections Already used by Packeteer Does not extend directly to more general LAN topologies