Transport Layer3-*3. Transport LayerComputer Networking: A Top Down Approach 6th edition Jim Kurose, Keith Ross Addison-Wesley March 2012

All material copyright 1996-2012 J.F Kurose and K.W. Ross, All Rights Reserved

Transport Layer

Transport Layer3-*3. Transport Layer: Goalsour goals: understand principles behind transport layer services:multiplexing, demultiplexingreliable data transferflow controlcongestion control

learn about Internet transport layer protocols:UDP: connectionless transportTCP: connection-oriented reliable transportTCP congestion control

Transport Layer

Transport Layer3-*3. Transport Layer: Outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

Transport Layer

Transport Layer3-*Transport services and protocolsprovide logical communication between app processes running on different hoststransport protocols run in end systems send side: breaks app messages into segments, passes to network layerrecv side: reassembles segments into messages, passes to app layermore than one transport protocol available to appsInternet: TCP and UDP

Transport Layer

Transport Layer3-*Transport vs. network layernetwork layer: logical communication between hosts

transport layer: logical communication between processes relies on and enhances network layer services12 kids in Anns house sending letters to 12 kids in Bills house:hosts = housesprocesses = kidsapp messages = letters in envelopestransport protocol = Ann and Bill who demux to in-house siblingsnetwork-layer protocol = postal service

household analogy:

Transport Layer

Transport Layer3-*Internet transport-layer protocolsreliable, in-order delivery (TCP)congestion control flow controlconnection setupunreliable, unordered delivery: UDPno-frills extension of best-effort IPservices not available: delay guaranteesbandwidth guarantees

Transport Layer

Transport Layer3-*3. Transport Layer: Outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

Transport Layer

Transport Layer3-*Multiplexing/demultiplexingprocesssockettransportapplicationphysicallinknetworkP2P1transportapplicationphysicallinknetworkP4transportapplicationphysicallinknetworkP3

Transport Layer

Transport Layer3-*How demultiplexing workshost receives IP datagramseach datagram has source and destination IP addresseach datagram carries one transport-layer segmenteach segment has source and destination port number host uses IP addresses & port numbers to direct segment to right socketsource port #dest port #32 bitsapplicationdata (payload)other header fieldsTCP/UDP segment format

Transport Layer

Transport Layer3-*Connectionless demultiplexingrecall: created socket has host-local port #: DatagramSocket mySocket1 = new DatagramSocket(12534);

when host receives UDP segment:checks destination IP and port # in segmentdirects UDP segment to socket bound to that (IP,port)

recall: when creating datagram to send into UDP socket, must specifydestination IP addressdestination port #IP datagrams with same dest. (IP, port), but different source IP addresses and/or source port numbers will be directed to same socket

Transport Layer

Transport Layer3-*Connectionless demux: exampleDatagramSocket serverSocket = new DatagramSocket (6428);

transportapplicationphysicallinknetworkP3transportapplicationphysicallinknetworkP1transportapplicationphysicallinknetworkP4DatagramSocket mySocket1 = new DatagramSocket (5775);

DatagramSocket mySocket2 = new DatagramSocket (9157);

Transport Layer

Transport Layer3-*Connection-oriented demuxTCP socket identified by 4-tuple: source IP addresssource port numberdest IP addressdest port numberdemux: receiver uses all four values to direct segment to right socketserver host has many simultaneous TCP sockets:each socket identified by its own 4-tupleweb servers have different socket each clientnon-persistent HTTP will have different socket for each request

Transport Layer

Transport Layer3-*Connection-oriented demux: exampletransportapplicationphysicallinknetworkP3transportappphysicallinkP4transportapplicationphysicallinknetworkP2host: IP address Ahost: IP address CnetworkP6P5P3three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different socketsserver: IP address Bserver socket, also port 80

Transport Layer

Transport Layer3-*Connection-oriented demux: exampletransportapplicationphysicallinknetworkP3transportappphysicallinktransportapplicationphysicallinknetworkP2host: IP address Ahost: IP address Cserver: IP address BnetworkP3P4server socket, also port 80threaded server

Transport Layer

Transport Layer3-*3. Transport Layer: Outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

Transport Layer

Transport Layer3-*UDP: User Datagram Protocol [RFC 768]no frills, bare bones transport protocol for best effort service, UDP segments may be:lostdelivered out-of-orderconnectionless:no sender-receiver handshakingeach UDP segment handled independentlyUDP uses:streaming multimedia apps (loss tolerant, rate sensitive)DNSSNMPreliable transfer over UDP: add reliability at application layerapplication-specific error recovery!

Transport Layer

Transport Layer3-*UDP: segment headersource port #dest port #32 bitsapplicationdata (payload)UDP segment formatlengthchecksumlength, in bytes of UDP segment, including headerno connection establishment (which can add delay)simple: no connection state at sender, receiversmall header sizeno congestion control: UDP can blast away as fast as desiredwhy is there a UDP?

Transport Layer

Transport Layer3-*UDP checksumsender:treat segment contents, including header fields, as sequence of 16-bit integerschecksum: addition (ones complement sum) of segment contentssender puts checksum value into UDP checksum fieldreceiver:compute checksum of received segmentcheck if computed checksum equals checksum field value:NO - error detectedYES - no error detected. But maybe errors nonetheless? More later .Goal: detect errors (flipped bits) in segments

Transport Layer

Transport Layer3-*Internet checksum: exampleexample: add two 16-bit integers1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1wraparoundsumchecksumNote: when adding numbers, a carryout from the most significant bit needs to be added to the result

