1. End-end congestion control: window-based congestion control Sending transport entity maintains congestion window over sequence number space  can send a packet if packet seq. # in window  distinct from flow control window On timeout  loss assumed  decrease congestion window size  increase timeout value (in case packet was delayed) ACK received: increase window size  everything is OK, so allow even larger window Copyright 1998. All Rights Reserved, J. Kurose, D. Towsley.

2. End-end congestion control: TCP Uses window-based congestion control Two variables used  cwnd: congestion window size  ssthresh: threshold for slowing down rate of increase TCP slow start + congestion avoidance:  assume 4K segment size  TCP window size = min(flow control window size, congestion control window size)

3. initialize: cwnd=1 ssthresh=16 ssthresh=16 loop: if (ACK received and cwnd <= ssthresh) cwnd = cwnd+1 cwnd = cwnd+1 else if (ACK received and cwnd > ssthresh) else if (ACK received and cwnd > ssthresh) cwnd = cwnd + 1/cwnd cwnd = cwnd + 1/cwnd else if packet timeout else if packet timeout ssthresh = cwnd/2 /* new thresh half ssthresh = cwnd/2 /* new thresh half current win */ current win */ cwnd = 1 /* new window size back cwnd = 1 /* new window size back to 1 */ to 1 */forever

4. Network-indicated Congestion Control Window-based control strictly end-end  network layer not involved, but congestion occurs in network layer! One network-indicated approach: network "marks" packets passing through congested node  receiver sees congestion indication mark and tells sender to slow down  congestion-experienced flag in ISO CLNP, CWI (change window indicator) in IBM SNA virtual route pacing

6. Network-indicated Congestion Control (cont) Second network-indicated approach: upon detecting congestion, congested router sends explicit message back to traffic sources to slow them down  text: choke packets  source quench in ICMP (Internet control message protocol)  VR-RWI bit in SNA VR pacing

7. Network Indicated Congestion Control: Difficulties Receiver-initiated control may have long feedback time in high-speed networks  sender may have 1000’s sent (but unACKed) packets before congestion indicator receiver  pipe filled already Both approaches require coupling of network and transport layer  OK for homogeneous networks  difficult in internetworked environment, with different network layers

8. Rate-Based congestion control  congestion control particularly hard in high-speed networks  e.g.,: 1 Gbit. sec link, 1Kbyte packet takes 8  sec to transmit  thousands of packets "in the wire" propagating cross country  when congestion occurs, too late to react  avoid congestion by regulating flow of packets into network  smoother flows will avoid bursts of packets from different senders arriving at same node and causing congestion  smooth out packet bursts at network edge on per session basis before they enter network.

9. Rate Based Congestion Control: Leaky Bucket Goal: regulate rate at which sender can inject packets into network

10. Rate Based Congestion Control: Leaky Bucket Goal: regulate rate at which sender can inject packets into network  a packet must match up with (and remove ) a token before entering network  tokens added to bucket at rate r: controls long term rate of packet entry into network  at most b tokens accumulate in bucket. Bucket size b control "burstiness" of arrivals  maximum number of packets entering network in t time units is b+rt  XTP uses rate and burst parameters analagous to r,b

11. Congestion control by Buffer Preallocation  lack of buffering in network is fundamental cause of congestion  avoid congestion by allocating buffers to an end-end connection  if insufficient buffers for a new connection, block it (as in circuit switching)  buffers dedicated to connection, link still shared  protects behaving connections from misbehaving one  data link layer involved in transport layer congestion control

12. Congestion Control in ATM ABR Service ATM ABR (available Bit Rate) service:  allows sender to send at rate up to a peak cell rate (PCR)  guarantees a rate of at least minimum cell rate (MCR) when needed  sender rate may fluctuate between 0 and PCR, depending on sender need, network congestion  provides max-min fairness among sessions Congestion Control in ABR service:  combines aspects of rate-based and network- indicated congestion control

13. ATM ABR Congestion Control: EFCI EFCI: explicit forward congestion indication  based on negative feedback ("bad things are happening") to sender  congested node (queue length > threshold) marks EFCI bit in sender-to-receiver cell  receiver sees EFCI set and notifies sender  sender decreases cell rate:  ACR: allowed cell rate ACR = max(ACR * multiplicative decrease, MCR) ACR = max(ACR * multiplicative decrease, MCR)  sender increases cell rate if no negative feedback in an update interval: ACR = min(ACR+ additive_increase, PCR) ACR = min(ACR+ additive_increase, PCR)

14. ATM ABR Congestion Control: explicit rates Sender declares every N-th cell as "RM" cell  RM: resource management  records its PCR, allowed_call_rate in RM cell  ER field in RM cell: used by switches to set source rate Switch on sender-to-receiver path: if congested  determine new rate for that source (consider PCR, ACR)  set ER field to indicate new rate only if new rate less than current ER value

15. Connection Management: Connection Paradigms Connection-oriented  explicitly setup/tear down connections  setup up session context  initial sequence number, flow control window size  exchange data within context of connection  e.g., TCP, ISO TP4

16. Connection Paradigms (cont) Connectionless service  pure datagram  one-time unreliable send  e.g., UDP (RFC 768), ISO CLTP (ISO 8072)  transaction oriented  single request from sender, single reply from receiver  VMTP protocol

17. Connection Management: Fundamental Issues Source of problems:  network can delay, reorder lose packets  timeout/retransmit introduces duplicates of data, ACKs, connect, close packets On packet arrival: is it real or is it memorex?  new connection request/release from "real live client" or an old one  transport protocols must create/maintain/destroy enough "state” information to answer the memorex question  explicit connection establishment/teardown with connection- oriented service

18. Connection Management: Two basic approaches for setting up a connection  two way handshake with wristwatch  three way handshake