1 / 18

CS E 679: Computer Network Review

CS E 679: 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. 32 bits. source port #. dest port #.

missy
Download Presentation

CS E 679: Computer Network Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Network Layers

  3. Transport Layers • TCP/UDP

  4. TCP • Transport Control Protocol • Flow control and Responds to congestion • Reliable In-order delivery • “Nice” Protocol

  5. 32 bits source port # dest port # sequence number acknowledgement number head len not used rcvr window size U A P R S F checksum ptr urgent data Options (variable length) application data (variable length) TCP segment structure URG: urgent data (generally not used) counting by bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)

  6. 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

  7. Seq. #’s: byte stream “number” of first byte in segment’s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn’t say, - up to implementer time TCP seq. #’s and ACKs Host B Host A User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 simple telnet scenario

  8. 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.

  9. Flow Control

  10. exponential increase (per RTT) in window size (not so slow!) loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP) Slowstart algorithm time TCP Slowstart Host A Host B one segment RTT initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) two segments four segments

  11. TCP Congestion Avoidance Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 1 1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs

  12. UDP • No reliability, flow control, congestion control. • Sends data in a burst. • Provides multiplexing and demultiplexing of sources. • Most multimedia applications using UDP

  13. “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: User Datagram Protocol [RFC 768]

  14. 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! UDP segment structure 32 bits source port # dest port # Length, in bytes of UDP segment, including header checksum length Application data (message) UDP segment format

  15. 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

  16. Unfairness • When UDP and TCP compete, UDP wins by pushing TCP into congestion

  17. 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

  18. 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

More Related