Transport layer Transport services and protocols applicatio - PowerPoint PPT Presentation

Transport layer

Transport services and protocols applicatio  Provide communication n transport between application processes network data link running on different hosts physical  Protocols run in end system OS  Sender transport  Breaks application messages into segments, passes to network layer  Receiver transport applicatio  Reassembles segments into n transport messages, passes to destination network data link application physical  Two main transport protocols  TCP and UDP

Transport Layer Functions  Demux to upper layer  Delivering data to correct application process  Connection setup  Providing a connection abstraction over a connectionless substrate  Delivery semantics  Reliable or unreliable  Ordered or unordered  Unicast, multicast, anycast  Flow control  Prevent overflow of receiver buffers  Congestion control  Prevent overflow of network buffers  Avoid packet loss and packet delay  Security

1. Demux to upper layer (both TCP & UDP)  Which process gets this request?  Done via 16-bit source port and 16-bit destination port in both UDP and TCP FTP HTTP NTP DNS TCP UDP Network IP TCP/UDP IP Type Protocol Port … NET 1 NET 2 NET n Field Field Number

Internet services layered on top of TCP/UDP  What uses TCP?  HTTP (Web pre-2016)  SMTP (E-mail transmission)  IMAP, POP (E-mail access) ‏  What uses (mainly) UDP?  DNS  NTP (network time protocol)  Highly interactive on-line games (First-Person Shooters) ‏  Many protocols can use both

Internet services layered on top of TCP/UDP  Protocols and their ports listed in /etc/services on *nix or C:\WIN*\system32\services echo 7/tcp echo 7/udp ssh 22/tcp # SSH Remote Login Protocol ssh 22/udp telnet 23/tcp smtp 25/tcp domain 53/tcp # Domain Name Server domain 53/udp http 80/tcp # WorldWideWeb HTTP http 80/udp # HyperText Transfer Protocol netbios-ssn 139/tcp # NETBIOS session service netbios-ssn 139/udp bgp 179/tcp # Border Gateway Protocol bgp 179/udp https 443/tcp # http protocol over TLS/SSL https 443/udp microsoft-ds 445/tcp # Microsoft Naked CIFS microsoft-ds 445/udp  IANA  http://www.iana.org/assignments/port-numbers

UDP: User Datagram Protocol  Barebones transport protocol  UDP and transport layer functions  Demux  Connection setup (none)  Connectionless  No handshaking between sender and receiver  Minimal state  Delivery semantics  Unreliable, unordered, mostly unicast (multicast no longer supported)  No flow control support  No congestion control support  No security support

UDP: more  Often used for streaming multimedia apps  loss tolerant 32 bits  rate sensitive source port # dest port # Length, in bytes of UDP checksum length segment, including header Application data (message) ‏ UDP segment format

TCP: Overview  Connection-oriented  Flow and congestion  Delivery semantics controlled:  Reliable, in-order byte  Pipelined operation to stream control size of "pipe" (i.e.  3-way handshake to initialize sender/receiver bandwidth) and provide connection  Pipeline of packets sized integrity  Error detection, correction by MSS (maximum  Retransmission segment size)  Duplicate detection  Control algorithms to keep  Unicast (point-to-point) sender from overwhelming  one sender, one receiver receiver or network  Full duplex (bi-directional flow) application application writes data reads data socket socket door door TCP TCP send buffer receive buffer segment

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

TCP  TCP creates a reliable data transfer service on top of IP’s‏unreliable‏service‏via  Checksum  Sequence numbers  Acknowledgments  Retransmissions  Rate limits on sender

What if the Data is Corrupted? Problem: Data Corruption GET index.html GET windex.html Internet Solution: Add a checksum X 0,9 9 6,7,8 21 4,5 7 1,2,3 6

Segment integrity via checksum  Checksum included in header by sender  Generated by treating data in the packet as numbers and adding them all up  Receiver checks checksum  Performs same operation as sender and checks checksum field  Corruption detected when no match

