1 Internet transport-layer protocols r reliable, in-order delivery (TCP) m congestion control m flow control m connection setup r unreliable, unordered.

Slides:



Advertisements
Similar presentations
Transport Layer3-1 Transport Overview and UDP. Transport Layer3-2 Goals r Understand transport services m Multiplexing and Demultiplexing m Reliable data.
Advertisements

Transport Layer 3-1 Transport services and protocols  provide logical communication between app processes running on different hosts  transport protocols.
Some slides are in courtesy of J. Kurose and K. Ross Review of Previous Lecture Electronic Mail: SMTP, POP3, IMAP DNS Socket programming with TCP.
Computer Communication Digital Communication in the Modern World Transport Layer Multiplexing, UDP
Chapter 3: Transport Layer
EEC-484/584 Computer Networks Lecture 6 Wenbing Zhao (Part of the slides are based on Drs. Kurose & Ross ’ s slides for their Computer.
1 Outline r Transport-layer services r Multiplexing and demultiplexing r Connectionless transport: UDP r Principles of reliable data transfer.
Transport Layer3-1 Transport Layer Our goals: r understand principles behind transport layer services: m multiplexing/demultipl exing m reliable data transfer.
Transport Layer3-1 Reliable Data Transfer. Transport Layer3-2 Principles of Reliable data transfer r important in app., transport, link layers r top-10.
Lecture 8 Chapter 3 Transport Layer
Some slides are in courtesy of J. Kurose and K. Ross Review of Previous Lecture Electronic Mail: SMTP, POP3, IMAP DNS Socket programming with TCP.
Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.
Transport Layer3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley,
9/30/ /2/2003 The Transport Layer September 30-October 2, 2003.
3-1 Transport services and protocols r provide logical communication between app processes running on different hosts r transport protocols run in end.
1 Transport Layer goals: r understand principles behind transport layer services: m multiplexing/demultiplexing m reliable data transfer m flow control.
8-1 Transport Layer Our goals: r understand principles behind transport layer services: m multiplexing/demultipl exing m reliable data transfer m flow.
Transport Layer3-1 Data Communication and Networks Lecture 5  Transport Protocols: Multiplexing and Reliable Data Transfer October 7, 2004.
Transport Layer Transport Layer. Transport Layer 3-2 Chapter 3 Transport Layer Computer Networking: A Top Down Approach Featuring the Internet,
Previous Lecture r P2P file sharing r Socket programming with TCP r Socket programming with UDP.
Review: –What is AS? –What is the routing algorithm in BGP? –How does it work? –Where is “policy” reflected in BGP (policy based routing)? –Give examples.
Transport Layer 3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley Chapter3_1.
Transport Layer3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009.
Data Communications and Computer Networks Chapter 3 CS 3830 Lecture 12 Omar Meqdadi Department of Computer Science and Software Engineering University.
CS 1652 The slides are adapted from the publisher’s material All material copyright J.F Kurose and K.W. Ross, All Rights Reserved Jack Lange.
Network LayerII-1 RSC Part III: Transport Layer 1. Basic Concepts Redes y Servicios de Comunicaciones Universidad Carlos III de Madrid These slides are,
14-1 Last time □ Mobility in Cellular networks ♦ HLR, VLR, MSC ♦ Handoff □ Transport Layer ♦ Introduction ♦ Multiplexing / demultiplexing ♦ UDP.
Transport Layer 3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Part.
Transport Layer3-1 Chapter 3: Transport Layer Our goals: r understand principles behind transport layer services: m multiplexing/demultipl exing m reliable.
Transport Layer1 Ram Dantu (compiled from various text books)
1 of 44 Week 2 Lecture 2 – Network Layers Transport Layer – Example: TCP/UDP.
Lecture91 Administrative Things r Return homework # 1 r Review some problems in homework # 1 r Questions about grading? Yona r WebCT for CSE245 is working!
CS 3830 Day 15 Introduction 1-1. Announcements r Quiz 3: Wednesday, Oct 10 r Prog3 due (in 1DropBox) on Wednesday, Oct 10 r Prog4: m Parts A and B m Work.
Transport Layer3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July A.
Chapter 3, slide: 1 CS 372 – introduction to computer networks* Tuesday July 6 Announcements: r Lab 2 is due today Acknowledgement: slides drawn heavily.
Transport Layer Goals: Overview:
Transport Layer3-1 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles.
Transport Layer 3-1 Chapter 3 outline 3.4 Principles of reliable data transfer.
Transport Layer 3-1 Chapter 3 Outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP.
Transport Layer3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley,
Transport Layer 3-1 Chapter 3: Transport Layer Our goals: r understand principles behind transport layer services: m Multiplexing/demultip lexing m reliable.
MULTIPLEXING/DEMULTIPLEXING, CONNECTIONLESS TRANSPORT.
1 CSCD 330 Network Programming Some Material in these slides from J.F Kurose and K.W. Ross All material copyright Lecture 9 Transport Layer Winter.
Transport Layer3-1 Chapter 3: Transport Layer Our goals: r understand principles behind transport layer services: m multiplexing/demultipl exing m reliable.
Transport Layer3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009.
Application Layer 2-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012.
Introduction 1-1 source application transport network link physical HtHt HnHn M segment HtHt datagram destination application transport network link physical.
Chapter 3 Transport Layer
Chapter 3 outline 3.1 Transport-layer services
Session 8 INST 346 Technologies, Infrastructure and Architecture
Chapter 3 Transport Layer
Chapter 3: Transport Layer
EEC-484/584 Computer Networks
Chapter 3: Transport Layer
Chapter 3: Transport Layer
Chapter 3 outline 3.1 Transport-layer services
Chapter 3 Transport Layer
EEC-484/584 Computer Networks
EEC-484/584 Computer Networks
EEC-484/584 Computer Networks
EEC-484 Computer Networks
Never take life seriously. Nobody gets out alive anyway
Chapter 3: Transport Layer
EEC-484/584 Computer Networks
Chapter 3: Transport Layer
EEC-484/584 Computer Networks
Chapter 3: Transport Layer
CS 5565 Network Architecture and Protocols
Transport Layer Our goals:
Chapter 3: Transport Layer
Presentation transcript:

1 Internet transport-layer protocols r reliable, in-order delivery (TCP) m congestion control m flow control m connection setup r unreliable, unordered delivery: UDP m no-frills extension of “best-effort” IP r services not available: m delay guarantees m bandwidth guarantees application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport

2 outline r Transport-layer services r Multiplexing and demultiplexing r Connectionless transport: UDP

3 Multiplexing/demultiplexing application transport network link physical P1 application transport network link physical application transport network link physical P2 P3 P4 P1 host 1 host 2 host 3 = process= socket delivering received segments to correct socket Demultiplexing at rcv host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) Multiplexing at send host:

