Chapter_3_v8.0.pptx

Editor's Notes

• #2: Version History 8.0 (April 2020) All slides reformatted for 16:9 aspect ratio All slides updated to 8th edition material Use of Calibri font, rather that Gill Sans MT Add LOTS more animation throughout added new 8th edition material on QUIC, CUBIC, delay-based congestion control lighter header font
• #5:  By logical communication , we mean that from an application’s perspective, it is as if the hosts running the processes were directly connected; in reality, the hosts may be on opposite sides of the planet, connected via numerous routers and a wide range of link types. Application processes use the logical communication provided by the transport layer to send messages to each other, free from the worry of the details of the physical infrastructure used to carry these messages. Let’s look at each of these three (logical communications, actions,
• #27: read this RFC – it’s only 2.5 pages!
• #38: note arrows through reliable data transfer channel is just one way – reliably send from sender to receiver
• #39: Spend some time talking about how its to the sender and receiver side protocol that IMPLEMENTS reliable data transfer Communication over unreliable channel is TWO-way: sender and receiver will exchange messages back and forth to IMPLEMENT one-way reliable data transfer
• #40: So we have a sender side and a receiver side. How much work they’ll have to do depends on the IMPAIRMENTS introduced by channel – if the channel is perfect – no problem!
• #41: Here’s a point of view to keep in mind – it’s easy for US to look at sender and receiver together and see what is happening. OH – that message sent was lost. But think about it say from senders POV How does the sender know if its transmitted message over the unreliable channel got though?? ONLY if receiver somehow signals to the sender that it was received. The key point here is that one side does NOT know what is going on at the other side – it’s as if there’s a curtain between them. Everything they know about the other can ONLY be learned by sending/receiving messages. Sender process wants to make sure a segment got through. But it can just somehow magically look through curtain to see if receiver got it. It will be up to the receiver to let the sender KNOW that it (the receiver) has correctly received the segment. How will the sender and receiver do that – that’s the PROTOCOL. Before starting to develop a protocol, let’s look more closely at the interface (the API if you will)
• #43: SO let’s get started in developing our reliable data transfer protocol, which we’ll call rdt (need a good acronym for protocol – like HTTP, TCP, UDP, IP) Bullet points 1 and 2 NOW if we are going to develop a protocol, so we’ll need some way to SPECIFY a protocol. How do we do that? We could write text, but as all know, that’s prone to misinterpretation, and might be incomplete. You might write a specification, and then think “oh yeah – I forgot about that case” What we need is more formal way to specify a protocol. In fact, with a formal specification there may be ways to PROVE PROPERTIES about a specification. But that’s an advanced topic we won’t get into here. We’ll start here by adopting a fairly simple protocol specification technique known as finite state machines (FSM) And as the name might suggest, a central notion of finite state machines is the notion of STATE <talk about state>
• #44: We’ll start with the simplest case possible - an unreliable channel that is, in fact perfect – no segments are lost, corrupted, dupplicated or reordered. The sender just sends and it pops out the other side(perhaps after some delay) perfectly.
• #59: We see the familiar four state sender from our rdt 2.1 and 2.2 protocols. Top two states when sending packet with zero seq # and bottom two
• #60: We see the familiar four state sender from our rdt 2.1 and 2.2 protocols. Top two states when sending packet with zero seq # and bottom two
• #63: if RTT=30 msec, 1KB pkt every 30 msec: 33kB/sec thruput over 1 Gbps link network protocol limits use of physical resources Let’s develop a formula for utilization
• #67: two generic forms of pipelined protocols: go-Back-N, selective repeat
• #68: window size of 14, 8 have been sent but are not yet ackowledgedm 6 sequence numbers are available for us. In woindow, but no calls from above to use them. Note – we’ll skip the Go-Back-N FSM specification you can chack that out in powerpoitn slides or book) TCP uses cumulative ACK
• #69: Note – we’ll skip the Go-Back-N FSM specification (actually it’s
• #70: Let’s skip FSM specification for GBN – check out the book or ppt – and let’s watch GBN sender and receivers in action. Let assume a window size of 4. at t=0, sender sends packets 0, 1, 2 3, 4, and packet 2 will be lost At the receiver: Packet 0 received ACK0 generated Packet 1 received ACK1 generated Packet 2 is lost, and so when packet 3 is received, ACK 1 is sent – that’s the cumulative ACK, re-Acknowledging the receipt of packet 1. and in this implementation packet 3 is discarded
• #71: An important mechanism of GBN was the use of the cumulative acknowledgements, and as we mentioned, cumulative ACKs are used in TCP An alternate ACK mechanism would be for the receiver to indiviually acknowledge specific packets as they are received. This mechanism is at the heart of the Selective repeat protocol.
• #73: If the packet is in order, its data will be delivered, as will any buffered data that can now be delived in order
• #78: Typical MSS is 1460 bytes
• #81: The key thing to note here is that the ACK number (43) on the B-to-A segment is one more than the sequence number (42) on the A-toB segment that triggered that ACK Similarly, the ACK number (80) on the last A-to-B segment is one more than the sequence number (79) on the B-to-A segment that triggered that ACK
• #83: This is how TCP re-computes the estimated RTT each time a new SampleRTT is taken. The process is knows as an exponeitally weighted moving average, shown by the equation here. <say it> Where alpha reflects the influence of the most recent measurements on the estimated RTT; a typical value of alpha used in implementaitons is .125 The graph at the bottom show measured RTTs beween a host in the Massachusetts and a host in France, as well as the estimated, “smoothed” RTT
• #84: Given this value of the estimated RTT, TCP computes the timeout interval to be the estimated RTT plus a “safety margin” And the intuition is that if we are seeing a large variation in SAMPLERTT – the RTT estimates are fluctuating a lot - then we’ll want a larger savety margin So TCP computes the Timeout interval to be the Estimated RTT plus 4 times a measure of deviation in the RTT. The deviation in the RTT is computed as the eWMA of the difference between the most recently measured SampleRTT from the Estimated RTT
• #85: Given these details of TCP sequence numbers, acks, and timers, we can now describe the big picture view of how the TCP sender and receiver operate You can check out FSMs in book; let’s just give an English text description here and let’s start with the sender.
• #86: Rather than immediately ACKnowledig this segment, many TCP implementations will wait for half a second for another in-order segment to arrive, and then generate a single cumulative ACK for both segments – thus decreasing the amount of ACK traffic. The arrival of this second in-order segment and the cumulative ACK generation that covers both segments is the second row in this table.
• #87: To cement our understanding of TCP reliability, let’s look a a few retransmission scenarios In the first case a TCP segments is transmited and the ACK is lost, and the TCP timeout mechanism results in another copy of being transmitted and then re-ACKed a the sender In the second example two segments are sent and acknowledged, but there is a premature timeout e for the first segment, which is retransmitted. Notet that when this retransmitted segment is received, the receiver has already received the first two segments, and so resends a cumulative ACK for both segments received so far, rather than an ACK for just this fist segment.
• #88: And in this last example, two segments are again transmitted, the first ACK is lost but the second ACK, a cumulative ACK arrives at the sender, which then can transmit a third segment, knowing that the first two have arrived, even though the ACK for the first segment was lost
• #89: Let’s wrap up our study of TCP reliability by discussing an optimization to the original TCP known as TCP fast retransmit, Take a look at this example on the right where 5 segments are transmitted and the second segment is lost. In this case the TCP receiver sends an ACK 100 acknowledging the first received segment. When the third segment arrives at the receiver, the TCP receiver sends another ACK 100 since the second segment has not arrived. And similarly for the 4th and 5th segments to arrive. Now what does the sender see? The sender receives the first ACK 100 it has been hoping for, but then three additional duplicate ACK100s arrive. The sender knows that somethings’ wrong – it knows the first segment arrived at the receiver but three later arriving segments at the receiver – the ones that generated the three duplicate ACKs – we received correctly but were not in order. That is, that there was a missing segment at the receiver when each of the three duplicate ACK were generated. With fast retransmit, the arrival of three duplicate ACK causes the sender to retransmit its oldest unACKed segment, without waiting for a timeout event. This allows TCP to recover more quickly from what is very likely a loss event specifically that the second segment has been lost, since three higher -numbered segments were received
• #91: (Presuming an intro) Before diving into the details of TCP flow control, let’s first get the general context and motivate the need for flow control. This diagram show a typical transport-layer implementation A segment is brought up the protocol stack to the transport layer, and the segment’s payload is removed from the segment and written INTO socket buffers. How does data get taken OUT of socket buffers? By applications performing socket reads, as we learned in Chapter 2. And so the question is “What happens if network layer delivers data faster than an application-layer process removes data from socket buffers?” Let’s watch a video of what happens when things arrive way too fast to fast to be processed. <video>. (I love that video). Another human analogy showing the need for flow control is the saying – to use some English slang - “no one can drink from a firehose” Flow control is a mechanism to the calamity of a receiver being over-run by a sender that is sending too fast – it allows the RECEIVER to explictly control the SENDER so sender won’t overflow receiver’s buffer by transmitting too much, too fast
• #92: (Presuming an intro) Before diving into the details of TCP flow control, let’s first get the general context and motivate the need for flow control. This diagram show a typical transport-layer implementation A segment is brought up the protocol stack to the transport layer, and the segment’s payload is removed from the segment and written INTO socket buffers. How does data get taken OUT of socket buffers? By applications performing socket reads, as we learned in Chapter 2. And so the question is “What happens if network layer delivers data faster than an application-layer process removes data from socket buffers?” Let’s watch a video of what happens when things arrive way too fast to fast to be processed. <video>. (I love that video). Another human analogy showing the need for flow control is the saying – to use some English slang - “no one can drink from a firehose” Flow control is a mechanism to the calamity of a receiver being over-run by a sender that is sending too fast – it allows the RECEIVER to explictly control the SENDER so sender won’t overflow receiver’s buffer by transmitting too much, too fast
• #93: (Presuming an intro) Before diving into the details of TCP flow control, let’s first get the general context and motivate the need for flow control. This diagram show a typical transport-layer implementation A segment is brought up the protocol stack to the transport layer, and the segment’s payload is removed from the segment and written INTO socket buffers. How does data get taken OUT of socket buffers? By applications performing socket reads, as we learned in Chapter 2. And so the question is “What happens if network layer delivers data faster than an application-layer process removes data from socket buffers?” Let’s watch a video of what happens when things arrive way too fast to fast to be processed. <video>. (I love that video). Another human analogy showing the need for flow control is the saying – to use some English slang - “no one can drink from a firehose” Flow control is a mechanism to the calamity of a receiver being over-run by a sender that is sending too fast – it allows the RECEIVER to explictly control the SENDER so sender won’t overflow receiver’s buffer by transmitting too much, too fast
• #94: (Presuming an intro) Before diving into the details of TCP flow control, let’s first get the general context and motivate the need for flow control. This diagram show a typical transport-layer implementation A segment is brought up the protocol stack to the transport layer, and the segment’s payload is removed from the segment and written INTO socket buffers. How does data get taken OUT of socket buffers? By applications performing socket reads, as we learned in Chapter 2. And so the question is “What happens if network layer delivers data faster than an application-layer process removes data from socket buffers?” Let’s watch a video of what happens when things arrive way too fast to fast to be processed. <video>. (I love that video). Another human analogy showing the need for flow control is the saying – to use some English slang - “no one can drink from a firehose” Flow control is a mechanism to the calamity of a receiver being over-run by a sender that is sending too fast – it allows the RECEIVER to explictly control the SENDER so sender won’t overflow receiver’s buffer by transmitting too much, too fast
• #95: Here’s how TCP implement flow control. The basic idea is simple – the receiver informs the sender how much free buffer space there is, and the sender is limited to send no more than this amount of data. That the value o RWND in the diagram to the right. This information is carried from the receiver to the sender in the “receiver advertised window” (do a PIP of header) in the TCP header, and the value will change as the amount of free buffer space fluctuates over time.
• #96: Here’s how TCP implement flow control. The basic idea is simple – the receiver informs the sender how much free buffer space there is, and the sender is limited to send no more than this amount of data. That the value o RWND in the diagram to the right. This information is carried from the receiver to the sender in the “receiver advertised window” (do a PIP of header) in the TCP header, and the value will change as the amount of free buffer space fluctuates over time.
• #97: The other TCP topic we’ll want to consider here is that of “connection management” The TCP sender and reciver have a number of pieces of shared state that they must establish before actually communication FIRST theym ust both agree that they WANT to communicate with each other Secondly there are connection parameters – the initial sequence number and the initial receiver-advertised bufferspace that they’ll want to agree on This is done via a so-called handshake protocol – the client reaching our to the server, and the server answering back. And before diving into the TCP handshake protocol, let’s first consider the problem of handshaking, of establishing shared state.
• #98: Here’s an example of a two way handshake. Alice reaches out to Bob and say’s “let’s talk” and Bob says OK, and they start their conversation For a network protocol, the equivalent protocol would be a client sending a “request connection” message saying ”let’s talk, the initial sequence number is x” And the server would respond with a message ”I accept your connect x” And the question we want to ask ourselves is <talk through> Will this work? Let’s look at a few scenarios…
• #102: TCP’s three way handshake, that operates as follows Let’s say the client and server both create a TCP socket as we learned about in Chapter 2 and enter the LISTEN state The client then connects to the server sending a SYN message with a sequence number x (SYN Message is an TCP Segment with SYN but set in the header – you might want to go back and review the TCP segment format!) The server is waiting for a connection, and receives the SYN message enters the SYN received state (NOT the established state and sends a SYN ACK message back. Finally the client sends an ACK message to the server, and when the server receiver this enters the ESTABLished state. This is when the application process would see the return from the wait on the socket accept() call
• #103: As usual, there’s a human protocol analogy to the three way handshake, and I still remember thinking about this clinging for my life while climbing up a rockface When you want start climbing you first say ON BELOW (meaning ARE YOU READY WITH MY SAFETY ROPE) THE BELYER (server) responds BELAY ON (that lets you know the belayer is ready for you) And then you say CLIMING It’s amazing what can pass through your head when your clinging for your life o a
• #104: All good things must come to an end, and that’s true for a TCP connection as well. And of course there’s a protocol for one side to gracefully close of a TCP connection using a FIN message, to which the other side sends a FINACK message and waits around a bit to respond to any retransmitted FIN messages before timing out.