What if the Data is Out of Order? Problem: Out of Order ml inde x.th GET GET x.thindeml Solution: Add Sequence Numbers ml 4 inde 2 x.th 3 GET 1 GET index.html

Sequence numbers  Data‏in‏each‏packet‏is‏labeled‏with‏a‏“unique”‏number  Establishes ordering amongst packets  Allows receiver to identify which packets have been received and which have not  Initialized during connection setup (i.e. 3-way handshake) A B SYN + Seq A SYN+ACK-A + Seq B ACK-B

What if the Data is Lost? Problem: Lost Data GET index.html Internet Solution: Timeout and Retransmit GET index.html GET index.html Internet GET index.html

Acknowledgements and retransmissions  TCP receiver sends an acknowledgement back to sender for the data it receives  Lets‏sender‏know‏to‏“move‏on”  Lets sender know that network has the capacity to deliver its packets  Retransmissions  Via timeout events  TCP uses single retransmission timer  Sender sends segment and sets a timer  Timer is based on measured round-trip times and round-trip time variations  (e.g. timeout after ave. rtt + 2*std. deviation)  Exponential backoff if persistent loss  Via missing acknowledgements  If receiver reports it has received packets 1, 3, 4, and 5, sender automatically resends 2 before timeout

What if receiver has no resources (flow control)? Problem: Overflowing receiver buffers PUT remix.mp3 Internet Solution: Receiver advertised window PUT remix.mp3 Internet 16KB free

TCP Flow control  Receiver has a finite buffer  App process may be slow reading it  Flow control to make sure sender won't overflow it  Match‏the‏send‏rate‏to‏the‏receiving‏app’s‏drain‏rate  Rcvr advertises spare room in buffer by including value of RcvWindow in each segment/ACK  Also‏known‏as‏the‏“advertised”‏window  Sender limits unACKed data to RcvWindow to avoid overflow

TCP Flow control  Problem: 16-bit advertised window field (in bytes) ‏  Maximum of 64KB !!  Consider network with 1500 byte segments, 100ms RTT, want 10 Gbps throughput  BW*Delay = 10Gbs * 0.1s = 1Gbit  In packets, W=83,333  In bytes, 1Gbit/8 = 125MB  Amount of data potentially in flight from sender to receiver  Need at least a 125MB receiver buffer to support!  Solution: TCP window scaling option  Scaling factor on advertised window specifies # of bits to shift to the left  Scaling factor exchanged during connection setup

What if Network is Overloaded?  Short bursts: buffer  What if buffer overflows?  Packets dropped and retransmitted  Sender adjusts rate until load = resources  Called‏“Congestion‏control”

TCP congestion control  End-host, window-based  Only place to really prevent collapse is at end-host  Added in late 80s due to congestion collapse on the Internet  Increase in network load results in decrease of useful work  A result of  Spurious retransmissions of packets still in flight  Undelivered packets which consume network resources and are dropped elsewhere in network

TCP congestion control basics  Keep a congestion window, ( cwnd ) ‏  Reduce when congestion is perceived  Increase otherwise (probe for bandwidth) ‏  Size of window denotes how much network is able to absorb  “Size‏of‏the‏pipe”  Make cwnd as large as possible without loss  TCP‏“probes”‏for‏usable‏bandwidth‏continuously  Increase cwnd until loss (congestion) ‏  Decrease cwnd upon loss ,then begin probing (increasing) again  Recall‏receiver’s‏advertised‏window‏( rcv_wnd ) ‏  Sender’s‏maximum‏window  min(rcv_wnd,cwnd) ‏

TCP slow start (circa 1990s)  When connection begins, increase rate exponentially fast until first loss event  cwnd = 1 for 1st RTT  cwnd = 2 for 2nd RTT  cwnd = 4 for 3rd RTT  When connection begins, cwnd = 1 MSS  Example: MSS = 500 bytes & RTT = 200 msec  Initial rate = 20 kbps!  Available bandwidth may be much larger than MSS/RTT  desirable to quickly ramp up to respectable rate