|
CSE 588 - Spring 2002 - Transcription |
|
 CSE Home |
CSE 588 Home |
Scribe List |
About Us |
Search |
Contact Info |
CSE 588 Networks Lecture
May 7, 2002
First half
- Tom asked about projects. It is week 6, only 5.5 weeks left.
- Tom passed out a handout on the tpc congestion game.
- The "network" used in the game:
------------- ---------------- -------------
|sender | | Router | | Receiver |
| |<-------> | | <-------> | |
| | link 1 |buffer size = | link 2 | |
| | | 4 packets | | |
------------- ---------------- -------------
link 1: latency = 1, bandwidth is infinite
link 2: latency = 0, bandwidth is 1 packet per time step
- Game was played with tom using post-it notes to represent packets as they
traveled through the network. The game illustrated the router dropping packets
as its buffer space was exhausted. Note that packets were transmitted on the
link 1 with higher frequency than they could be transmitted on link2, so the
packets would accumulate on the router and be dropped.
- note that with slow start, the sender won't find out about lost packets
for some time.
- why can't routers send the notification when a packet is dropped?
- There were some graphs that I won't attempt to reproduce in ascii. In
essence they showed periodic steep drops in throughput due to the fact that
congestion info wasn't propagated back to sender in a timely manner.
- Note that in the example game, the first dup ack the sender received is when
the sender's congestion window was at 14. The maximum throughput in the system
is four packets. over a 300% difference.
- At some point, we eventually do multiplicative decrease and then move into
congestion avoidance.
- w/ congestion avoidance, we will eventually get into a steady state
- on the ack of the sixth packet, we end slow start and start additive increase.
- Note: If the buffer size in the router is increased, you increase the amount
of time it takes to identify the congestion.
- Question: Why not detect congestion when the buffer starts filling instead of
when the router overflows?
Answer: There are two approaches:
Router Assist - ECN Better End Host - vegas
------------------- -----------------------
+ use freq. of acks
+ annotate packets to + to estimate queue size and
include info about back off on the sending host
queue size.
+ Can also set a bit if
Avg. queue size > X
(RED w/ ECN)
- What if bandwidth is fixed, sending rate is fixed, varying # of flows:
+ throughput remains constant as # of flows increases
+ loss rate increases linearly as # of flows increases
I have graphs in my notes:
| |
| loss |
thru- | rate | /
put | | /
|--------------------- | /
| | /
| | /
| |-------
---------------------- ----------------------
0 1 2 ... --------> 0 1 2 ... -------->
# of flows= # of flows
NOTE: loss rate graph is linear in my notes. It doesn't look that
way in ascii.
- if congestion window is < 1, things are really bad, as tcp doesn't support
congestion window < 1.
- TCP Pacing - whenver you have to send something, spread all packets over the
entire round-trip-time (instead of slow start).
+ Doesn't work well at all. Why? Network fills up from everyone in a synch
manner.
+ it does work well for networks w/ small buffers
 |
Department of Computer Science & Engineering University of Washington Box 352350 Seattle, WA 98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to owner-cse588] |