Transport Layer

Q1: Sockets and multiplexingTCP uses more information in packet headers in order to demultiplex packets compared to UDP.TrueFalseTransport Layer3-*

Transport Layer

Q2: Sockets UDPSuppose we use UDP instead of TCP under HTTP for designing a web server where all requests and responses fit in a single packet. Suppose a 100 clients are simultaneously communicating with this web server. How many sockets are respectively at the server and at each client?1,12,1200,2100,1101, 1Transport Layer3-*

Transport Layer

Q3: Sockets TCPSuppose a 100 clients are simultaneously communicating with a (traditional HTTP/TCP) web server. How many sockets are respectively at the server and at each client?1,12,1200,2100,1101, 1Transport Layer3-*

Transport Layer

Q4: Sockets TCPSuppose a 100 clients are simultaneously communicating with (a traditional HTTP/TCP) web server. Do all of the sockets at the server have the same server-side port number?YesNoTransport Layer3-*

Transport Layer

Q5: UDP checksumsLets denote a UDP packet as (checksum, data) ignoring other fields for this question. Suppose a sender sends (0010, 1110) and the receiver receives (0011,1110). Which of the following is true of the receiver?Thinks the packet or checksum is corrupted and discards the packet.Thinks only the checksum is corrupted and delivers the correct data to the application. Can possibly conclude that nothing is wrong with the packet.A and CTransport Layer3-*

Transport Layer

Transport Layer3-*3. Transport Layer: Outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

Transport Layer

Transport Layer3-*Principles of reliable data transferimportant in application, transport, link layerstop-10 list of important networking topics!

characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

Transport Layer

Transport Layer3-*characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)Principles of reliable data transferimportant in application, transport, link layerstop-10 list of important networking topics!

Transport Layer

Transport Layer3-*characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)important in application, transport, link layerstop-10 list of important networking topics!

Principles of reliable data transfer

Transport Layer

Transport Layer3-*Reliable data transfer: getting startedsendsidereceiveside

Transport Layer

Transport Layer3-*well:incrementally develop sender, receiver sides of reliable data transfer protocol (rdt)consider only unidirectional data transferbut control info will flow on both directions!use finite state machines (FSM) to specify sender, receiverstate1state2event causing state transitionactions taken on state transitionstate: when in this state next state uniquely determined by next eventeventactionsReliable data transfer: getting started

Transport Layer

Transport Layer3-*rdt1.0: reliable transfer over a reliable channelunderlying channel perfectly reliableno bit errorsno loss of packetsseparate FSMs for sender, receiver:sender sends data into underlying channelreceiver reads data from underlying channelWait for call from abovepacket = make_pkt(data)udt_send(packet)rdt_send(data)extract (packet,data)deliver_data(data)Wait for call from belowrdt_rcv(packet)senderreceiver

Transport Layer

Transport Layer3-*underlying channel may flip bits in packetchecksum to detect bit errorsthe question: how to recover from errors:acknowledgements (ACKs): receiver explicitly tells sender that pkt received OKnegative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errorssender retransmits pkt on receipt of NAKnew mechanisms in rdt2.0 (beyond rdt1.0):error detectionreceiver feedback: control msgs (ACK,NAK) rcvr->senderrdt2.0: channel with bit errorsHow do humans recover from errorsduring conversation?

Transport Layer

Transport Layer3-*underlying channel may flip bits in packetchecksum to detect bit errorsthe question: how to recover from errors:acknowledgements (ACKs): receiver explicitly tells sender that pkt received OKnegative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errorssender retransmits pkt on receipt of NAKnew mechanisms in rdt2.0 (beyond rdt1.0):error detectionfeedback: control msgs (ACK,NAK) from receiver to senderrdt2.0: channel with bit errors

Transport Layer

Transport Layer3-*rdt2.0: FSM specificationWait for call from abovesndpkt = 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)senderreceiverrdt_send(data)L

Transport Layer

Transport Layer3-*rdt2.0: operation with no errorsWait for call from abovesnkpkt = 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)Wait for call from belowrdt_send(data)L

Transport Layer

Transport Layer3-*rdt2.0: error scenarioWait for call from abovesnkpkt = 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)Wait for call from belowrdt_send(data)L

Transport Layer

Transport Layer3-*rdt2.0 has a fatal flaw!what happens if ACK/NAK corrupted?sender doesnt know what happened at receiver!cant just retransmit: possible duplicate

handling duplicates: sender retransmits current pkt if ACK/NAK corruptedsender adds sequence number to each pktreceiver discards (doesnt deliver up) duplicate pkt

Transport Layer

Transport Layer3-*rdt2.1: sender, handles garbled ACK/NAKsWait for call 0 from abovesndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)rdt_send(data)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) LL

Transport Layer

Transport Layer3-*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)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)rdt2.1: receiver, handles garbled ACK/NAKs

Transport Layer

Transport Layer3-*

Transport Layer

Transport Layer3-*rdt2.1: discussionsender:seq # added to pkttwo seq. #s (0,1) will suffice. Why?must check if received ACK/NAK corrupted twice as many statesstate must remember whether expected pkt should have seq # of 0 or 1

receiver:must check if received packet is duplicatestate indicates whether 0 or 1 is expected pkt seq #note: receiver can not know if its last ACK/NAK received OK at senderQ: Do we really need both ACKs and NACKs?

Transport Layer

