DOC PREVIEW
Berkeley ELENG 122 - Transport Protocols & DNS

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

11Transport Protocols & DNSEE 122: Intro to Communication NetworksFall 2006 (MW 4-5:30 in Donner 155)Vern PaxsonTAs: Dilip Antony Joseph and Sukun Kimhttp://inst.eecs.berkeley.edu/~ee122/Materials with thanks to Jennifer Rexford, Ion Stoica,and colleagues at Princeton and UC Berkeley2Announcements• We’re soliciting feedback– What’s not working? What’s working well?• Send via email …• … or if you want to be anonymous, put a note inmy box in Soda, 3rd floor (near dept. admins)3Goals for Today’s Lecture, Part 1• Principles underlying transport-layer services– (De)multiplexing via port numbers– Reliable delivery– Performance issues: Stop-and-Wait vs. Sliding Window Flow control• Service models of Internet transport protocols– User Datagram Protocol (UDP)– Transmission Control Protocol (TCP)• Not a goal for today: details of TCP’s operation4Goals of Today’s Lecture, Part 2• Concepts & principles underlying Domain NameSystem (DNS)– Indirection: names in place of addresses– Hierarchy: in names, addresses, and servers– Caching: of mappings from names to/from addresses• Inner workings of DNS– DNS resolvers and servers– Iterative and recursive queries– TTL-based caching– Use of the dig utility5Role of Transport Layer• Application layer– Communication for specific applications– E.g., HyperText Transfer Protocol (HTTP), File TransferProtocol (FTP), Network News Transfer Protocol (NNTP)• Transport layer– Communication between processes (e.g., socket)– Relies on network layer; serves the application layer– E.g., TCP and UDP• Network layer– Logical communication between nodes– Hides details of the link technology– E.g., IP6Transport Protocols• Provide logical communicationbetween application processesrunning on different hosts• Run on end hosts– Sender: breaks applicationmessages into segments,and passes to network layer– Receiver: reassembles segmentsinto messages, passes toapplication layer• Multiple transport protocol availableto applications– Internet: TCP and UDP (mainly)applicationtransportnetworkdata linkphysicalapplicationtransportnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicallogical end-end transport27Internet Transport Protocols• Datagram messaging service (UDP)– No-frills extension of “best-effort” IP• Reliable, in-order delivery (TCP)– Connection set-up– Discarding of corrupted packets– Retransmission of lost packets– Flow control– Congestion control• Services not available– Delay guarantees– Bandwidth guarantees– Sessions that survive change-of-IP-address8Multiplexing and Demultiplexing• Host receives IP datagrams– Each datagram has sourceand destination IP address,– Each datagram carries onetransport-layer segment– Each segment has sourceand destination port number• Host uses IP addresses andport numbers to direct thesegment to appropriate socketsource port # dest port #32 bitsapplicationdata (message)other header fieldsTCP/UDP segment format9Unreliable Message Delivery Service• Lightweight communication between processes– Avoid overhead and delays of ordered, reliable delivery– Send messages to and receive them from a socket• User Datagram Protocol (UDP; RFC 768 - 1980!)– IP plus port numbers to support (de)multiplexing– Optional error checking on the packet contents (checksum field = 0 means “don’t verify checksum”) SRC port DST portchecksum lengthDATA10Why Would Anyone Use UDP?• Finer control over what data is sent and when– As soon as an application process writes into the socket– … UDP will package the data and send the packet• No delay for connection establishment– UDP just blasts away without any formal preliminaries– … which avoids introducing any unnecessary delays• No connection state– No allocation of buffers, sequence #s, timers …– … making it easier to handle many active clients at once• Small packet header overhead– UDP header is only 8 bytes11Popular Applications That Use UDP• Multimedia streaming– Retransmitting lost/corrupted packets often pointless - bythe time the packet is retransmitted, it’s too late– E.g., telephone calls, video conferencing, gaming• Simple query protocols like Domain Name System– Connection establishment overhead would double cost– Easier to have application retransmit if needed“Address for bbc.co.uk?”“212.58.228.155”12Transmission Control Protocol (TCP)• Connection oriented– Explicit set-up and tear-down of TCP session• Stream-of-bytes service– Sends and receives a stream of bytes, not messages• Congestion control– Dynamic adaptation to network path’s capacity• Reliable, in-order delivery– TCP tries very hard to ensure byte stream (eventually)arrives intact In the presence of corruption and loss• Flow control– Ensure that sender doesn’t overwhelm receiver313Reliable Delivery• How do we design for reliable delivery?– One possible model: how does it work talking on yourcell phone?• Positive acknowledgment (“Ack”)– Explicit confirmation by receiver– TCP acknowledgments are cumulative (“I’ve receivedeverything up through sequence #N”) With an option for acknowledging individual segments (“SACK”)• Negative acknowledgment (“Nack”)– “I’m missing the following: …”– How might the receiver tell something’s missing?Can they always do this?– (Only used by TCP in implicit fashion - “fast retransmit”)14Reliable Delivery, con’t• Timeout– If haven’t heard anything from receiver, send again– Problem: for how long do you wait? TCP uses function of estimated RTT– Problem: what if no Ack for retransmission? TCP (and other schemes) employs exponential backoff Double timer up to maximum - tapers off load during congestion• A very different approach to reliability: sendredundant data– Cell phone analogy: “Meet me at 3PM - repeat 3PM”– Forward error correction– Recovers from lost data nearly immediately!– But: only can cope with a limited degree of loss– And: adds load to the network15TCP Support for Reliable Delivery• Sequence numbers– Used to detect missing data– ... and for putting the data back in order• Checksum– Used to detect corrupted data at the receiver– …leading the receiver to drop the packet– No error signal sent -


View Full Document

Berkeley ELENG 122 - Transport Protocols & DNS

Documents in this Course
Lecture 6

Lecture 6

22 pages

Wireless

Wireless

16 pages

Links

Links

21 pages

Ethernet

Ethernet

10 pages

routing

routing

11 pages

Links

Links

7 pages

Switches

Switches

30 pages

Multicast

Multicast

36 pages

Switches

Switches

18 pages

Security

Security

16 pages

Switches

Switches

18 pages

Lecture 1

Lecture 1

56 pages

OPNET

OPNET

5 pages

Lecture 4

Lecture 4

16 pages

Ethernet

Ethernet

65 pages

Models

Models

30 pages

TCP

TCP

16 pages

Wireless

Wireless

48 pages

Load more
Download Transport Protocols & DNS
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Transport Protocols & DNS and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Transport Protocols & DNS 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?