Outline

1
Outline

• TCPs goals
• Transmit packets to saturate link (b/w delay
  product)
• Flow control to not overwhelm recipient
• Client notifies the sender
• Congestion control to not overwhelm network
• Sender probes the network
• Assume Missed ACK congestion (backoff)
• Missed ACK RTT calculations are off
• Use ACKs to clock packet transmissions

2
Is lost ACK congestion?

• Question Are these good assumptions valid under
  all circumstances?
• What about Asymmetric links such as ADSL/Cable
  etc (1.5 Mbps upstream and 128 kbps downstream)
• ACKs can be stuck behind other data
• Congestion in ACK traffic does not mean
  congestion in forward path
• What about wireless links (errors are sporadic -
  e.g. cellular quality fades momentarily as you
  walk behind a building)?
• Need not back-off for sporadic packet loss -
  otherwise TCP will operate at significantly less
  efficiency than is possible

3

• What about asymmetric delay networks?
• DirectTV satellite for downstream (high bandwidth
  and high delay - signal has to travel to
  satellite and back - geosynchronous orbit is
  36000 km above equator) and dialup for upstream
  (low bandwidth and low latency)
• E.g. satellite providers, especially in remote
  areas

4
Approaches

• Reducing frequency of ACKs
• ACK filtering (before a congested link, remove
  redudant ACKs
• If we have ACKs for packets 1, 2, 3, 4 just
  transmit ACK4 and kill 1, 2, and 3
• However, this would make sender burst packets -
  we just lost TCP clocking mechanism
• Sender can adapt and space packets
• Infrastructure can reconstruct the lost ACKs and
  transmit them at a nice pace
• Treat ACKs separately and expedite through
  reverse congested links
• ACK first scheduling on routers

5

• Split the TCP - one for symmetric network and one
  for non-symmetric part
• Still retain end-to-end semantics of TCP
• Hide wireless specific issues from the wired side