Transport Layer3-*rdt2.2: a NAK-free protocolsame functionality as rdt2.1, using ACKs onlyinstead of NAK, receiver sends ACK for last pkt received OKreceiver must explicitly include seq # of pkt being ACKed duplicate ACK at sender results in same action as NAK: retransmit current pkt

Transport Layer

Transport Layer3-*rdt2.2: sender, receiver fragments

Transport Layer

Transport Layer3-*rdt3.0: channels with errors and lossnew assumption: underlying channel can also lose packets (data, ACKs)checksum, seq. #, ACKs, retransmissions will be of help but not enoughapproach: sender waits reasonable amount of time for ACK retransmits if no ACK received in this timeif pkt (or ACK) just delayed (not lost):retransmission will be duplicate, but seq. #s already handles thisreceiver must specify seq # of pkt being ACKedrequires countdown timer

Transport Layer

Transport Layer3-*rdt3.0 sendersndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timerrdt_send(data)rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timerrdt_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_timerstop_timerudt_send(sndpkt)start_timertimeoutudt_send(sndpkt)start_timertimeoutrdt_rcv(rcvpkt)Lrdt_rcv(rcvpkt)LLL

Transport Layer

Transport Layer3-*senderreceiverrcv pkt1rcv pkt0send ack0send ack1send ack0rcv ack0send pkt0send pkt1rcv ack1send pkt0rcv pkt0(a) no losssenderreceiverrcv pkt1rcv pkt0send ack0send ack1send ack0rcv ack0send pkt0send pkt1rcv ack1send pkt0rcv pkt0(b) packet lossrdt3.0 in action

Transport Layer

Transport Layer3-*rdt3.0 in actionrcv pkt1send ack1(detect duplicate)senderreceiverrcv pkt1rcv pkt0send ack0send ack1send ack0rcv ack0send pkt0send pkt1rcv ack1send pkt0rcv pkt0(c) ACK lossrcv pkt1send ack1(detect duplicate)senderreceiverrcv pkt1send ack0rcv ack0send pkt1send pkt0rcv pkt0(d) premature timeout/ delayed ACK

Transport Layer

Try writing rdt 3.0 receiver?Use rdt_rcv(), isCorrupt(), udt_send(pkt), extract(.), deliver(.), make_pkt(.), isAck(.), hasSeq(.)Transport Layer3-*

Transport Layer

Transport Layer3-*Performance of rdt3.0rdt3.0 is correct, but performance stinkse.g.: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:

U : utilization fraction of time sender busy sendingif RTT=30 msec, 1KB pkt every 30 msec: 33kB/sec thruput over 1 Gbps linknetwork protocol limits use of physical resources!

Transport Layer

0.00027

L / R

RTT + L / R

=

30.008

.008

=

U

=

Transport Layer3-*rdt3.0: stop-and-wait operationfirst packet bit transmitted, t = 0senderreceiverRTT last packet bit transmitted, t = L / Rfirst packet bit arriveslast packet bit arrives, send ACKACK arrives, send next packet, t = RTT + L / R

Transport Layer

0.00027

L / R

RTT + L / R

=

30.008

.008

=

U

=

Transport Layer3-*Pipelined protocolspipelining: sender allows multiple, in-flight, yet-to-be-acknowledged pktsrange of sequence numbers must be increasedbuffering at sender and/or receivertwo generic forms of pipelined protocols: go-Back-N, selective repeat

Transport Layer

Transport Layer3-*Pipelining: increased utilizationfirst packet bit transmitted, t = 0senderreceiverRTT last bit transmitted, t = L / Rfirst packet bit arriveslast packet bit arrives, send ACKACK arrives, send next packet, t = RTT + L / Rlast bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK3-packet pipelining increases utilization by a factor of 3!

Transport Layer

.0024

3L / R

0.00081

RTT + L / R

=

30.008

=

U

=

Q1: Reliable data transferWhich of the following are needed for reliable data transfer with only packet corruption (and no loss or reordering)? Use only as much as is strictly needed.ChecksumsChecksums, ACKs, NACKsChecksums, ACKsChecksums, ACKs, sequence numbersChecksums, ACKs, NACKs, sequence numbersTransport Layer3-*

Transport Layer

Q2: Reliable data transferIf packets (and ACKs and NACKs) could be lost, which of the following is true of rdt 2.1 (or 2.2)?Reliable, in-order delivery is still achieved.The protocol will get get stuck.The protocol will continue making progress but may skip delivering some messages.Transport Layer3-*

Transport Layer

Q3: Reliable data transferWhich of the following are needed for reliable data transfer to handle packet corruption and loss? Use only as much as is strictly needed.Checksums, timeouts, and fries with thatChecksums, ACKs, sequence numbersChecksums, ACKs, timeouts, pipelined protocolChecksums, ACKs, sequence numbers, timeoutsChecksums, ACKs, NACKs, sequence numbers, timeoutsTransport Layer3-*

Transport Layer

Q4: Reliable data transferrdt 3.0 handles corruption and loss but not reordering. True or false?TrueFalseTransport Layer3-*

Transport Layer

Transport Layer3-*Pipelined protocols: overviewGo-back-N:sender can have up to N unacked packets in pipelinereceiver only sends cumulative ackdoesnt ack packet if theres a gapsender has timer for oldest unacked packetwhen timer expires, retransmit all unacked packetsSelective Repeat:sender can have up to N unacked packets in pipelinercvr sends individual ack for each packet

sender maintains timer for each unacked packetwhen timer expires, retransmit only that unacked packet

Transport Layer

