Post on 13-Jan-2016
CSE679: Computer Network Review
Review of the uncounted quiz Computer network review
Network Layers
Transport Layers
TCP/UDP
TCP
Transport Control Protocol Flow control and Responds to congestion Reliable In-order delivery “Nice” Protocol
TCP segment structure
source port # dest port #
32 bits
applicationdata
(variable length)
sequence number
acknowledgement numberrcvr window size
ptr urgent datachecksum
FSRPAUheadlen
notused
Options (variable length)
URG: urgent data (generally not used)
ACK: ACK #valid
PSH: push data now(generally not used)
RST, SYN, FIN:connection estab(setup, teardown
commands)
# bytes rcvr willingto accept
countingby bytes of data(not segments!)
Internetchecksum
(as in UDP)
Reliable Delivery
Sender, Receiver keep track of bytes sent and bytes received.
Acks have an indication of next byte expected. Three duplicate acks considered a packet loss
- sender retransmits
TCP seq. #’s and ACKs
Seq. #’s: byte stream
“number” of first byte in segment’s data
ACKs: seq # of next byte
expected from other side
cumulative ACKQ: how receiver handles
out-of-order segments A: TCP spec doesn’t
say, - up to implementer
Host A Host B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Usertypes
‘C’
host ACKsreceipt
of echoed‘C’
host ACKsreceipt of
‘C’, echoesback ‘C’
timesimple telnet scenario
TCP Flow Control
Window based Sender cannot send more data than a window
without acknowledgements. Window is a minimum of receiver’s buffer and
‘congestion window’. After a window of data is transmitted, in
steady state, acks control sending rate.
Flow Control
TCP Slowstart
exponential increase (per RTT) in window size (not so slow!)
loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP)
initialize: Congwin = 1for (each segment ACKed) Congwin++until (loss event OR CongWin > threshold)
Slowstart algorithmHost A
one segment
RTT
Host B
time
two segments
four segments
TCP Congestion Avoidance
/* slowstart is over */ /* Congwin > threshold */Until (loss event) { every w segments ACKed: Congwin++ }threshold = Congwin/2Congwin = 1perform slowstart
Congestion avoidance
1
1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs
UDP
No reliability, flow control, congestion control. Sends data in a burst. Provides multiplexing and demultiplexing of
sources. Most multimedia applications using UDP
UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internet transport protocol
“best effort” service, UDP segments may be: lost delivered out of order to
app connectionless:
no handshaking between UDP sender, receiver
each UDP segment handled independently of others
Why is there a UDP? no connection
establishment (which can add delay)
simple: no connection state at sender, receiver
small segment header no congestion control: UDP
can blast away as fast as desired
UDP segment structure
often used for streaming multimedia apps loss tolerant rate sensitive
other UDP uses (why?): DNS SNMP
reliable transfer over UDP: add reliability at application layer application-specific error
recover!
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksumLength, in
bytes of UDPsegment,including
header
UDP Consequences
Most applications today use TCP Stability of network relies on congestion
response of applications Large scale use of UDP could lead to problems
- no congestion response Large number of multimedia applications
expected - move larger amounts of data
Unfairness
When UDP and TCP compete, UDP wins by pushing TCP into congestion
TCP-Friendly
Throughput of a TCP connection
P: the packet size p: the lost probability of a packet
Limit flows to TCP-style BW Don’t know RTT exactly Why should everyone follow this exactly? Monitoring individual flows difficult
)/(2.1 RTTpP
Conclusion
TCP TCP not well suited to multimedia. TCP is a well understood, ‘nice’ protocol. Multiplicative decrease/additive increase allows fair
sharing of BW and avoids congestion collapse. UDP is being used by multimedia developers.
UDP UDP can be tuned to better support multimedia
applications. TCP-friendly Rate-based adaptation
• Packet-pair Hop-by-hop control