transport layer
play

Transport Layer Understand Learn about transport layer protocols - PDF document

Chapter 3: Transport Layer Goals: Transport Layer Understand Learn about transport layer protocols in the principles behind transport layer Internet: services: UDP: connectionless CS 3516 Computer Networks CS 3516 Computer


  1. Chapter 3: Transport Layer Goals: Transport Layer • Understand • Learn about transport layer protocols in the principles behind transport layer Internet: services: – UDP: connectionless CS 3516 – Computer Networks CS 3516 Computer Networks transport transport – Multiplexing / l l / – TCP: connection-oriented demultiplexing transport – Reliable data transfer – TCP congestion control – Flow control – Congestion control Transport Services and Protocols Chapter 3 outline application • Provide logical communication • 3.5 Connection-oriented transport network • 3.1 Transport-layer between app processes data link physical transport: TCP running on different hosts services • Transport protocols run in – segment structure • 3.2 Multiplexing and end systems – reliable data transfer demultiplexing – send side: breaks app – flow control f • 3.3 Connectionless messages into segments, – connection management passes to network layer • 3.6 Principles of transport: UDP – receive side: reassembles • 3.4 Principles of application congestion control segments into messages, transport • 3.7 TCP congestion network reliable data transfer passes to app layer data link physical • More than one transport control protocol available to apps – Internet: TCP and UDP Internet Transport-layer Protocols Transport vs. Network layer • reliable, in-order Household analogy: application • network layer: logical transport delivery (TCP) network 12 kids sending letters to 12 data link physical communication kids – congestion control network data link • processes = kids network physical between hosts – flow control data link • app messages = letters in physical • transport layer: logical – connection setup • unreliable, unordered • envelopes envelopes li bl d d communication network t k • hosts = houses data link delivery: UDP between processes physical network • transport protocol = Ann data link physical – no-frills extension of – relies on, enhances, network and Bill (collect mail from “best-effort” IP data link network layer services application physical siblings) • services not available: network transport data link network • network-layer protocol = physical data link physical – delay guarantees postal service – bandwidth guarantees 1

  2. Chapter 3 outline Chapter 3 outline • 3.5 Connection-oriented • 3.5 Connection-oriented • 3.1 Transport-layer • 3.1 Transport-layer transport: TCP transport: TCP services services – segment structure – segment structure • 3.2 Multiplexing and • 3.2 Multiplexing and – reliable data transfer – reliable data transfer demultiplexing demultiplexing – flow control f – flow control f • 3.3 Connectionless • 3.3 Connectionless – connection management – connection management • 3.6 Principles of • 3.6 Principles of transport: UDP transport: UDP • 3.4 Principles of • 3.4 Principles of congestion control congestion control • 3.7 TCP congestion • 3.7 TCP congestion reliable data transfer reliable data transfer control control UDP: User Datagram Protocol [RFC 768] UDP: more • “no frills,” “bare bones” • Often used for streaming Internet transport Why is there a UDP? (video/audio) or game apps 32 bits protocol • no connection – loss tolerant source port # dest port # • “best effort” service, UDP Length, in establishment (which can – rate sensitive bytes of UDP checksum length • other UDP uses segments may be: add delay) segment, • simple: no connection state – lost including simple: no connection state – DNS DNS header h d – delivered out of order at sender, receiver – SNMP • small segment header to app • reliable transfer over UDP: • connectionless: Application • no congestion control: UDP add reliability at data – no handshaking between can blast away as fast as application layer (message) UDP sender, receiver desired – application-specific – each UDP segment error recovery! handled independently UDP segment format of others Internet Checksum Example UDP: checksum • Example: add two 16-bit integers Goal: detect “errors” (e.g., flipped bits) in transmitted segment 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 Sender: Receiver: • treat segment contents • compute checksum of wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 as sequence of 16-bit f 16 bit received segment i d s t • check if computed checksum integers sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 • checksum: addition (1’s equals checksum field value: checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 complement sum) of – NO - error detected • At receiver, add 2 integers and checksum … should segment contents – YES - no error detected. • sender puts checksum be all 1’s. If not, bit error (correction?  next) But maybe errors value into UDP checksum nonetheless? More later field …. 2

  3. Chapter 3 outline Principles of Reliable data transfer • important in app., transport, link layers • 3.5 Connection-oriented • top-10 list of important networking topics! • 3.1 Transport-layer transport: TCP services – segment structure • 3.2 Multiplexing and – reliable data transfer demultiplexing – flow control f • 3.3 Connectionless – connection management • 3.6 Principles of transport: UDP • 3.4 Principles of congestion control • 3.7 TCP congestion reliable data transfer control • characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Principles of Reliable Data Transfer Principles of Reliable data transfer • important in app., transport, link layers • important in app., transport, link layers • top-10 list of important networking topics! • top-10 list of important networking topics! (Zoom next slide) • characteristics of unreliable channel will determine • Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) complexity of reliable data transfer protocol (rdt) Reliable Data Transfer: Getting Started Reliable Data Transfer: Getting Started We’ll: rdt_send(): called from above, deliver_data(): called by • Incrementally develop sender, receiver sides rdt to deliver data to upper (e.g., by app.). Passed data to deliver to receiver upper layer of reliable data transfer protocol (rdt) • Consider only unidirectional data transfer – but control info will flow on both directions! • Use finite state machines (FSM) to specify send send receive receive side side sender, receiver event causing state transition actions taken on state transition state: when in this “state” state 1 next state uniquely state 2 event determined by next udt_send(): called by rdt, rdt_rcv(): called when packet actions event to transfer packet over arrives on rcv-side of channel unreliable channel to receiver 3

  4. Rdt1.0: Reliable Transfer over a Reliable What if Taking a Message over Channel Phone? • Underlying channel perfectly reliable • Message is clear? – no bit errors – no loss of packets • Message is garbled? • Separate FSMs for sender, receiver: – sender sends data into underlying channel – receiver read data from underlying channel i d d t f d l i h l rdt_send(data) Wait for rdt_rcv(packet) Wait for call from call from extract (packet,data) above packet = make_pkt(data) below deliver_data(data) udt_send(packet) Easy! sender receiver What if Taking a Message over Rdt2.0: Channel with Bit Errors (no Loss) Phone? • Underlying channel may flip bits in packet • Message is clear? – Checksum to detect bit errors – Ok • The question: how to recover from errors: • Message is garbled? – acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK – Ask to repeat – negative acknowledgements (NAKs): receiver explicitly – negative acknowledgements (NAKs): receiver explicitly – May not need whole message tells sender that pkt had errors • In networks, called Automatic Repeat – Sender retransmits pkt on receipt of NAK • New mechanisms in rdt2.0 (beyond rdt1.0 ): reQuest (ARQ) – Error detection – Need error detection – Receiver feedback: control msgs (ACK,NAK) rcvr  sender – Receiver feedback – Retransmission Rdt2.0: Operation with No Errors Rdt2.0: FSM Specification rdt_send(data) rdt_send(data) sndpkt = make_pkt(data, checksum) receiver snkpkt = make_pkt(data, checksum) receiver udt_send(sndpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) && isNAK(rcvpkt) isNAK(rcvpkt) Wait for Wait for Wait for rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) && Wait for call from ACK or ACK or udt_send(sndpkt) corrupt(rcvpkt) call from udt_send(sndpkt) corrupt(rcvpkt) above NAK NAK above udt_send(NAK) udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for Wait for   call from call from below below sender sender rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) notcorrupt(rcvpkt) extract(rcvpkt,data) extract(rcvpkt,data) deliver_data(data) deliver_data(data) udt_send(ACK) udt_send(ACK) 4

Recommend


More recommend