Transport Layer3-*Go-Back-N: senderk-bit seq # in pkt headerwindow of up to N, consecutive unacked pkts allowed

ACK(n): ACKs all pkts up to, including # n - cumulative ACKmay receive duplicate ACKs (see receiver)timer for oldest in-flight pkttimeout(n): retransmit packet n and all higher seq # pkts in window

Transport Layer

Transport Layer3-*GBN: sender extended FSMstart_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])udt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ }else refuse_data(data)base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else restart_timerrdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

L

Transport Layer

Transport Layer3-*ACK-only: always send ACK for correctly-received pkt with highest in-order seq #may generate duplicate ACKsneed only remember expectedseqnumout-of-order pkt: discard (dont buffer): no receiver buffering!re-ACK pkt with highest in-order seq #Waitudt_send(sndpkt)default

rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++expectedseqnum=1sndpkt = make_pkt(expectedseqnum,ACK,chksum)

LGBN: receiver extended FSM

Transport Layer

Transport Layer3-*GBN in actionsend pkt0send pkt1send pkt2send pkt3(wait)senderreceiverreceive pkt0, send ack0receive pkt1, send ack1 receive pkt3, discard, (re)send ack1rcv ack0, send pkt4rcv ack1, send pkt5

pkt 2 timeoutsend pkt2send pkt3send pkt4send pkt5Xlossreceive pkt4, discard, (re)send ack1receive pkt5, discard, (re)send ack1rcv pkt2, deliver, send ack2rcv pkt3, deliver, send ack3rcv pkt4, deliver, send ack4rcv pkt5, deliver, send ack5ignore duplicate ACKsender window (N=4)0 1 2 3 4 5 6 7 8

Transport Layer

Transport Layer3-*Selective repeatreceiver individually acknowledges all correctly received pktsbuffers pkts, as needed, for eventual in-order delivery to upper layersender only resends pkts for which ACK not receivedsender timer for each unACKed pktsender windowN consecutive seq #slimits seq #s of sent, unACKed pkts

Transport Layer

Transport Layer3-*Selective repeat: sender, receiver windows

Transport Layer

Transport Layer3-*Selective repeatdata from above:if next available seq # in window, send pkttimeout(n):resend pkt n, restart timerACK(n) in [sendbase,sendbase+N]:mark pkt n as receivedif n smallest unACKed pkt, advance window base to next unACKed seq #

pkt n in [rcvbase, rcvbase+N-1]send ACK(n)out-of-order: bufferin-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pktpkt n in [rcvbase-N,rcvbase-1]ACK(n)otherwise: ignore

Transport Layer

Q: what happens when ack2 arrives?Transport Layer3-*Selective repeat in actionsend pkt0send pkt1send pkt2send pkt3(wait)senderreceiverreceive pkt0, send ack0receive pkt1, send ack1 receive pkt3, buffer, send ack3rcv ack0, send pkt4rcv ack1, send pkt5

pkt 2 timeoutsend pkt2Xlossreceive pkt4, buffer, send ack4receive pkt5, buffer, send ack5rcv pkt2; deliver pkt2,pkt3, pkt4, pkt5; send ack2record ack3 arrivedsender window (N=4)0 1 2 3 4 5 6 7 8 record ack4 arrivedrecord ack4 arrived

Transport Layer

Transport Layer3-*Selective repeat:dilemmaexample: seq #s: 0, 1, 2, 3window size=3receiver window(after receipt)sender window(after receipt)receiver cant see sender side.receiver behavior identical in both cases!somethings (very) wrong!receiver sees no difference in two scenarios!duplicate data accepted as new in (b)

Q: what relationship between size of seq # space and window size to avoid problem in (b)?

Transport Layer

Q1: RDT pipeliningConsider a path of bottleneck capacity C, round-trip time T, and maximum segment size S. If a pipelined rdt protocol maintains a window of N outstanding packets, how much does it improve throughput compared to a stop-and-wait rdt protocol (when no losses are actually happening)? Assume NS/C < T.NNS/(CT+S)(NS/C)/(T+NS/C)NTC/S

Transport Layer3-*

Transport Layer

Q2: RDT pipeliningConsider a path of bottleneck capacity C, round-trip time T, and maximum segment size S. What is the greatest throughput improvement factor that an ideal pipelined protocol (assuming corruptions and loss are negligible) can provide compared to a stop-and-wait protocol?(CT+S)/S2S/(CT+S)(S/C)/(T+S/C)(TC/S)^2

Transport Layer3-*

Transport Layer

Q3 UDP & TCPWhich of the following is true?UDP does not maintain connection state and does not have error detectionTCP is a connectionless protocol with reliable, in-order delivery and error detectionUDP has error detection but no connection stateUDP only has error detection but TCP also has error correctionTransport Layer3-*

Transport Layer

Q4 Go-back-N, selective repeat Which of the following is not true?GBN uses cumulative ACKs, SR uses individual ACKsBoth GBN and SR use timeouts to address packet lossGBN maintains a separate timer for each outstanding packetSR maintains a separate timer for each outstanding packetNeither GBN nor SR use NACKsTransport Layer3-*

Transport Layer

Q5 Go-back-N, selective repeat Suppose a receiver that has received all packets up to and including sequence number 24 and next receives packet 27 and 28. In response, what are the sequence numbers in the ACK(s) sent out by the GBN and SR receiver respectively?[27,28], [28][24,24], [27,28][27,28], [27,28][25], [25][nothing], [27, 28]Transport Layer3-*