4 How demultiplexing works r host receives IP datagrams m each datagram has source IP address, destination IP address m each datagram carries 1 transport-layer segment m each segment has source, destination port number (recall: well-known port numbers for specific applications) r host uses IP addresses & port numbers to direct segment to appropriate socket source port #dest port # 32 bits application data (message) other header fields TCP/UDP segment format

5 Connectionless demultiplexing r Create sockets with port numbers: DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222); r UDP socket identified by two-tuple: ( dest IP address, dest port number) r When host receives UDP segment: m checks destination port number in segment m directs UDP segment to socket with that port number r IP datagrams with different source IP addresses and/or source port numbers directed to same socket

6 Connectionless demux (cont) DatagramSocket serverSocket = new DatagramSocket(6428); Client IP:B P2 client IP: A P1 P3 server IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 SP: 6428 DP: 5775 SP: 5775 DP: 6428 SP provides “return address”

7 Connection-oriented demux r TCP socket identified by 4-tuple: m source IP address m source port number m dest IP address m dest port number r recv host uses all four values to direct segment to appropriate socket r Server host may support many simultaneous TCP sockets: m each socket identified by its own 4-tuple r Web servers have different sockets for each connecting client m non-persistent HTTP will have different socket for each request

8 Connection-oriented demux (cont) Client IP:B P1 client IP: A P1P2P4 server IP: C SP: 9157 DP: 80 SP: 9157 DP: 80 P5P6P3 D-IP:C S-IP: A D-IP:C S-IP: B SP: 5775 DP: 80 D-IP:C S-IP: B

9 Outline r Transport-layer services r Multiplexing and demultiplexing r Connectionless transport: UDP

10 UDP: User Datagram Protocol [RFC 768] r “no frills,” “bare bones” Internet transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others Why is there a UDP? r no connection establishment (which can add delay) r simple: no connection state at sender, receiver r small segment header r no congestion control: UDP can blast away as fast as desired

11 UDP: more r often used for streaming multimedia apps m loss tolerant m rate sensitive r other UDP uses m DNS m SNMP r reliable transfer over UDP: add reliability at application layer m application-specific error recovery! source port #dest port # 32 bits Application data (message) UDP segment format length checksum Length, in bytes of UDP segment, including header

12 UDP checksum Sender: r treat segment contents as sequence of 16-bit integers r checksum: addition (1’s complement sum) of segment contents r sender puts checksum value into UDP checksum field Receiver: r compute checksum of received segment r check if computed checksum equals checksum field value: m NO - error detected m YES - no error detected. But maybe errors nonetheless? More later …. Goal: detect “errors” (e.g., flipped bits) in transmitted segment

