TCPIP Over Lossy Links TCP SACK without Congestion Control - PowerPoint PPT Presentation

About This Presentation
Title:

TCPIP Over Lossy Links TCP SACK without Congestion Control

Description:

Without SACK, this flavor of TCP will perform poorly ... TCP SACK = 65% (at identical efficiencies of 91 ... compared to TCP SACK. Plan: investigate performance ... – PowerPoint PPT presentation

Number of Views:69
Avg rating:3.0/5.0
Slides: 20
Provided by: rolandk4
Learn more at: https://my.ece.utah.edu
Category:

less

Transcript and Presenter's Notes

Title: TCPIP Over Lossy Links TCP SACK without Congestion Control


1
TCP/IP Over Lossy Links - TCP SACK without
Congestion Control


2
The History of TCP2. Current TCP Congestion
Control3. Design Ideas no congestion control
at all4. Measurement Results5. Future TCP
Congestion Control?6. Conclusion
Organization
3
Old Tahoe slow start and congestion
avoidance after a lost packet, wait for a
timeout, then perform slowstart to
recoverTahoe (88)also contains fast
recovery. After the reception of a triple
duplicate ACKs, performs fast retransmit followed
by a slowstart Jaco88.Reno (90)fast
retransmit extended by fast recovery.
1. The History of TCP (incomplete)

4
Vegas (94, never actually implemented)
modified congestion behavior. By measuring the
output queue size, equilibrium is detemined
(Littles Law of queuing theory)
BraMalPet94.New Reno (94) small
optimization of TCP Reno, uses partial ACKs as an
indication that the following packet got lost and
immediately retransmits it without leaving fast
recovery. Hoe96.TCP SACK(95) added the
SACK option within ACKs. Allows receiver to
specify the range of packets that were received
out of order. MatmahFlRo96.
1. The History of TCP (incomplete)
In contrast to all previous flavors, more than
one packet per RTT during fast recovery can be
send

5
FACK (96) In fast recovery, congestion
window is fixed. TCP FACK uses pipe variable to
estimate the data in the network by taking the
transmitted out-of-order segments into account,
thus preventing premature timeouts MatMah96.
1. The History of TCP (incomplete)

6
Slow Start with every received ACK, double the
number of packets sent.Slow start adds a window
to the sender's TCP the congestion window,
called cwnd as well as a variable called ssthres

2. Congestion Control slow start
exponential growth of the Congestion Window up to
ssthres, then linear growth
Figure taken from Jaco88
The congestion window is flow control imposed by
the sender. It is based on the sender's educated
guess of perceived network congestion. Congestion
Control assumes that packets are only lost due to
overfull queues.

7
2. Congestion Control congestion avoidance in
TCP Reno
window
time
SS
CA
SS Slow Start CA Congestion Avoidance
8
2. TCP Congestion Control
TCP send rate is determined by three windows
winmin(snd_cwnd,snd_wnd,snd_bwnd)

9
3. Design Idea no congestion control at all
The sending rate is given by winmin(snd_cwnd,s
nd_wnd,snd_bwnd) Now winmin(snd_bwnd,snd_wnd)

Without SACK, this flavor of TCP will perform
poorly (waste of bandwidth on duplicate ACKs
that can lead to timeouts)
SACK gives us control over the now static window
UDP?
In contrast to UDP, the protocol will still
guarantee for in-order delivery and will adopt
to the link capacity.
10
4. Measurements the emulation environment
On all links, delay10ms. Loss rates varied from
p0, p0.001, p0.01, p0.1 to p0.2 Packt loss
events are uniformly distributed.
Experiment has been set up in the emulab
environment emu.

11
4. Measurements collection of Data
1. Initialize tcpdump on the to-be-observed
node sudo tcpdump -c num -w file -i if 2.
Start ttcp on the receiving node ttcp -r -s
src 3. Start ttcp on the sending node ttcp -t
-s -n num dst num - number of packets to be
captured file - name of the dump
file if - interface to be listened to src - IP
address of the sending node dst - IP address of
the receiving node
Traces have been analyzed off-line with ethereal
eth.
12
4. Measurements SACKBASE, lossless link
tcpdump started on the sender, zoomed into
connection set up phase
13
4. Measurements SACKEXP, lossless link
tcpdump started on the sender, zoomed into
connection set up phase
14
4. Definitions Throughput and Goodput
ThroughputThe number of packets per unit of
time transmitted between sender and receiver.
GoodputThe number of packets per unit of
time forwarded from sender to receiver, minus any
packets lost or retransmitted, minus ACKs.
15
4. Measurements summary of results, competing
flows
16
4. Measurements summary of results, competing
flows
17
5. Future TCP Congestion Control? ECN bit
Another way to do congestion control the ECN bit
Instead of dropping packets, a router sends a TCP
an explicit message stating that the network is
becoming congested. The network determines an
explicit rate for a sender RamFloyd99.
Hop-by-Hop vs. End-to-end congestion control
18
6. Conclusion
  • Ambiguity in packet loss ? current TCP
    congestion control
  • ? low throughput over lossy links
  • TCP w/o congestion control and without SACK is
    inefficient
  • p0.1, SACKEXP 91 of goodput of lossless
    link, TCP SACK 65 (at identical efficiencies
    of 91)
  • As losses increase to 20, SACKEXP goodputs
    700 at similar efficiencies compared to TCP
    SACK
  • Plan investigate performance of SACKEXP with
  • Congestion Control based on the ECN bit/ICMP
    Source Quench
  • Performance of SACKEXP has to be compared to a
    TCP that can resort to a Link Layer
    retransmission scheme.
  • What about TCP fairness????

19
THE END
  • Questions are
  • welcome!
Write a Comment
User Comments (0)
About PowerShow.com