Transport Layer

Q6 Go-back-NConsider a GBN protocol with a sender window of 6 and a large sequence # space. Suppose the next in-order sequence number the receiver is expecting is M. At this time instant, which of the following sequence #s can not be part of the senders window? Assume no reordering.MM+1M+5M-6M-7Transport Layer3-*

Transport Layer

Q7 Go-back-NConsider a GBN protocol with a sender window of 6 and a large sequence # space. Suppose the next in-order sequence number the receiver is expecting is M. At this instant, which of the following can not be the sequence # in an in-flight ACK from the receiver? Assume no reordering.M-1M-6M-7M-8M-11Transport Layer3-*

Transport Layer

Transport Layer3-*3. Transport Layer: Outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

Transport Layer

Transport Layer3-*TCP: Overview RFCs: 793,1122,1323, 2018, 2581full duplex data:bi-directional data flow in same connectionMSS: maximum segment sizeconnection-oriented: handshaking (exchange of control msgs) inits sender, receiver state before data exchangeflow controlled:sender will not overwhelm receiverpoint-to-point:one sender, one receiver reliable, in-order byte steam:no message boundariespipelined:TCP congestion and flow control set window size

Transport Layer

Transport Layer3-*TCP segment structuresource port #dest port #32 bitsapplicationdata (variable length)sequence numberacknowledgement numberreceive windowUrg data pointerchecksumFSRPAUheadlennotusedoptions (variable length)URG: urgent data (generally not used)ACK: ACK #validPSH: push data now(generally not used)RST, SYN, FIN:connection estab(setup, teardowncommands)# bytes rcvr willingto acceptcountingby bytes of data(not segments!)Internetchecksum(as in UDP)

Transport Layer

Transport Layer3-*TCP seq. numbers, ACKssequence number:byte stream # of first byte in segments dataacknowledgement number:seq # of next byte expected from other sidecumulative ACKQ: how receiver handles out-of-order segmentsA: TCP spec doesnt say, - up to implementorsent ACKedsent, not-yet ACKed(in-flight)usablebut not yet sentnot usablewindow size Nsender sequence number space

Transport Layer

Transport Layer3-*TCP seq. numbers, ACKsUsertypesChost ACKsreceipt of echoedChost ACKsreceipt ofC, echoesback Csimple character echo applicationHost BHost ASeq=42, ACK=79, data = CSeq=79, ACK=43, data = CSeq=43, ACK=80

Transport Layer

Transport Layer3-*TCP round trip time, timeoutQ: how to set TCP timeout value?longer than RTTbut RTT variestoo short: premature timeout, unnecessary retransmissionstoo long: slow reaction to segment lossQ: how to estimate RTT?SampleRTT: measured time from segment transmission to ACK receiptignore retransmissionsSampleRTT will vary, want estimated RTT smootheraverage several recent measurements, not just current SampleRTT

Transport Layer

Transport Layer3-*SmoothedRTTi = (1- )*SmoothedRTTi-1 + *SampleRTTiexponential weighted moving averageinfluence of past sample decreases exponentially fasttypical value: = 0.125TCP round trip time, timeoutRTT (milliseconds)RTT: gaia.cs.umass.edu to fantasia.eurecom.frsampleRTTEstimatedRTT

Transport Layer

Transport Layer3-*timeout interval: SmoothedRTT plus safety marginlarge variation in SmootedRTT larger safety marginestimate SampleRTT deviation from SmoothedRTT: DevRTTi = (1-)*DevRTTi-1 + *|SampleRTTi-SmoothedRTTi|TCP round trip time, timeout(typically, = 0.25)TimeoutInterval = SmoothedRTT + 4*DevRTTaverage RTTsafety margin

Transport Layer

Transport Layer3-*Upon ACK receipt timeout SmoothedRTT + 4*DevRTTUpon a timeout:timeout 2*timeoutdoubling provides a limited form of congestion control (more later)TCP timeout summary

Transport Layer

Transport Layer3-*3. Transport Layer: Outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

Transport Layer

Transport Layer3-*TCP reliable data transferTCP creates rdt service on top of IPs unreliable servicepipelined segmentscumulative acks selective acks often supported as an optionsingle retransmission timer retransmissions triggered by:timeout eventsduplicate acks

lets initially consider simplified TCP sender:ignore duplicate acksignore flow control, congestion control

Transport Layer

Transport Layer3-*TCP sender events:data rcvd from app:create segment with seq # (= byte-stream number of first data byte in segment)start timer (for oldest unacked segment) if not already running TimeOutInterval = smoothed_RTT + 4*deviation_RTTtimeout:retransmit segment that caused timeoutrestart timer ack rcvd:if ack acknowledges previously unacked segmentsupdate what is known to be ACKed(re-)start timer if still unacked segments

Transport Layer

Transport Layer3-*TCP sender (simplified)waitfor eventNextSeqNum = InitialSeqNumSendBase = InitialSeqNumL

Transport Layer

Transport Layer3-*TCP: retransmission scenarioslost ACK scenarioHost BHost ASeq=92, 8 bytes of dataACK=100Seq=92, 8 bytes of dataXtimeoutACK=100premature timeoutHost BHost ASeq=92, 8 bytes of dataSeq=92, 8bytes of datatimeoutACK=120SendBase=100SendBase=120SendBase=120SendBase=92

Transport Layer

Transport Layer3-*TCP: retransmission scenariosXcumulative ACKHost BHost ASeq=92, 8 bytes of dataSeq=120, 15 bytes of data

