Download Week13_2

TCP continued
Discussion – TCP Throughput
• TCP will most likely generate the saw tooth
type of traffic.
– A rough estimate is that the congestion window
will go from w/2 to w, where w is the cwnd value
causing congestion.
• Does it mean that TCP can achieve only 75% of
the throughput that the network can support?
Discussion – TCP Throughput
• Recall that the routers have buffers. Buffer size
is usually large.
• What happens is that from the time the router
drops a packet (when TCP will start to
backoff), till the time TCP climbs back to a
large window size, the router keeps on
working to get rid of the buffered packets.
Discussion – TCP on Wireless
• How will TCP perform when the path goes
through a wireless link of loss ratio 0.1?
(Randomly drops 10% of the packets?)
Discussion – TCP on Wireless
• TCP will most likely perform not ideally.
• A wireless loss is a loss. The TCP sender will have
to, according to the protocol, backoff, either start
fast retransmit or perform slow start, in both
cases the congestion window is reduced.
• Is this the correct response? Actually no. Because
the loss is not due to congestion.
• TCP should send packets as fast as possible to
recover from the loss.
Discussion – TCP in a Global Sense
• We usually assume a router drops packets at
the end of the queue.
• What will this lead to in a global sense?
– Many TCP connections share the same router, the
same input/output ports.
Discussion – TCP in a Global Sense
• What will likely happen is that all TCP flows will
hold back at the same time, i.e., when the router
starts to drop packets. Then they will start in
increase at the same time.
• Global synchronization is not good because it
puts more pressure on the router buffers.
– If not synchronized, the buffer size needs to prepare
for the average case. If synchronized, needs to
prepare for the worst case.
• Solution?
Discussion – TCP in a Global Sense
• Use Random Early Detection (RED).
• Idea is to drop even when the queue is not
full. Drop with larger probability if the queue
length is longer.
• It will more likely drop a packet from a larger
flow than from a smaller flow.
ECN
• Explicit Congestion Notification. RFC 3168.
• “An ECN-aware router may set a bit in the IP
header instead of dropping a packet in order
to signal the beginning of congestion. The
receiver of the packet echoes the congestion
indication to the sender, which must react as
though a packet drop were detected. “ – from
wiki
Misc – TCP on Timeout
• Once a timeout happens, the sender doubles
timeout.
Misc – TCP Deadlock
• The receiver window is full because the application is
not reading the data fast enough.
• The receiver sends ACK back advertising window size
0.
• The sender will not send anything.
• The receiver finally frees up some space, but the
sender does not know, because the receiver does not
send ACK when no data is received.
• Solution: TCP provide option for the sender to send a
1-byte segment to probe the receiver.
Misc – TCP sender
• TCP sender does not have to send the data
you give him immediately. The
implementations typically waits until get some
more data to send. Remember TCP regards
the data as a byte stream.
– This is the reason why the template code took
some measures to make sure that always a
complete packet is delivered.
Misc – Silly Window Syndrome
• The receiver may advertise small windows.
• The sender then sends small segments – not
very efficient.
• TCP requires the receiver only advertise
window of one MSS or half of its buffer,
whichever is smaller.
Beyond TCP – DCCP
• Sometimes you don’t need reliability, but need to
exercise some congestion control!
• For applications with timing constraints, data may be
useless if outdated.
• http://read.cs.ucla.edu/dccp/
Useful Linux Network Commands
•
•
•
•
•
•
ifconfig
route
tracert
netstat
ping
tcpdump