13 Internet Checksum Example r Note m When adding numbers, a carryout from the most significant bit needs to be added to the result r Example: add two 16-bit integers wraparound sum checksum

14 Outline r Transport-layer services r Multiplexing and demultiplexing r Connectionless transport: UDP r Principles of reliable data transfer

15 Principles of Reliable data transfer r important in app., transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

16 Reliable data transfer: getting started send side receive side rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer udt_send(): called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv(): called when packet arrives on rcv-side of channel deliver_data(): called by rdt to deliver data to upper

17 Reliable data transfer: getting started We’ll: r incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) r consider only unidirectional data transfer m but control info will flow on both directions! r use finite state machines (FSM) to specify sender, receiver state 1 state 2 event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event event actions

18 Rdt1.0: reliable transfer over a reliable channel r underlying channel perfectly reliable m no bit errors m no loss of packets r separate FSMs for sender, receiver: m sender sends data into underlying channel m receiver read data from underlying channel Wait for call from above packet = make_pkt(data) udt_send(packet) rdt_send(data) extract (packet,data) deliver_data(data) Wait for call from below rdt_rcv(packet) sender receiver

19 Rdt2.0: channel with bit errors r underlying channel may flip bits in packet m checksum to detect bit errors r the question: how to recover from errors: m acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK m negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors m sender retransmits pkt on receipt of NAK  new mechanisms in rdt2.0 (beyond rdt1.0 ): m error detection m receiver feedback: control msgs (ACK,NAK) rcvr->sender

20 rdt2.0: FSM specification Wait for call from above snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below sender receiver rdt_send(data) 

21 rdt2.0: operation with no errors Wait for call from above snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below rdt_send(data) 

22 rdt2.0: error scenario Wait for call from above snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below rdt_send(data) 

23 rdt2.0 has a fatal flaw! What happens if ACK/NAK corrupted? r sender doesn’t know what happened at receiver! r can’t just retransmit: possible duplicate Handling duplicates: r sender adds sequence number to each pkt r sender retransmits current pkt if ACK/NAK garbled r receiver discards (doesn’t deliver up) duplicate pkt Sender sends one packet, then waits for receiver response stop and wait

24 rdt2.1: sender, handles garbled ACK/NAKs Wait for call 0 from above sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) Wait for ACK or NAK 0 udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Wait for call 1 from above Wait for ACK or NAK 1  

25 Outline r Reliable transfer protocols m rdt2.1: sender, handles garbled ACK/NAKs m rdt2.2: a NAK-free protocol m rdt3.0: channels with errors and loss m Pipelined protocols Go-back-N Selective repeat r Connection-oriented transport: TCP m Overview and segment structure

26 rdt2.1: receiver, handles garbled ACK/NAKs Wait for 0 from below sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)

27 Outline r Reliable transfer protocols m rdt2.1: sender, handles garbled ACK/NAKs m rdt2.2: a NAK-free protocol m rdt3.0: channels with errors and loss m Pipelined protocols Go-back-N Selective repeat r Connection-oriented transport: TCP m Overview and segment structure

28 rdt2.2: a NAK-free protocol r same functionality as rdt2.1, using ACKs only r instead of NAK, receiver sends ACK for last pkt received OK m receiver must explicitly include seq # of pkt being ACKed r duplicate ACK at sender results in same action as NAK: retransmit current pkt

29 rdt2.2: sender, receiver fragments Wait for call 0 from above sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) Wait for ACK 0 sender FSM fragment Wait for 0 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt) receiver FSM fragment 

30 Outline r Reliable transfer protocols m rdt2.1: sender, handles garbled ACK/NAKs m rdt2.2: a NAK-free protocol m rdt3.0: channels with errors and loss m Pipelined protocols Go-back-N Selective repeat r Connection-oriented transport: TCP m Overview and segment structure

31 rdt3.0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) m checksum, seq. #, ACKs, retransmissions will be of help, but not enough Approach: sender waits “reasonable” amount of time for ACK r retransmits if no ACK received in this time r if pkt (or ACK) just delayed (not lost): m retransmission will be duplicate, but use of seq. #’s already handles this m receiver must specify seq # of pkt being ACKed r requires countdown timer

32 rdt3.0 sender sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) Wait for ACK0 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) Wait for call 1 from above sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer udt_send(sndpkt) start_timer timeout udt_send(sndpkt) start_timer timeout rdt_rcv(rcvpkt) Wait for call 0from above Wait for ACK1  rdt_rcv(rcvpkt)   

33 rdt3.0 in action

34 rdt3.0 in action