Transport Layer

Transport Layer3-*TCP ACK generation [RFC 1122, RFC 2581]event at receiver

arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed

arrival of in-order segment withexpected seq #. One other segment has ACK pending

arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected

arrival of segment that partially or completely fills gap

TCP receiver action

delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK

immediately send single cumulative ACK, ACKing both in-order segments

immediately send duplicate ACK, indicating seq. # of next expected byte

immediate send ACK, provided thatsegment starts at lower end of gap

Transport Layer

Transport Layer3-*TCP fast retransmittime-out period often relatively long:long delay before resending lost packetdetect lost segments via duplicate ACKs.sending many segments back-to-back plus occasional segment loss duplicate ACKs

if sender receives 3 ACKs for same data(triple duplicate ACKs), resend unacked segment with smallest seq #likely that unacked segment lost, so dont wait for timeoutTCP fast retransmit(triple duplicate ACKs),

Transport Layer

Transport Layer3-*Xfast retransmit after sender receipt of triple duplicate ACKHost BHost ASeq=92, 8 bytes of dataTCP fast retransmitSeq=100, 20 bytes of dataSeq=100, 20 bytes of data

Transport Layer

Transport Layer3-*3. Transport Layer: Outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

Transport Layer

Transport Layer3-*TCP flow controlapplicationprocessTCPcodeIPcodereceiver protocol stackapplication may remove data from TCP socket buffers . slower than TCP receiver is delivering(sender is sending)from sender

Transport Layer

Transport Layer3-*TCP flow controlrwndRcvBufferTCP segment payloadsto application processreceiver advertises free buffer space by including rwnd value in TCP header of rcvr-to-sndr segmentsRcvBuffer size can be set via socket options most operating systems auto-adjust RcvBuffer

sender limits amount of unacked (in-flight) data to receivers rwnd value to ensure receive buffer will not overflowreceiver-side buffering

Transport Layer

Transport Layer3-*3. Transport Layer: Outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

Transport Layer

Transport Layer3-*Connection Managementbefore exchanging data, sender/receiver handshake:agree to establish connection (each knowing the other willing to establish connection)agree on connection parametersconnection state: ESTABconnection variables:seq # client-to-server server-to-clientrcvBuffer size at server,client applicationnetworkconnection state: ESTABconnection Variables:seq # client-to-server server-to-clientrcvBuffer size at server,client applicationnetworkSocket clientSocket = newSocket("hostname","port number");Socket connectionSocket = welcomeSocket.accept();

Transport Layer

Transport Layer3-*Q: will 2-way handshake always work in network?variable delaysretransmitted messages (e.g. req_conn(x)) due to message lossmessage reorderingcant see other side2-way handshake:Lets talkOKESTABESTABchoose x

req_conn(x)ESTABESTABacc_conn(x)Agreeing to establish a connection

Transport Layer

Transport Layer3-*Agreeing to establish a connection2-way handshake failure scenarios:

Transport Layer

Transport Layer3-*TCP 3-way handshakeESTAB

Transport Layer

Transport Layer3-*TCP 3-way handshake: FSMclosedLlistenSYNrcvdSYNsentESTABSocket clientSocket = newSocket("hostname","port number");SYN(seq=x)Socket connectionSocket = welcomeSocket.accept();SYN(x)

SYNACK(seq=y,ACKnum=x+1)create new socket for communication back to client

SYNACK(seq=y,ACKnum=x+1)

ACK(ACKnum=y+1)

ACK(ACKnum=y+1)

L

Transport Layer

Transport Layer3-*TCP: closing a connectionclient and server should each close their side of connectionby sending FIN (TCP segment with FIN flag = 1)should respond to received FIN with ACKon receiving FIN, ACK can be combined with own FINsimultaneous FIN exchanges should be handled

Transport Layer

Transport Layer3-*TCP: closing a connectionclient state

server state

ESTABESTABsocket.close()

Transport Layer

TCP: Overall state machineTransport Layer3-*

Transport Layer

Q1 TCP sequence numbers A TCP sender is just about to send a segment of size 100 bytes with sequence number 1234 and ack number 436 in the TCP header. What is the highest sequence number up to (and including) which this sender has received all bytes from the receiver?12334364351334536Transport Layer3-*

Transport Layer

Q2 TCP sequence numbers A TCP sender is just about to send a segment of size 100 bytes with sequence number 1234 and ack number 436 in the TCP header. Is it possible that the receiver has received byte number 1335?YesNoTransport Layer3-*

Transport Layer

Q3 TCP timeoutA TCP sender maintains a SmoothedRTT of 100ms. Suppose the next SampleRTT is 108ms. Which of the following is true of the sender?Will increase SmoothedRTT but leave the timeout unchangedWill increase timeoutWhether it increases SmoothedRTT depends on the deviation.Whether it increases the timeout depends on the deviationWill chomp on fries left over from the rdt question earlierTransport Layer3-*

Transport Layer

Q4 TCP timeoutA TCP sender maintains a SmoothedRTT of 100ms and DevRTT of 8ms. Suppose the next SampleRTT is 108ms. What is the new value of the timeout in milliseconds? (Numerical question)Transport Layer3-*

Transport Layer

Q5 TCP header fieldsWhich is the purpose of the receive window field in a TCP header?ReliabilityIn-order deliveryFlow controlCongestion controlPipelining

Transport Layer3-*

Transport Layer

Q6 TCP connection mgmtRoughly how much time does it take for both the TCP sender and receiver to establish connection state since the connect() call?RTT1.5RTT2RTT3RTT

