CSE679: Computer Network Review r Review of the uncounted quiz r Computer network review.

Post on 13-Jan-2016

216 views 2 download

Transcript of CSE679: Computer Network Review r Review of the uncounted quiz r Computer network review.

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