|
CSE 588 - Spring 2002 - Transcription |
|
 CSE Home |
CSE 588 Home |
Scribe List |
About Us |
Search |
Contact Info |
Scribe Duty Notes
Notes on Network Systems - CSE 584 - April 30 (first half)
TCP Mechanics
Some decisions can be argued with
but none of it matters
Sliding window and timeouts are essential.
What follows is not design, but tutorial
Given IP on machines, how to give allocations to process application
It is done by ports. It could have been process id, or application, but
no, ports
e.g. one expected port for HTTP
www.iana.org -- gives assignment of ports.
"to" port is fixed, "from" port is random, reserved ports are below 1024
Now, what is API to application?
One has to be client, one server
one has to listen (server), one has to connect (client)
After a connect, will want to write
API is two-way byte stream
almost like a synchronized file
Almost everything is this way in distributed systems
except for streaming media.
One set-up, would just like to write bytes
to a buffer
also read the same way, using different blocks
Could have been object oriented, with record delimiters
SCTP is along these lines -- it is a record oriented transfer
protocol
Would like to send whole objects
======== {{ drawing depicting two stacks, communicating }}
{{ at the bottom, being pushed and popped at the top }}
What will TCP size be: MTU - IP
Wouldn't we get fragments?
if don't-fragment bit set, xmit will get a reply
You can get route changes during connection, but rare
Packet loss /ARQ
imagine corrupt date --- 16 bit checksum
this is weak, could get mutual bit flips
CRC - would be what's used today to detect trouble
Why isn't checksum on whole data
checksum on IP header
checksum on TCP header
independent check, UDP has no checksum
X-25 was so much better, error less likely. Checksums fine
Well, end-to-end error detection not good enough
so we actually do link detection
page 387 agreement on what c/s covers
If checksum corrupt at RCVR, no ACK
{{ diagram showing packet, and resent packet, from
{{ one vertical line, slanting to right down, to other vertical line
{{ separated vertically be "time-out"
What if ACK got dropped?
Need a sequence number to track ACK to send
================
Sliding window
propagation delay -- first bit leading edge
transmission delay -- whole packet gets across
bandwidth
How big a sliding window
LAN Ethernet
1 nsec / ft.
100 MB/sec
100 ft. long 1u(micro)sec Causes problems:
Imagine packet sent
over just
Ethernet -
ACK collides
with next packet.
Send the packet out and identify with seq #
{{ drawing showing a lot of packet round trips between
{{ two vertical lines
Should we use
packet # or byte #
Could be more efficient, however, fragmentation is done by IP
However, MTU could change by the time things are retransmitted.
Why ACK #s separate from SEQ #s? Why not same slot
Performance, reply with ACK
80 % of TCP is HTML, so
painfully, 200 mSec delayed ACK
if data packet
if out of order
wait for two received packets
then 200 msec flush line ACK
This is a complication - optimization
On the server, 200 msec make some sense, not on client. Implementations
vary, in the past Microsoft TCP protocol did well with other Microsoft,
likewise for Sun, however protocol exchange Microsoft to Sun severe problems
a result of the implications of the 200 msec delay.
In tcp-header, seq # is first byte, ack # is next byte expected } in
32-bit
Why not NAK? -- unnecessary complication, since what we get back
from ACK is next expected.
duplicate ACKs are a result of dropped, or out of order, packets
Wait for t/o, or "fast retransmit" -- resend if we get a bunch of dupe
ACKs
{{ Drawing depicting "God's eye" view of the byte
(( stream, showing received+ACK'd, rec'vd but not
{{ ACK'd because of incontiguity, in transit, sent
(( bytes, and sent-but not ACK'd bytes.
{{ Also, not sent yet shown
Once acknowledged, can toss backing bufferage
How long to wait for first RTT?: 3 - 6 seconds
T/Os start w. fixed number -- 3 seconds
Australian connections involve multiple seconds
IP is store and forward, so have to get whole packet
before scheduling a transmit.
Communication with Mars? IP breaks down, e-mail model is closer to real.
Time-outs
start @ fixed
- measure -- exponentially
RTT(test) = RTT(old) * (alpha) + RTT(meas) * [ 1 - (alpha) ]
Problem #1 What if you get a loss, then retransmit, then get something
quick?
What time do you use?
"retransmission ambiguity measurement"
TCP/IP solution - after a time-out, double time-out
to avoid many retransmits, however drastic at start-up
Problem #2 congestion --> increasing RTT
which will also increase congestion
RTT(variance) = variance(old) * (beta) + variance
T/O = RTT(est) * 2 + variance * g
if RTT conservative can work because
will prevent congestion
What if receiver is too slow?
Write will block, ... because receive buffer is always full
"silly window syndrome avoidance" will not inform sending application
until half of buffer is open.
"Nagel's Algorithm"
Suppose on telnet, write one byte at a time
Can do, but will not send second byte buffer
until first ACK'd
Does this all make sense.
push() on socket API can override these rules.
==== end of first half ====
 |
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] |