Transport Layer3-*

Transport Layer

Q7 TCP reliabilityTCP uses cumulative ACKs like Go-back-N, but does not retransmit the entire window of outstanding packets upon a timeout. What mechanism lets TCP get away with this?Per-byte sequence and ack numbersTriple duplicate ACKsReceive window-based flow controlUsing a better timeout estimation methodKetchup (for the fries)

Transport Layer3-*

Transport Layer

Transport Layer3-*3. Transport Layer: Outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

Transport Layer

Transport Layer3-*congestion:informally: too many sources sending too much data too fast for network to handledifferent from flow control!manifestations:lost packets (buffer overflow at routers)long delays (queueing in router buffers)a top-10 problem!

Principles of congestion control

Transport Layer

Transport Layer3-*Causes/costs of congestion: scenario 1 two senders, two receiversone router, infinite buffers output link capacity: Rno retransmission

maximum per-connection throughput: R/2unlimited shared output link buffersHost Aoriginal data: lin Host Bthroughput: loutlarge delays as arrival rate, lin, approaches capacity

Transport Layer

Transport Layer3-*one router, finite buffers sender retransmission of timed-out packetapp-layer input = app-layer output: lin = louttransport-layer input includes retransmissions : lin lin

finite shared output link buffersHost Alin : original dataHost Bloutl'in: original data, plus retransmitted dataCauses/costs of congestion: scenario 2

Transport Layer

Transport Layer3-*idealization: perfect knowledgesender sends only when router buffers available

finite shared output link bufferslin : original dataloutl'in: original data, plus retransmitted datacopyfree buffer space!Causes/costs of congestion: scenario 2 Host BA

Transport Layer

Transport Layer3-*lin : original dataloutl'in: original data, plus retransmitted datacopyno buffer space!Idealization: known loss packets can be lost at router with full buffersender only resends if packet known to be lost

Causes/costs of congestion: scenario 2 AHost B

Transport Layer

Transport Layer3-*lin : original dataloutl'in: original data, plus retransmitted datafree buffer space!Causes/costs of congestion: scenario 2 Idealization: known loss packets can be lost at router with full buffersender only resends if packet known to be lost

AHost B

Transport Layer

Transport Layer3-*Alinloutl'incopyfree buffer space!R/2R/2loutHost BRealistic: duplicates packets can be lost at routers with full bufferssender times out prematurely, sending two copies, both of which are delivered

Causes/costs of congestion: scenario 2

Transport Layer

Transport Layer3-*R/2loutcosts of congestion: more work for same goodputunnecessary retransmission (link carries multiple copies of packet) decreases goodput

R/2Causes/costs of congestion: scenario 2 Realistic: duplicates packets can be lost at routers with full bufferssender times out prematurely, sending two copies, both of which are delivered

Transport Layer

Transport Layer3-*Congestion collapse: dramatic reduction in throughput (how?)

Causes/costs of congestion: scenario 3 C/2C/2loutlinHistory: In the late 80s, we learned this lesson the hard way.

Transport Layer

Transport Layer3-*four sendersmultihop pathstimeout/retransmit

Q: what happens as lin and lin increase ?finite shared output link buffersHost AloutCauses/costs of congestion: scenario 3 Host BHost CHost Dlin : original datal'in: original data, plus retransmitted dataA: as red lin increases, all arriving blue pkts at upper queue are dropped, blue throughput g 0

Transport Layer

Transport Layer3-*most important cost of congestion: when packet dropped, any upstream bandwidth used for that packet wasted. wastage can ripple into a collapse!Causes/costs of congestion: scenario 3 C/2C/2loutlin

Transport Layer

Transport Layer3-*Approaches towards congestion controltwo broad approaches towards congestion control:end-end congestion control:no explicit feedback from networkcongestion inferred from end-system observed loss, delayapproach taken by TCPnetwork-assisted congestion control:routers provide feedback to end systemssingle bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)explicit rate for sender to send at

Transport Layer

Transport Layer3-*Case study: ATM ABR congestion controlABR: available bit rate:elastic service if senders path underloaded: sender should use available bandwidthif senders path congested: sender throttled to minimum guaranteed rateRM (resource management) cells:sent by sender, interspersed with data cellsbits in RM cell set by switches (network-assisted) NI bit: no increase in rate (mild congestion)CI bit: congestion indicationRM cells returned to sender by receiver, with bits intact

Transport Layer

Transport Layer3-*Case study: ATM ABR congestion controltwo-byte ER (explicit rate) field in RM cellcongested switch may lower ER value in cellsenders send rate thus max supportable rate on pathEFCI bit in data cells: set to 1 in congested switchif data cell preceding RM cell has EFCI set, receiver sets CI bit in returned RM cellRM celldata cell

Transport Layer

Transport Layer3-*3. Transport Layer: Outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

Transport Layer

TCP congestion controlCongestion avoidance using AIMDSlow start upon a timeoutFast recovery to patch occasional lossTransport Layer3-*

Transport Layer

Transport Layer3-*Congestion avoidance: AIMDapproach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occursadditive increase: increase cwnd by 1 MSS every RTT until loss detectedmultiplicative decrease: cut cwnd in half after loss

cwnd: TCP sender congestion window sizeAIMD saw toothbehavior: probingfor bandwidthadditively increase window size . until loss occurs (then cut window in half)time

Transport Layer

Transport Layer3-*TCP congestion control windowsender limits transmission:

