End-end protocols - Chap 6
guarantee message delivery
delivers messages in the same order they are sent
deliver at most one copy of a message
support arbitrarily large messages
support synchro between sender and receiver
allow the receiver to apply flow control to the sender
support multiple application processes on each host
underlying layer may
drop messages
reorder messages
deliver duplicate copies of a given message
limite messages to some finite size
deliver messages after an arbitrarily long delay
6.1 UDP
convert host-host to process-process - demuxing
could use pid to id process, but it is os-dependent and closed
open process uses port ot indirectly id process
(destination host, port) - port is 16 bit (64k per host)
well-known ports, may move
no flow control
uses checksum on data plus pseudoheader
6.2 TCP
reliable in-order byte-stream, full-duplex, flow-control,
congestion control, demuxing
.1 end-end issues
differences between layer 2 and layer 4
connection-establishment/teardown
variable RTT - timeouts must be adaptive
TTL real - packets can show up much delayed
variable resources on hosts - must learn buffer and other
resources per connection, since they are shared among many connections versus a dedicated line
congestion control needed in addition to flow
end-end argument in system design never implement too low
if you can't do it right.
TCP extensions
improve timeout mechanism using timestamp to measure RTT
use timestamp to extend address space to insure no
wrap around
use advertised window to indicate larger (eg
16byte) chunks so that large fast pipes can be filled
.2 Segment Format
Max Segment Size generally set to MTU
send segment when MSS reached, or on a push command or on a
timer
.3 Connection establishment and termination
three-way handshakes
state transition diagram - all intersting stuff is in
Established state
.4 Sliding window revisited
reliable and orderly delivery - sending buffer deals with
last byte acked, last byte sent, lastbyte written. receiving buffer management has to deal with last byte read (by upper application), nextbyte expected (set to first hole) and last byte received (set to furtherest out received).
flow control -uses advertised window that is set at the amount of free space in receiving buffer. setting window to 0 causes sender to stop, which fills up sending buffer whcih stops sending application. unblocking occurs when window >0 sender can transmit, receive acks and release buffer space then starting sending app. sender sends 1 byte probes every once in a while to get window updates. an instance of the smart sender/dumb receiver model - keep receiver simple
keeping the pipe full
32 bit tcp seq number space - wraps around in 6.4
hrs on a t1, 14 sec at oc48. compare to ttl setting of 60sec! 16bit advertised window -to fill a pip depends on delayXbandwidth - for 100 ms at t1 is 18kB, for oc48 its 14,8mB. compare to a 64kB window size max for 16 bit.
.5 Adaptive retransmission timeout setting betweeen hosts
Original algorithm running average of RTT, weighted
against last reading
Karn/Partridge - adds solution to retransmitted problems
and uses exponential
Jacobsen/Karels - uses rtt and deviation.
.6 Record boundaries
can do with a push command or a the urg flag and urg pointer.
6.3 RPC explain strucutre, stubs, ewidows and orphans,
messagin versus rpc
.1 Bulk transfer
blast algorithm
blast message format
.2 request/reply (Chan)
At most once semantics
Chan Algorithm
Chan Message Format
.3 Dispatcher (select)
.4 Putting it all together (SUN RPC)
simple rpc stack
more interesting rpc stack
sunrpc
6.4 API - interface that allows apps to contact transport layer.
defines a syntax as well as a semantic
6.5 Performance - pg 337.
experimental format
latency
throughput
Open Issues
coping with TCP changes - extensions are good...(eg timeouts)
window size and seq number tougher issues- limit to hdrs in tcp
(due to hdrlen field being 4 bits => tcp hdr can have only 44bytes of hdr
protocols that don't want all the features of TCP - eg video, audio