cwnd is dynamic, function of perceived congestion

TCP sending rate:roughly: send cwnd bytes, wait RTT for ACKS, then send more byteslast byteACKedsent, not-yet ACKed(in-flight)last byte sentcwndLastByteSent -LastByteAckedcwndsender sequence number space ratebytes/sec

Transport Layer

Transport Layer3-*TCP Slow Start when connection begins, increase rate exponentially until first loss event:initially cwnd = 1 MSSdouble cwnd every RTTdone by incrementing cwnd upon every ACKsummary: initial rate is slow but ramps up exponentially fastHost Aone segmentRTTHost Btwo segmentsfour segments

Transport Layer

Transport Layer3-*TCP: detecting, reacting to lossloss indicated by timeout:cwnd set to 1 MSS; window then grows exponentially (as in slow start) to threshold, then grows linearlyloss indicated by 3 duplicate ACKs: TCP RENOdup ACKs indicate network capable of delivering some segments cwnd is cut in half window then grows linearlyTCP Tahoe always sets cwnd to 1 (timeout or 3 duplicate acks)

Transport Layer

Transport Layer3-*Q: when should the exponential increase switch to linear? A: when cwnd gets to 1/2 of its value before timeout.

Implementation:variable ssthresh on loss event, ssthresh is set to 1/2 of cwnd just before loss eventTCP: slow start cong. avoidance

Transport Layer

Transport Layer3-*Summary: TCP Congestion Control

Transport Layer

Transport Layer3-*TCP throughput: Simplistic modelavg. TCP thruput as function of window size, RTT?ignore slow start, assume always data to sendW: window size (measured in bytes) where loss occursavg. window size (# in-flight bytes) is Wavg. throughput is 3/4W per RTTIn practice, W not known or fixed, so this model is too simplistic to be useful

Transport Layer

Transport Layer3-*TCP throughput: More practical modelThroughput in terms of segment loss probability, L, round-trip time T, and maximum segment size M [Mathis et al. 1997]:

Transport Layer

Transport Layer3-*TCP futures: TCP over long, fat pipesexample: 1500 byte segments, 100ms RTT, want 10 Gbps throughputrequires W = 83,333 in-flight segments as per the throughput formula to achieve 10 Gbps throughput, need a loss rate of L = 210-10 an unrealistically small loss rate!new versions of TCP for high-speed

Transport Layer

TCP throughput wrap-upSuppose sender window cwnd, receiver window rwndbottleneck capacity C round-trip time T path loss rate L max segment size MSS

Instantaneous TCP throughput = min(C, cwnd/T,rwnd/T)Steady-state TCP throughput = min(C, 1.22M/(TL))Throughput (of course) application sending rateTransport Layer3-*

Transport Layer

Transport Layer3-*fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/KTCP connection 1bottleneckroutercapacity RTCP FairnessTCP connection 2

Transport Layer

Transport Layer3-*Why is TCP fair?two competing sessions:additive increase gives slope of 1, as throughout increasesmultiplicative decrease decreases throughput proportionally RRequal bandwidth shareConnection 1 throughputConnection 2 throughputcongestion avoidance: additive increaseloss: decrease window by factor of 2congestion avoidance: additive increaseloss: decrease window by factor of 2

Transport Layer

Transport Layer3-*Fairness (more)Fairness and UDPmultimedia apps often do not use TCPrate throttling by congestion control can hurt streaming qualityinstead use UDP:send audio/video at constant rate, tolerate packet loss

Fairness, parallel TCP connectionsapplication can open many parallel connections between two hostsweb browsers do this e.g., link of rate R with 9 existing connections:new app asks for 1 TCP, gets R/10new app asks for 11 TCPs, gets R/2

Transport Layer

Q1 TCP congestion controlIn the figure, how many congestion avoidance intervals can you identify?01234Transport Layer3-*

Transport Layer

Q2 TCP congestion controlIn the figure, how many slow start intervals can you identify?01234Transport Layer3-*

Transport Layer

Q3 TCP congestion controlIn the figure, after the 16th transmission round, is segment loss detected by a triple duplicate ACK or timeout?Triple-dupTimeoutTransport Layer3-*

Transport Layer

Q4 TCP congestion controlIn the figure, after the 22nd transmission round, is segment loss detected by a triple duplicate ACK or timeout?Triple-dupTimeoutTransport Layer3-*

Transport Layer

Q5 TCP congestion controlIn the figure, what is the initial value of ssthresh?032644228Transport Layer3-*

Transport Layer

Q6 TCP congestion controlIn the figure, what is the value of ssthresh at the 18th round?Transport Layer3-*

Transport Layer

Q7 TCP congestion controlIn the figure, during what transmission round is the 70th segment sent?Transport Layer3-*

Transport Layer

Q8 TCP congestion controlIn the figure, if a loss is detected via a triple-duplicate ACK in the 26th round, what is the new value of the congestion window?Transport Layer3-*

Transport Layer

Q9 Congestion controlIn a network where the bottleneck links capacity strictly exceeds the combined sending rates of all applications, is congestion control still necessary?YesNoTransport Layer3-*

Transport Layer

Transport Layer3-*3. Summaryprinciples behind transport layer services:multiplexing, demultiplexingreliable data transferflow controlcongestion controlinstantiation, implementation in the InternetUDPTCPnext:leaving the network edge (application, transport layers)into the network core

Transport Layer

*******************Kurose and Ross forgot to say anything about wrapping the carry and adding it to low order bit**********************************************************************************************************