Colin Perkins

 

00:00:00.633 In this lecture I want to move

00:00:02.333 on from the discussion of connection establishment,

00:00:04.800 and talk instead about reliability and effective

00:00:07.433 data transfer across the network.

 

00:00:10.000 There are four parts to this.

 

00:00:12.000 In this first part, I’ll talk briefly

00:00:14.066 about packet loss in the Internet,

00:00:15.866 and the trade-off between reliability and timeliness.

 

00:00:19.000 Then, I’ll move on to discuss unreliable

00:00:21.633 data using UDP, and talk about the

00:00:23.833 types of applications that benefit from this.

 

00:00:26.700 In part three, I’ll talk about reliable

00:00:29.000 data transfer with TCP. I’ll discuss the

00:00:31.966 TCP service model, how TCP ensures data

00:00:34.866 is delivered reliably, and some of the

00:00:37.066 limitations of TCP relating to head-of-line blocking.

 

00:00:41.000 Then, in the final part, I’ll conclude

00:00:43.100 by discussing how QUIC transfers data and

00:00:45.433 how this differs from TCP.

 

00:00:49.866 I want to start by discussing packet loss in the Internet.

00:00:52.833 What we mean when we say that the Internet

00:00:55.000 provides a best effort service.

00:00:57.066 The end-to-end argument.

00:00:58.733 And the timeliness vs reliability trade-off inherent

00:01:01.400 in the design of the Internet.

 

00:01:05.833 As we discussed back in lecture 1,

00:01:08.066 the Internet is a best effort packet delivery network.

 

00:01:11.933 This means that it’s unreliable by design.

 

00:01:15.000 IP packets can be lost, delayed,

00:01:17.533 reordered, or corrupted in transit. And this

00:01:20.900 is regarded as a feature, rather than a bug.

 

00:01:23.766 A network that can’t deliver

00:01:25.766 a packet is supposed to discard it.

 

00:01:29.000 There are many reasons why a packet

00:01:31.133 can get lost or discarded. It could

00:01:33.733 be due to a transmission error,

00:01:35.433 where electrical noise of wireless interference corrupts

00:01:37.833 the packet in transit, making the packet unreadable.

 

00:01:41.833 Or it could be because too much

00:01:43.300 traffic is arriving at some intermediate link

00:01:45.500 in the network, so an intermediate router

00:01:48.433 runs out of buffer space. If traffic

00:01:51.033 is arriving at a router from several

00:01:52.666 different incoming links, but all going to

00:01:55.200 the same destination, so it’s arriving faster

00:01:57.700 than it can be delivered, a queue

00:01:59.900 of packets will build up, waiting for transmission.

 

00:02:03.033 If this situation persists, the queue might

00:02:05.400 grow so much that a router runs

00:02:07.633 out of memory, and has no choice

00:02:09.400 but to discard the packets.

 

00:02:12.000 Or packets could be lost because of

00:02:13.966 a link failure. Or a router bug.

00:02:15.833 Or for other reasons.

 

00:02:18.000 How often this happens varies significantly.

 

00:02:22.000 The packet loss rate depends on the type of link.

 

00:02:26.100 Wireless links tend to be less reliable

00:02:28.433 than wired links, for example.

 

00:02:30.966 It’s reasonably likely that packet sent over a wireless

00:02:34.533 link, such as WiFi or 4G,

00:02:36.466 will be corrupted in transit due to

00:02:38.433 noise, interference, or cross traffic.

 

00:02:41.066 This is very unlikely on an Ethernet

00:02:43.633 or optical fibre link.

 

00:02:46.000 The packet loss rate also depends on

00:02:48.933 the overall quality and robustness of the infrastructure.

 

00:02:52.366 Countries with well developed

00:02:53.800 and well maintained infrastructure

00:02:55.400 tend to have reliable Internet links;

00:02:58.366 countries with less robust or lower

00:03:00.500 capacity infrastructure tend to see more problems.

 

00:03:04.833 And the loss rate depends on the protocol.

00:03:07.966 Some protocols intentionally try to push

00:03:10.000 links to capacity, causing temporary overload as

00:03:12.500 they try to find the limit,

00:03:14.633 as they try to find the maximum

00:03:16.666 transmission rate they can achieve.

 

00:03:19.000 TCP and QUIC do this in many cases,

00:03:22.033 depending on the congestion control algorithm

00:03:24.366 used, as we’ll see in lecture 6.

 

00:03:28.000 Other applications, such as telephony or video

00:03:30.200 conferencing, tend to have an upper bound

00:03:32.400 in the amount of data they can send.

 

00:03:35.066 Whatever the reason, though,

00:03:36.933 some packet loss is inevitable.

 

00:03:40.000 The transport layer needs to recognise this.

00:03:42.533 It must detect packet loss. And,

00:03:44.866 if the application needs reliability, it must

00:03:47.133 retransmit or otherwise repair any lost data.

 

00:03:53.000 That the Internet provides best effort packet

00:03:55.266 delivery is a result of the end-to-end argument.

 

00:03:58.966 The end-to-end argument considers whether it’s better

00:04:02.133 to place functionality inside the network or

00:04:04.300 at the end points.

 

00:04:06.833 For example, rather than provide best effort

00:04:09.633 delivery, we could try to make the

00:04:11.766 network deliver packets reliably. We could design

00:04:15.466 some way to detect packet loss on

00:04:17.133 a particular link, and request that the

00:04:19.166 lost packets be retransmitted locally,

00:04:21.466 somewhere within the network.

 

00:04:23.666 And, indeed, some network links do this.

 

00:04:27.000 In WiFi networks, for example, the base

00:04:29.666 station acknowledges packets it receives from the

00:04:31.800 clients, and requests any corrupted packets are

00:04:34.966 re-sent, to correct the error.

 

00:04:38.000 The problem is, that unless this mechanism

00:04:40.333 is 100% perfect all the time,

00:04:43.033 then end systems will still need to

00:04:44.966 check if the data has been received

00:04:46.600 correctly, and will still need some way

00:04:48.600 of retransmitting packets in the case of problems.

 

00:04:52.000 And if they’ve got that, why bother

00:04:54.133 with the in-network retransmission and repair?

 

00:04:58.000 Often times, if you add features into

00:05:00.233 the network routers, they end up duplicating

00:05:03.000 functionality that the network endpoints need to

00:05:05.500 provide anyway.

 

00:05:08.600 Maybe the performance benefit of adding features

00:05:11.833 to the network is so big that it’s worth while.

 

00:05:16.000 But often, the right thing to do

00:05:17.566 is to keep the network simple.

 

00:05:19.733 Omit anything that can be done by the endpoints.

 

00:05:22.633 And favour simplicity over the

00:05:24.533 absolute optimal performance.

 

00:05:28.300 The end-to-end argument is one of the

00:05:29.933 defining principles of the Internet. And I

00:05:32.900 think it’s still a good approach to

00:05:34.566 take, when possible. Keep the network simple, if you can

 

00:05:39.000 The paper linked from the slide talks

00:05:40.866 about this subject in a lot more detail.

 

00:05:46.000 Irrespective of whether retransmission of lost packets

00:05:49.033 happen between the endpoints or within the

00:05:51.766 network, it takes time.

 

00:05:54.566 This leads to a fundamental trade-off in

00:05:56.400 the design of the network.

 

00:05:59.000 If a connection is to be reliable,

00:06:01.266 it cannot guarantee timeliness.

 

00:06:04.400 It’s not possible to build absolutely perfect

00:06:07.066 network links, that never discard or corrupt

00:06:09.433 packets. There’s always some risk that the

00:06:12.566 data is lost and needs to be

00:06:14.833 retransmitted. And retransmitting a packet will always

00:06:18.133 take time, and so disrupt the timeliness of the delivery.

 

00:06:22.400 And similarly, if a connection is to

00:06:24.600 be timely, it cannot guarantee reliability.

 

00:06:27.800 There’s a trade-off to be made.

 

00:06:31.100 Protocols like UDP are timely but don’t

00:06:33.966 attempt to be reliable. They send packets,

00:06:36.800 and if they get lost, they get lost.

 

00:06:40.533 TCP and QUIC, on the other hand,

00:06:42.566 aim to be reliable. They send the

00:06:45.733 packets, and if they get lost,

00:06:47.366 they retransmit them.

 

00:06:49.666 And if the retransmission gets lost? They

00:06:52.200 try again, until the data eventually arrives.

 

00:06:55.533 As we’ll see in part 3 of

00:06:57.533 this lecture, this causes head of line

00:06:59.266 blocking, making the protocol less timely.

 

00:07:03.000 And other protocols, such as the Real-time

00:07:05.466 Transport Protocol, RTP, that I’ll talk about

00:07:09.166 in lecture 7, or the partially reliable

00:07:11.566 version of the Stream Control Transport Protocol,

00:07:13.800 SCTP, aim for a middle ground.

 

00:07:17.466 They try to correct some, but not

00:07:19.100 all, of the transmission errors. The try

00:07:22.000 to achieve a balance, a middle-ground,

00:07:24.233 between timeliness and reliability.

 

00:07:29.266 The different protocols exist because different applications

00:07:32.400 make different trade-offs.

 

00:07:34.233 Some applications prefer timeliness,

00:07:36.533 some prefer reliability.

 

00:07:39.366 For applications like web browsing, email,

00:07:41.833 or messaging, you want to receive all

00:07:44.533 the data. If I’m loading a web

00:07:47.333 site, I’d like it to load quickly,

00:07:49.300 sure. But I prefer for it to

00:07:51.800 load slowly, and be uncorrupted, rather than

00:07:54.433 load quickly with some parts missing.

 

00:07:57.466 For a video conferencing tool, like Zoom,

00:08:00.100 though, the trade-off is different. If I’m

00:08:03.200 having a conversation with someone, it’s more

00:08:05.166 important that the latency is low,

00:08:07.066 than the picture quality is perfect.

 

00:08:10.000 The same may be true for gaming.

 

00:08:13.000 And this has implications for the way

00:08:15.166 we design the network.

 

00:08:17.000 It means that the IP layer needs

00:08:18.933 to be unreliable. It needs to be

00:08:21.066 a best effort network.

 

00:08:23.400 If the IP layer is unreliable,

00:08:25.700 protocols like TCP and QUIC can sit

00:08:28.100 on top and retransmit packets to make

00:08:30.200 it reliable. A transport protocol can make

00:08:33.533 an unreliable network into a reliable one.

 

00:08:37.366 But if the IP layer is reliable,

00:08:39.666 if the IP layer retransmits packets itself,

00:08:42.700 then the network, the applications, the transport

00:08:45.366 protocols, can’t undo that.

 

00:08:51.466 So this concludes the discussion of packet

00:08:53.533 loss and why the Internet opts to

00:08:55.433 provide an unreliable, best-effort, service.

 

00:08:58.566 In the next part, I’ll talk about

00:09:00.233 UDP and how to make use of

00:09:02.100 an unreliable transport protocol.

 

00:00:00.300 In this part, I’ll move on to

00:00:02.166 discuss how to send unreliable data using UDP.

 

00:00:05.400 I’ll talk about the UDP service model,

00:00:07.900 how to send and receive packets,

00:00:09.833 and how to layer protocols on top of UDP.

 

00:00:14.000 UDP provides an unreliable,

00:00:16.300 connectionless, datagram service.

 

00:00:18.600 It adds only two features on top

00:00:20.566 of the IP layer: port numbers and a checksum.

 

00:00:24.000 The checksum is used to detect whether

00:00:26.300 the packet has been corrupted in transit.

 

00:00:28.666 If so, the packet will be discarded

00:00:30.933 by the UDP code in the operating

00:00:33.066 system of the receiver, and won’t be

00:00:34.833 delivered to the application.

 

00:00:37.000 The port numbers determine what application receives

00:00:39.866 the UDP datagrams when they arrive at

00:00:42.066 the destination. They’re set by the bind()

00:00:44.500 call, once the socket has been created.

 

00:00:47.566 The Internet Assigned Numbers Authority, the IANA,

00:00:50.566 maintains a list of well-known UDP port

00:00:52.633 numbers which you should use for particular

00:00:55.200 applications. This is linked from the bottom of the slide.

 

00:00:59.400 UDP is very minimal. It doesn’t provide

00:01:02.166 reliability, or ordering, or congestion control.

 

00:01:05.533 It just delivers packets to an application,

00:01:08.400 that’s bound to a particular port.

 

00:01:11.000 Mostly, UDP is used as a substrate.

 

00:01:13.800 It’s a base on which higher-layer protocols are built.

 

00:01:17.666 QUIC is an example of this,

00:01:19.433 as we discussed in the last lecture.

00:01:21.600 Others are the Real-time Transport Protocol,

00:01:24.100 and the DNS protocol,

00:01:25.466 that we’ll talk about later in the course.

 

00:01:29.666 UDP is connectionless. It’s got no notion

00:01:32.633 of clients or servers, or of establishing

00:01:34.933 a connection before it can be used.

 

00:01:38.000 To use UDP, you first create a socket.

 

00:01:41.433 Then you call bind(),

00:01:42.766 to choose the local port on which that socket

00:01:44.833 listens for incoming datagrams.

 

00:01:46.900 They you call recvfrom() if you want

00:01:49.400 to receive a datagram on that socket,

00:01:51.800 or sendto() if you want to send a datagram.

 

00:01:55.000 You don’t need to connect.

00:01:56.966 You don’t need to accept connections.

00:01:59.266 You just send and receive data.

 

00:02:01.866 And maybe that data is delivered.

 

00:02:05.000 When you’re finished, you close the socket.

 

00:02:08.433 Protocols that run on top of UDP,

00:02:10.700 such as QUIC, might add support for

00:02:13.133 connections, reliability, ordering,

00:02:15.333 congestion control, and so on,

00:02:17.166 but UDP itself supports none of this.

 

00:02:22.866 To send a UDP datagram, you use

00:02:25.000 the sendto() function.

 

00:02:27.033 This work similarly to the send() function

00:02:29.566 you used to send data over a

00:02:31.033 TCP connection in the labs, except that

00:02:33.933 it takes two additional parameters to indicate

00:02:36.566 the address to which the datagram should

00:02:39.066 be sent, and the size of that address.

 

00:02:41.800 When using TCP, you establish a connection

00:02:45.133 between a socket, bound to a local

00:02:46.933 address and port, and a server listening

00:02:49.600 on a particular port on some remote

00:02:51.400 IP address. And once the connection is

00:02:54.033 established, all the data goes over that

00:02:55.966 connection, to the same destination.

 

00:02:59.033 UDP is not like that.

 

00:03:01.533 Every time you call sendto(), you specify

00:03:04.333 the destination address. Every packet you send

00:03:07.633 from a UDP socket can go to

00:03:09.800 a different destination, if you want.

 

00:03:12.166 There’s no notion of connections.

 

00:03:15.400 Now, you can call connect() on a

00:03:17.600 UDP socket, if you like, but it doesn’t actually create

00:03:20.233 a connection. Rather, it just remembers the

00:03:23.666 address you give it, so you can

00:03:25.400 call send(), rather than sendto() in future,

00:03:28.400 to save having to specify the address each time.

 

00:03:33.000 To receive a UDP datagram, you call

00:03:36.133 the recvfrom() function, as shown on the slide.

 

00:03:39.800 This is like the recv() call you

00:03:42.000 use with TCP, but again it has

00:03:44.566 two additional parameters. These allow it to

00:03:47.433 record the address that the received datagram

00:03:49.700 came from, so you can use them

00:03:52.133 in the sendto() function to send a reply.

 

00:03:54.766 You can also call recv(), rather than

00:03:57.000 recvfrom(), like with TCP, and it works,

00:04:00.566 but it doesn’t give you the return

00:04:02.233 address, so it’s not very useful.

 

00:04:05.366 The important point with UDP is that

00:04:07.900 packets can be lost, delayed, or reordered

00:04:10.166 in transit, and UDP doesn’t attempt to

00:04:12.500 recover from this.

 

00:04:14.900 Just because you send a datagram,

00:04:17.000 doesn’t mean it will arrive. And if

00:04:19.500 datagrams do arrive, they won’t necessarily arrive

00:04:21.933 in the order sent.

 

00:04:27.900 Unlike TCP, where data written to a

00:04:30.700 connection in a single send() call might

00:04:32.933 end up being split across multiple read()

00:04:35.066 calls at the receiver, a single UDP

00:04:37.900 send generates exactly one datagram.

 

00:04:41.566 If it’s delivered at all, the data

00:04:43.800 sent by a single call to sendto()

00:04:45.866 will be delivered by a single call

00:04:47.566 to recvfrom(). UDP doesn’t split messages.

 

00:04:52.233 But UDP is otherwise unreliable.

 

00:04:54.966 Datagrams can be lost, delayed, reordered,

00:04:57.766 or duplicated in transit.

 

00:05:00.400 Data sent with sendto() might never arrive.

00:05:03.300 Or it might arrive more than once.

00:05:05.966 Or data sent in consecutive calls to

00:05:08.266 sendto() might arrive out of order,

00:05:10.633 with data sent later arriving first.

 

00:05:14.700 UDP doesn’t attempt to correct any of these things.

 

00:05:19.500 The protocol you build on top of

00:05:21.200 UDP might choose to do so.

 

00:05:23.900 For example, we saw that QUIC adds

00:05:26.000 packet sequence numbers and acknowledgement frames to

00:05:28.433 the data it sends within UDP packets.

 

00:05:31.366 This lets it put the data back

00:05:33.100 into the correct order, and retransmit any

00:05:34.966 missing packets.

 

00:05:36.800 But there’s no requirement that the protocol

00:05:38.566 running over UDP is reliable.

 

00:05:41.500 RTP, the Real-time Transport Protocol, that’s used

00:05:44.933 for video conferencing apps, puts sequence numbers

00:05:47.600 and timestamps inside the UDP datagrams it

00:05:50.666 sends, so it can know if any

00:05:53.033 data is missing, and it can conceal

00:05:55.000 loss or reconstruct the packet playout time,

00:05:58.466 but it generally doesn’t retransmit missing data.

 

00:06:03.000 UDP gives the application the choice of

00:06:05.566 building reliability, if it wants it.

 

00:06:07.866 But it doesn’t require that the applications

00:06:09.966 deliver data reliably.

 

00:06:14.000 Applications that use UDP need to organise

00:06:16.766 the data they send, so it’s useful

00:06:18.400 if some data is lost.

 

00:06:21.133 Different applications do this in different ways,

00:06:23.633 depending on their needs.

 

00:06:26.000 QUIC, for example, organises the data into

00:06:28.533 sub-streams within a connection,

00:06:30.300 and retransmits missing data.

 

00:06:33.266 Video conferencing applications

00:06:34.766 tend to do something different.

 

00:06:37.333 The way video compression works, is that

00:06:39.700 the codec sends occasional full frames of

00:06:41.700 video, known as I-frames, index frames,

00:06:44.700 every few seconds. And in between these

00:06:48.000 it sends only the differences from the

00:06:49.566 previous frame, known as P-frames, predicted frames.

 

00:06:53.866 In a video call, it’s common for

00:06:55.900 the background to stay the same,

00:06:57.433 while the person moves in the foreground,

00:06:59.766 so a lot of the frame is

00:07:01.166 the same each time. By only sending

00:07:03.866 the differences, video compression saves bandwidth.

 

00:07:07.733 But this affects how the application treats

00:07:09.533 the different datagrams.

 

00:07:12.000 If a UDP datagram containing a predicted

00:07:14.500 frame is lost, it’s not that important.

 

00:07:17.433 You’ll get a glitch in one frame of video.

 

00:07:20.500 But if a UDP datagram containing an

00:07:22.700 index frame, or part of an index

00:07:25.300 frame, is lost, then that matters a

00:07:27.533 lot more because the next few seconds

00:07:29.700 worth of video are predicted based on

00:07:31.600 that index frame. Losing an index frame

00:07:34.766 corrupts several seconds worth of video.

 

00:07:38.000 For this reason, many video conferencing apps

00:07:40.166 running over UDP try to determine if

00:07:42.866 missing packets contained an index frame or

00:07:45.233 not. And they try to retransmit index

00:07:48.000 frames, but not predicted frames.

 

00:07:51.000 The details of how they do this

00:07:52.833 aren’t really important, unless you’re building a

00:07:54.966 video conferencing app.

 

00:07:56.766 What’s important though, is that UDP gives

00:07:58.966 the application flexibility to be unreliable for

00:08:02.033 some of the datagrams it sends,

00:08:04.266 while trying to deliver other datagrams reliably.

 

00:08:08.000 You don’t have that flexibility with TCP.

 

00:08:12.333 UDP is harder to use, because it

00:08:14.766 provides very few services to help your

00:08:16.600 application, but it’s more flexible because you

00:08:19.333 can build exactly the services you need

00:08:21.200 on top of UDP.

 

00:08:25.100 Fundamentally, UDP doesn’t make any attempt to

00:08:28.233 provide sequencing, reliability,

00:08:30.500 timing recovery, or congestion control.

 

00:08:33.766 It just delivers datagrams on a best effort basis.

 

00:08:38.000 It lets you build any type of

00:08:39.933 transport protocol you want, running inside UDP packets.

 

00:08:44.000 Maybe that transport protocols has sequence numbers

00:08:46.766 and acknowledgements, and retransmits some or all

00:08:49.533 of the lost packets.

 

00:08:52.100 Maybe, instead, it uses error correcting codes,

00:08:55.066 to allow some of the packets to

00:08:57.233 be repaired without retransmission.

 

00:08:59.666 Maybe it includes timestamps, so the receiver

00:09:02.233 can carefully reconstruct the timing.

 

00:09:04.733 Maybe it contains other information.

 

00:09:07.166 The point is that UDP gives you

00:09:09.133 flexibility, but at the cost of having

00:09:11.500 to implement these features yourself. At the

00:09:14.066 cost of adding complexity.

 

00:09:18.000 There’s a lot to think about when

00:09:19.866 writing a UDP-based protocol or a UDP-

00:09:22.133 based application.

 

00:09:24.033 If you use a transport protocol,

00:09:26.200 like QUIC or like RTP, that runs

00:09:28.633 over UDP, then the designers of that

00:09:31.366 protocol have made these decisions, and will

00:09:33.833 have given you a library you can use.

 

00:09:36.500 If not, if you’re designing your own

00:09:38.566 protocol that runs over UDP, then the

00:09:41.733 IETF has written some guidelines, highlighting the

00:09:44.066 issues you need to think about,

00:09:45.600 in RFC 8085.

 

00:09:48.200 Please read this before you try and

00:09:49.866 write applications that use UDP. There are

00:09:52.666 a lot of non-obvious things that can catch you out.

 

00:09:57.500 So, that concludes our discussion of UDP.

 

00:10:00.233 In the next part, I’ll talk about

00:10:01.866 how TCP delivers data reliably.

 

00:00:00.233 In this part I want to talk

00:00:02.000 about how reliable data is delivered using

00:00:03.966 TCP connections. I’ll talk about the TCP

00:00:06.866 service model, how TCP uses sequence numbers

00:00:10.400 and acknowledgments, and how packet loss detection

00:00:13.500 and recovery works in TCP.

 

00:00:17.033 Thinking about the TCP service model,

00:00:19.266 as we've seen in previous lectures,

00:00:21.600 TCP provides a reliable, ordered, byte stream

00:00:24.966 delivery service that runs over IP.

 

00:00:27.966 The applications write data into the TCP

00:00:30.733 socket, that buffers it up in the

00:00:32.833 sending system, and then delivers it over

00:00:35.533 a sequence of data segments over the IP layer.

 

00:00:38.866 When these data packets, these data segments,

00:00:41.766 are received, they are accumulated in a

00:00:44.533 receive buffer at the receiver. If anything

00:00:47.200 is lost, or arrives out of order,

00:00:49.066 it's re-transmitted, and eventually the data is

00:00:51.433 delivered to the application.

 

00:00:53.333 The data delivered to the application is

00:00:55.666 always delivered reliably, and in the order sent.

 

00:00:58.733 If something is lost, if something needs

00:01:01.600 to be re-transmitted, this stalls the delivery

00:01:04.400 of the later data, to make sure

00:01:06.766 that everything is always delivered in order.

 

00:01:10.966 TCP delivers, as we say, an order,

00:01:13.766 reliable, byte stream.

 

00:01:16.366 After the connection has been established,

00:01:18.466 after the SYN, SYN-ACK, ACK handshake,

00:01:20.866 the client and the server can send

00:01:22.633 and receive data.

 

00:01:24.700 The data can flow in either direction

00:01:27.166 within that TCP connection.

 

00:01:29.400 It’s usual that the data follows a

00:01:31.900 request response pattern. You open the connection.

00:01:35.100 The client sends a request to the

00:01:36.733 server. The server replies with a response.

 

00:01:39.400 The client makes another request. The server

00:01:41.566 replies with another response, and so on.

 

00:01:44.566 But TCP doesn't make any requirements on

00:01:46.900 this. There’s no requirement that the data

00:01:49.266 flows in a request response pattern,

00:01:51.300 and the client and the server can

00:01:53.666 send data in any order they feel like.

 

00:01:56.366 TCP does ensure that the data is

00:01:58.400 delivered reliably, and in the order it

00:02:00.600 was sent, though.

 

00:02:02.766 TCP sends acknowledgments for each data segment

00:02:05.600 as it's received. And if any data

00:02:07.733 is lost, it retransmits that lost data.

 

00:02:10.733 And if segments are delayed and arrive

00:02:13.033 out of order, or if a segment

00:02:15.166 has to be re-transmitted and arrives out

00:02:17.166 of order, then TCP will reconstruct the

00:02:19.300 order before giving the segments back to the application.

 

00:02:25.533 In order to send data over a

00:02:27.300 TCP connection you use the send() function.

 

00:02:30.766 This transmits a block of data over

00:02:33.500 the TCP connection. The parameters are the

00:02:37.133 file descriptor representing the socket – the

00:02:39.500 TCP socket, the data, the length of

00:02:42.066 the data, and a flag. And the

00:02:44.366 flag field is usually zero.

 

00:02:47.466 The send() function blocks until all the

00:02:49.600 data can be written.

 

00:02:51.400 And it might take a significant amount

00:02:53.900 of time to do this, depending on

00:02:55.866 the available capacity of the network.

 

00:02:59.433 It also might not be able to

00:03:00.800 send all the data.

 

00:03:02.833 If the connection is congested, and can't

00:03:05.233 accept any more data, then the send()

00:03:06.966 function will return to indicate that it

00:03:10.566 wasn't able to successfully send all the

00:03:12.766 data that was requested.

 

00:03:15.300 The return value from the send() function

00:03:17.300 is the amount of data it actually

00:03:18.766 managed to send on the connection.

 

00:03:20.266 And that can be less than the

00:03:21.866 amount it was asked to send.

 

00:03:23.566 In which case, you need to figure

00:03:25.533 out what data was not sent,

00:03:27.100 by looking at the return value,

00:03:29.800 and the amount you asked for,

00:03:31.233 and re-send just the missing part in another call.

 

00:03:34.833 Similarly, if an error occurs, if the

00:03:37.333 connection has failed for some reason,

00:03:39.500 the send() function will return -1,

00:03:41.166 and it will set the global variable

00:03:42.566 errno to indicate that.

 

00:03:46.800 On the receiving side you call the

00:03:49.100 recv() function to receive data on a

00:03:50.966 TCP connection.

 

00:03:53.200 The recv() function blocks until data is

00:03:55.833 available, or until the connection is closed.

 

00:03:59.833 It’s passed a size,

00:04:01.333 It’s passed a buffer, buf, and the

00:04:04.666 size of the buffer, BUFLEN, and it

00:04:07.066 reads up to BUFLEN bytes of data.

 

00:04:09.600 And what it returns is the number

00:04:11.700 of bytes of data that were read.

 

00:04:14.066 Or, if the connection was closed,

00:04:16.100 it returns zero. Or, if an error

00:04:18.900 occurs, it returns -1, and again sets

00:04:21.700 global variable errno to indicate what happened.

 

00:04:26.933 When a recv() call finishes, you have

00:04:29.500 to check these three possibilities. You have

00:04:31.900 to check if the return value is

00:04:33.300 zero, to indicate that the connection is

00:04:35.466 closed and you've successfully received all the

00:04:38.133 data in that connection. At which point,

00:04:40.366 you should also close the connection.

 

00:04:42.900 You have to check if the return

00:04:44.300 value is minus one, in which case

00:04:46.166 an error has occurred, and that connection

00:04:48.566 has failed, and you need to somehow

00:04:50.566 handle that error.

 

00:04:53.266 And you need to check if it's some other value,

00:04:55.900 to indicate that you've received some data,

00:04:57.900 and then you need to process that data.

 

00:05:01.133 What's important is to remember that the

00:05:04.200 recv() call just gives you that data

00:05:07.033 in the buffer. If the return value

00:05:09.700 from receive is 157, this indicates that

00:05:12.566 the buffer has 157 bytes of data in it.

 

00:05:16.366 What the recv() called doesn't ever do,

00:05:18.833 is add a terminating null to that buffer.

 

00:05:22.366 Now, if you're careful that doesn't matter,

00:05:26.133 because you know how much data is

00:05:28.300 in the buffer, and you can explicitly

00:05:30.400 process the data up to that length.

 

00:05:33.866 But, a common problem with TCP-based applications,

00:05:38.500 is that they treat the data as if it was a string.

 

00:05:43.366 They pass it to the printf() call

00:05:45.200 using %s as if it were a

00:05:47.200 string, or they pass it to function

00:05:49.666 like strstr() to search for a string

00:05:51.533 within it, or strcpy(), or something like that.

 

00:05:56.133 And the problem is the string functions

00:05:58.033 assume there’s a terminating null, and the

00:06:00.333 recv() call doesn't provide one.

 

00:06:03.766 If you're going to pass the data

00:06:05.866 that's returned from a recv() call to

00:06:08.600 one of the C string functions,

00:06:10.666 you need to explicitly add that null yourself.

 

00:06:13.866 You need to look at the buffer,

00:06:17.333 add the null at the end,

00:06:19.100 after the last byte which was successfully

00:06:21.533 received. If you don't do, this the

00:06:25.033 string functions will just run off the end of the buffer

00:06:27.300 and you'll get a buffer overflow attack.

 

00:06:29.733 And this is a significant security risk.

00:06:31.733 It’s one of the biggest security problems

00:06:33.666 with network code using C. It’s misusing

00:06:36.900 these buffers, accidentally using one of the

00:06:39.166 string functions, and it just reads off

00:06:41.966 the end of buffer, and who knows what it processes.

 

00:06:48.566 When you send data using TCP,

00:06:50.700 the send() call enqueues the data for transmission.

 

00:06:55.200 The operating system, the TCP code in

00:06:57.900 the operating system, splits the data you've

00:07:00.366 written using the various send() calls into

00:07:02.266 what’s known as segments, and puts each

00:07:04.333 of these into a TCP packet.

 

00:07:07.433 The TCP packets are sent in IP

00:07:09.533 packets. And TCP runs a congestion control

00:07:12.933 algorithm to decide when it can send those packets.

 

00:07:17.166 Each TCP segment, each segment is in

00:07:20.200 a TCP packet. The TCP packets have

00:07:22.933 a header, which has a sequence number.

 

00:07:25.933 When the connection setup handshake happens,

00:07:28.700 in the SYN and the SYN-ACK packets,

00:07:31.366 the connection agrees the initial sequence numbers;

00:07:34.300 agrees the starting value for the sequence numbers.

 

00:07:37.666 If you’re the client, for example;

00:07:39.600 the client picks a sequence number at

00:07:43.200 random, and sends this in its SYN packet.

 

00:07:46.433 And then when it starts sending data,

00:07:48.600 the next data packet has a sequence

00:07:50.700 number that is one higher than that

00:07:52.466 in the SYN packet.

 

00:07:55.033 And, as it continues to send data,

00:07:57.700 the sequence numbers increase by the number

00:08:00.300 of data bytes sent.

 

00:08:02.400 So, for example, if the initial sequence

00:08:04.533 number was 1001, just picked randomly,

00:08:07.133 and it sends 30 bytes of data

00:08:09.466 in the packet, then the next sequence

00:08:12.733 number will be 1031.

 

00:08:16.533 The sequence number spaces are separate for

00:08:18.800 each in each direction. The sequence numbers

00:08:21.066 the client uses increase based on the

00:08:23.333 initial sequence number the client sent the SYN packet.

 

00:08:26.366 The sequence numbers the server use,

00:08:28.433 start based on the initial sequence number

00:08:30.600 the server sent in the SYN-ACK packet,

00:08:32.700 and increase based on the amount of

00:08:34.766 data the server is sending. The two

00:08:36.366 number spaces are unrelated.

 

00:08:41.600 What's important is that calls to send()

00:08:44.300 don't map directly onto TCP segments.

 

00:08:49.066 If the data which is given to

00:08:51.300 a send() call is too big to

00:08:52.900 fit into one TCP segment, then the

00:08:56.100 TCP code will split it across several

00:08:58.366 segments; it'll split it across several packets.

 

00:09:02.600 Similarly, if the data you send,

00:09:04.900 that data you give the send() call

00:09:06.666 is quite small, TCP might not send

00:09:09.066 it immediately.

 

00:09:11.066 It might buffer it up, combine it

00:09:13.166 with data sent as part of a

00:09:15.600 later send() call. And combine it,

00:09:18.266 and send it in a single larger

00:09:19.700 segment, a single larger TCP packet.

 

00:09:23.566 This is an idea known as Nagle’s

00:09:27.100 algorithm. It's there to improve efficiency by

00:09:30.200 only sending big packets, because there's a

00:09:32.633 certain amount of overhead for each packet.

 

00:09:35.733 Each packet that’s sent by TCP has

00:09:38.033 a TCP header. It’s got an IP

00:09:40.333 header. It's got the Ethernet or the

00:09:42.666 WiFi headers depending on the link layer.

 

00:09:45.033 And that adds a certain amount of

00:09:47.033 overhead. It’s about, I think, 40 bytes

00:09:48.966 per packet. So if you're only sending

00:09:51.066 a small amount of data, that's a

00:09:52.900 lot of overhead, a lot of wasted data.

 

00:09:55.533 So TCP, with the Nagle algorithm,

00:09:57.466 tries to combine these packets into larger

00:09:59.500 packets when it can. But, of course,

00:10:01.633 this adds some delay. It’s got to

00:10:03.800 wait for you to send more data;

00:10:05.400 wait to see if it can form a bigger packet.

 

00:10:09.133 If you really need low latency,

00:10:11.133 you can disable the Nagle algorithm.

 

00:10:13.100 There’s a socket option called TCP_NODELAY,

00:10:16.000 and we see the code on the

00:10:17.800 slide to show how to use that.

 

00:10:19.833 So you create the socket, you

00:10:23.300 establish the connection, and then you call

00:10:26.400 the TCP_NODELAY option and that turns this

00:10:28.700 off. And this means that every time

00:10:31.000 you send() on the socket, it immediately

00:10:32.900 gets sent as quickly as possible.

 

00:10:37.800 One implication of this behaviour, though,

00:10:40.233 where TCP can either split data written

00:10:43.800 in a single send() across multiple segments,

00:10:47.233 or where it can combine several send()

00:10:49.566 calls into a single segment, is that

00:10:52.400 the data returned by the recv() calls

00:10:54.900 doesn't always correspond to a single send().

 

00:10:58.400 When you call recv(), you might get

00:11:01.166 just part of a message. And you

00:11:03.266 need to call recv() again to get the rest of the message.

 

00:11:06.700 Or you may get several messages in one recv() call.

 

00:11:12.600 When you're using TCP, the recv() calls

00:11:14.933 return the data reliably, and they return

00:11:17.266 the data in the order that it was sent.

 

00:11:20.366 But what they don't do is frame

00:11:22.300 the data. What they don't do is

00:11:23.833 preserve the message boundaries.

 

00:11:27.233 For example, if we're using HTTP,

00:11:30.433 which we see, we see an example

00:11:32.666 of an HTTP message that might be sent,

00:11:34.866 an HTTP response that might be sent,

00:11:37.866 by a web server back to a browser.

 

00:11:41.566 If we're using HTTP, what we would

00:11:44.500 like is that the whole response is

00:11:46.800 received in one go. So if we're

00:11:50.066 implementing a web browser we just call

00:11:51.766 recv() on the TCP connection

00:11:53.633 and we get all of the headers,

00:11:55.866 and all of the body, in just

00:11:57.500 in just one call to recv() and

00:11:59.433 we can then parse it, and process it, and deal with it.

 

00:12:02.833 TCP doesn't guarantee this, though.

 

00:12:06.133 It can split the messages arbitrarily,

00:12:08.566 depending on how much data was in

00:12:11.166 the packets, what size packets the underlying

00:12:14.233 link layers can send, and on the

00:12:17.066 available capacity of the network depending on

00:12:19.566 the congestion control.

 

00:12:21.200 And it can split the packets at arbitrary points.

 

00:12:24.466 For example, if we look at the

00:12:26.800 slide, we see that the headers,

00:12:29.166 some of them are labeled in red,

00:12:30.533 some are in blue, some of the body is in blue,

00:12:33.233 some the rest of the body is

00:12:34.500 in green. And it could be that

00:12:36.400 the TCP connection splits the data up,

00:12:38.600 so that the first recv() call just

00:12:40.633 gets the part of the headers highlighted

00:12:42.466 in red,

 

00:12:43.500 ending halfway through the “ETag:” line.

 

00:12:46.466 And then you have to call recv()

00:12:48.333 again. And then you get the part

00:12:50.233 of the message highlighted in blue,

00:12:51.833 which contains the rest of the headers

00:12:53.600 and the first part of the body.

 

00:12:55.533 Then you have to call recv() again,

00:12:57.433 to get the rest of the message

00:12:59.033 that's highlighted in green on the slide.

 

00:13:01.300 And this makes it much harder to

00:13:03.166 parse; much harder for the programmer.

 

00:13:05.833 Because you have to look at the

00:13:07.866 data you've got, parse it, check to

00:13:09.900 see if you've got the whole message,

00:13:11.500 check if you've received the complete headers,

00:13:13.466 check to see if you've received the

00:13:15.033 complete body. And you have to handle

00:13:17.033 the fact that you might have partial messages.

 

00:13:20.633 And it's something which makes it a

00:13:22.200 little bit hard to debug, because if

00:13:24.466 you only send small messages,

00:13:25.833 if you're sending packets which are only

00:13:28.200 like 1000 bytes, or so, they’re probably

00:13:31.800 small enough to fit in a single

00:13:33.600 packet, and they always get delivered in one go.

 

00:13:36.333 It’s only when you start sending

00:13:38.400 larger packets, or sending lots of data

00:13:41.333 over connection so things get split up

00:13:43.800 due to congestion control, that you start

00:13:45.600 to see this behaviour where the messages

00:13:47.533 get split at arbitrary points.

 

00:13:54.133 So as we've seen, the TCP segments

00:13:58.200 contain sequence numbers, and the sequence numbers

00:14:00.333 count up with the number of bytes being sent.

 

00:14:03.600 Each TCP segment also has an acknowledgement number.

 

00:14:09.366 When a TCP segment is sent,

00:14:12.266 it acknowledges any segments that have previously

00:14:16.666 been received.

 

00:14:18.866 So if,

00:14:20.266 if a TCP endpoint has received some

00:14:24.733 data on a TCP connection,

00:14:27.266 when it sends its next packet,

00:14:29.400 the ACK bit will be set in

00:14:31.866 the TCP header, to indicate that the

00:14:33.866 acknowledgement number is valid, and the acknowledgement

00:14:36.500 number will have a value indicating the

00:14:39.100 next sequence number it is expecting.

 

00:14:42.166 That is, the next contiguous byte it's

00:14:44.533 expecting on the connection.

 

00:14:47.866 So, in the example, we have a

00:14:52.500 slightly unrealistic example in that the connection

00:14:54.733 is sending one byte at a time,

00:14:56.500 and the first packet is sent with sequence number five.

 

00:14:59.566 And then the next packet is sent

00:15:01.700 with sequence number six, and then seven,

00:15:03.833 and eight, and nine, and ten,

00:15:05.666 and so on. And this is what

00:15:07.800 might happen with an ssh connection,

00:15:09.600 where each key you type generates a

00:15:11.166 TCP segment, with just the one key press in it.

 

00:15:14.866 And when those packets are received at

00:15:17.866 host B, it sends a TCP segment

00:15:20.700 with the acknowledgement bit set, acknowledging what's

00:15:24.766 expected next.

 

00:15:26.233 So when it receives the TCP packet

00:15:29.800 with sequence number five, and one byte

00:15:31.833 of data in it, it sends an

00:15:33.900 acknowledgement saying it got it, and it's

00:15:36.133 expecting the packet with sequence number six next.

 

00:15:40.333 When it receives the packet with sequence

00:15:42.366 number six, and one byte of data

00:15:44.433 in it, it sends an acknowledgement saying

00:15:46.333 it's expecting seven. And so on.

 

00:15:51.033 TCP only ever acknowledges the next contiguous

00:15:55.766 sequence number expected.

 

00:15:58.233 And if a packet is lost,

00:16:00.500 subsequent packets generate duplicate acknowledgments.

 

00:16:05.300 So in this case, packet five was

00:16:08.733 sent. It got to the receiver,

00:16:10.766 and that sent the acknowledgement saying it

00:16:12.633 expected six. Six was sent, arrived at

00:16:15.100 the receiver, so the acknowledgement says it

00:16:17.133 expects seven.

 

00:16:18.800 Seven was sent, arrives at the receiver,

00:16:21.600 sends the acknowledgement saying it expects

00:16:23.333 eight. Eight was sent, and gets lost.

 

00:16:29.466 Nine was sent, and arrives at the receiver.

 

00:16:33.033 At this point, the receiver’s received the

00:16:36.066 packets with sequence numbers five, six,

00:16:38.000 and seven; eight is missing; and nine

00:16:40.366 has arrived. So the next contiguous sequence

00:16:43.400 number it's expecting is still eight.

 

00:16:46.233 So it sends an acknowledgement saying “I’m

00:16:48.633 expecting sequence number eight next”.

 

00:16:52.066 The packet sent, the next packet sent,

00:16:55.066 has sequence number 10. This arrives,

00:16:57.633 the acknowledgement goes back saying “I still

00:16:59.800 haven't got eight, I’m still expecting eight”,

00:17:02.400 and this carries on. TCP keeps sending

00:17:04.800 duplicate acknowledgments while there’s a gap in

00:17:06.900 the sequence number space.

 

00:17:11.533 In addition, we don't show it here,

00:17:14.000 but TCP can also send delayed acknowledgments,

00:17:16.333 where it only acknowledges every second packet.

 

00:17:18.466 In this case the acknowledgments might go,

00:17:20.666 six, eight. The packet with sequence number

00:17:23.966 five is sent, and it acknowledges six.

 

00:17:26.566 Packet with number six is sent,

00:17:28.366 and arrives, and packet number seven is

00:17:30.366 sent, and then it sends the acknowledgement

00:17:32.166 saying it's expecting eight. So it doesn't

00:17:34.366 have to send every acknowledgement, it can

00:17:36.300 sent every other acknowledgement to reduce the overheads.

 

00:17:43.300 TCP uses the acknowledgments to detect packet

00:17:47.800 loss; to detect when segments are lost.

 

00:17:51.233 There’s two ways in which it does this.

 

00:17:54.466 The first is that if it sends

00:17:57.433 data, but for some reason the acknowledgments stop entirely.

 

00:18:01.500 This is a sign that either the receiver has failed,

 

00:18:04.966 And, you know, the packets are being

00:18:06.866 delivered to the receiver, but the application

00:18:08.733 has crashed, and there's nothing there to

00:18:11.000 receive the data, to reply.

 

00:18:13.700 Or it's an indication that the network

00:18:15.800 connection has failed, and the packets are

00:18:17.900 just not reaching the receiver.

 

00:18:19.500 So if TCP is sending data,

00:18:21.633 and it's not getting any acknowledgments back,

00:18:24.066 after a while it times out and

00:18:26.933 uses this as an indication that the

00:18:28.866 connection has failed.

 

00:18:32.300 Alternatively, it can be sending data,

00:18:35.666 and if some data is lost,

00:18:39.700 but the later segments arrive, then TCP

00:18:42.000 will start sending the duplicate acknowledgments.

 

00:18:45.166 Again, back to the example, we see

00:18:47.900 that packet eight is lost, packet nine

00:18:50.266 arrives, and the sequence number, the acknowledgement

00:18:53.366 number, comes back says “I’m expecting sequence

00:18:55.266 number eight”.

 

00:18:56.966 And packet ten is sent and it

00:18:59.133 arrives, and it still says “I’m still

00:19:00.666 expecting packet with sequence number eight”,

00:19:03.200 and this just carries on.

 

00:19:05.700 And, eventually, TCP gets what's known as

00:19:08.333 a triple duplicate acknowledgement. It’s got the

00:19:11.833 original acknowledgement saying it's expecting packet eight,

00:19:14.933 and then three duplicates following that,

00:19:17.266 so four packets in total, all saying

00:19:19.433 “I’m still expecting packet eight”.

 

00:19:22.533 And what this indicates, is that data

00:19:24.900 is still arriving, but something's got lost.

 

00:19:28.266 It only generates acknowledgements when a new

00:19:30.800 packet arrives, so if we keep seeing

00:19:33.000 acknowledgments indicating the same thing, this indicates

00:19:35.933 that new packets arriving, because that's what

00:19:38.200 triggers the acknowledgement to be sent,

00:19:40.866 but there's still a packet missing,

00:19:43.400 and it's telling us which one it's expecting.

 

00:19:46.866 At that point TCP assumes that the

00:19:49.400 packet has got lost, and retransmits that

00:19:51.566 segment. It retransmits the packet with sequence

00:19:54.833 number eight.

 

00:19:59.233 Why does it wait for a triple duplicate acknowledgement?

 

00:20:03.466 Why does it not just retransmit it

00:20:06.033 immediately. when it sees a duplicate?

 

00:20:08.566 Well, the example we see here illustrates that.

 

00:20:13.466 In this case, a packet with sequence

00:20:15.733 number five is sent, containing one byte

00:20:17.866 of data, and it arrives, and the

00:20:19.866 receiver acknowledges it, saying it's expecting six.

 

00:20:23.400 And six is sent, and it arrives,

00:20:26.266 and the receiver acknowledges it, indicating it’s

00:20:28.333 expecting seven.

 

00:20:30.066 And packet seven is sent, and it's

00:20:32.866 delayed. And packet eight is sent,

00:20:35.566 and eventually arrives at the receiver.

 

00:20:38.233 Now the receiver hasn't received packet seven

00:20:41.100 yet, so it sends an acknowledgement which

00:20:43.500 says “I’m still expecting seven”. So that's

00:20:46.066 a duplicate acknowledgement.

 

00:20:48.200 At that point packet seven, which was

00:20:50.466 delayed, finally does arrive.

 

00:20:53.866 Now packet seven has arrived, packet eight

00:20:56.466 had arrived previously, so what is now

00:20:58.600 expecting is nine, so it sends an

00:21:00.833 acknowledgement for nine.

 

00:21:02.866 And we see that the acknowledgments go

00:21:05.266 six, seven, seven, nine, because that packet

00:21:08.033 seven was delayed a little bit.

 

00:21:11.900 And if TCP reacts to a single

00:21:14.300 duplicate acknowledgement as an indication that the

00:21:17.166 packet was lost, then you run the

00:21:20.233 risk that you're resending a packet on

00:21:23.033 the assumption when it was lost,

00:21:24.933 when it was just merely delayed a little bit.

 

00:21:28.466 And there's a trade off you can make here.

 

00:21:31.733 Do you treat, a single duplicate as

00:21:35.600 an indication of loss? Do you treat

00:21:38.066 two duplicates as an indication of loss?

00:21:40.366 Three? Four? Five? At what point do

00:21:42.900 you say “this as an indication of

00:21:44.300 loss”, rather than just “this is a

00:21:46.566 slightly delayed packet, and it might recover

00:21:49.133 itself in a minute”?

 

00:21:53.600 The reason that a triple duplicate is

00:21:55.933 used, is because someone did some measurements,

00:21:58.833 and decided that packets being delayed

00:22:01.800 enough to cause one or two duplicates,

00:22:04.500 because they arrived just a little bit

00:22:06.933 out of order, was relatively common.

 

00:22:09.133 But packets being delayed enough that they

00:22:11.800 cause three or more duplicates is rare.

 

00:22:14.500 So it's balancing-off speed of loss detection

00:22:17.766 vs. the likelihood that a merely delayed

00:22:20.466 packet is treated as if it were

00:22:22.600 lost, and retransmitted unnecessarily.

 

00:22:26.300 And, based on the statistics, the belief

00:22:29.500 by the designers of TCP was that

00:22:32.666 waiting for three duplicates was the right threshold.

 

00:22:36.233 And you could make a TCP version

00:22:38.900 that reduced this to two, or even

00:22:41.300 one duplicate, and it would respond to

00:22:43.666 loss faster, but would have the risk

00:22:45.666 that it's more likely to unnecessarily retransmit

00:22:47.966 something that's just delayed.

 

00:22:50.500 Or you could make it four,

00:22:52.433 five, six, even more duplicate acknowledgments,

00:22:55.700 which will be less likely to unnecessarily

00:22:57.900 retransmit data. But it’d be slower,

00:23:00.966 because it would be slower in responding

00:23:03.300 to loss, and slower in retransmitting actually lost packets.

 

00:23:12.766 The other behaviour of TCP. which is

00:23:16.033 worth noting, is head-of-line blocking.

 

00:23:19.566 Now, in this case we're sending something

00:23:21.866 more realistic. We're sending full size packets,

00:23:24.166 with 1500 bytes of data in each packet.

 

00:23:26.900 And 1500 is the maximum packet size

00:23:29.333 that you can send in an Ethernet

00:23:31.733 packet, or in a WiFi packet,

00:23:33.833 so this is a typical size that actually gets sent.

 

00:23:37.366 In this case, the first packet is

00:23:40.366 sent with sequence numbers in the range

00:23:42.966 zero through to 1499.

 

00:23:46.266 And this arrives at the receiver,

00:23:48.266 and the receiver sends an acknowledgement saying

00:23:50.500 it got it, and the next packet

00:23:52.300 it’s expecting has sequence number 1500.

00:23:55.666 So it sends an acknowledgement for 1500.

 

00:23:58.666 And if there’s a recv() call outstanding

00:24:01.033 on that socket, that recv() call will

00:24:03.400 return at that point, and return 1500

00:24:05.100 bytes of data. It returns the data

00:24:07.733 as it was received.

 

00:24:09.600 The next packet arrives at the receiver,

00:24:11.866 containing sequence numbers 1500 through to 2999,

00:24:16.800 and again the recv() call, if there

00:24:19.266 is one, will return, and return that

00:24:21.233 next 1500 bytes.

 

00:24:23.200 Similarly, when the packet containing the next

00:24:25.833 1500 comes in, the receiver will send

00:24:28.433 the ACK saying “I’m expecting 4500”,

00:24:30.533 and the recv() call will return.

 

00:24:33.733 The packet containing sequence numbers 4500 though

00:24:37.500 to 5999 is lost.

 

00:24:40.633 The packet containing 6000 through to 7499 arrives.

 

00:24:47.466 The acknowledgement goes back indicating that it’s

00:24:50.166 still expecting sequence number 4500, because that

00:24:53.166 packet got lost. And at that point,

00:24:56.233 some data has arrived, some new data

00:24:57.966 has arrived at the receiver.

 

00:24:59.600 But there's a gap. The packets,

00:25:02.566 the packet, containing data with sequence numbers

00:25:05.266 4500 through to 5999 is still missing.

 

00:25:08.833 So if the receiver application has called

00:25:12.933 recv() on that socket, it won't return.

 

00:25:16.366 The data has arrived, it's buffered up

00:25:18.833 in the TCP layer in the operating

00:25:20.800 system, but TCP won't give it back

00:25:22.400 to the application.

 

00:25:24.933 And the packets can keep being sent,

00:25:27.200 and the receiver keeps sending the duplicate

00:25:29.700 acknowledgments, and eventually it’s sent the triple

00:25:32.266 duplicate acknowledgement, and the TCP sender notices

00:25:35.700 and retransmits the packet with sequence numbers

00:25:38.366 4500 through to 5999.

 

00:25:41.833 And eventually those arrive at the receiver.

 

00:25:45.900 At that point, the receiver has a

00:25:48.966 contiguous block of data available, with no

00:25:51.133 gaps in it, and it returns all

00:25:54.100 of the data from sequence number 4500

00:25:57.000 up to sequence number 12,000,

00:26:00.533 up to the application in one go.

 

00:26:03.333 And if the application has given a

00:26:05.600 big enough buffer, at that point the

00:26:07.366 recv() call will returned 7500 bytes of

00:26:09.766 data. It’ll return all of that received

00:26:12.666 data in one big burst.

 

00:26:18.033 And then, as the data, you know,

00:26:20.700 gets retransmitted, as the data arrives,

00:26:23.066 it will just keep, you know,

00:26:25.233 the recv() call will unblock and data

00:26:27.066 will start flowing.

 

00:26:29.133 The point is the TCP receiver waits

00:26:31.700 for any missing data to be delivered.

 

00:26:34.366 If anything's missing, the triple duplicate ACK

00:26:37.900 happens, it eventually gets retransmitted, and the

00:26:40.933 receiver won't return anything to the application

00:26:43.533 until that retransmission has happened.

 

00:26:48.200 It’s called head of line blocking.

00:26:50.066 The data stops being delivered, until it

00:26:52.433 can be delivered in sequence to the

00:26:54.466 application. It’s all just buffered up in

00:26:56.633 the operating system, in the TCP code.

 

00:26:58.933 TCP always gives the data to the

00:27:01.100 application in a contiguous ordered sequence,

00:27:03.000 in the order it was sent.

 

00:27:04.933 And this is another reason why the

00:27:06.700 recv() calls don't always preserve the message boundaries.

 

00:27:09.600 Because it depends how much data was

00:27:11.700 queued up because of packet losses,

00:27:13.466 and so on, so that it can

00:27:15.266 always be delivered in order.

 

00:27:19.266 The head of line blocking increases the

00:27:21.900 total download time. We see on the

00:27:24.500 left, the case where one packet was

00:27:27.133 lost, and had to be re-transmitted.

 

00:27:29.500 And we see on the right,

00:27:31.033 the case where all the packets were

00:27:32.866 received on time. And we see an

00:27:34.666 increase in the download time because of

00:27:36.466 the packet loss.

 

00:27:40.733 It blocks the receiving, it delays things

00:27:43.700 a little bit, waiting for the retransmission.

 

00:27:46.533 And it increases the overall download time

00:27:50.500 a little bit.

 

00:27:52.366 It disrupts the behaviour of when the

00:27:54.966 packets are received, during the download quite

00:27:57.333 significantly. We see 1500, 1500, 1500,

00:28:02.400 big gap, seven thousand five hundred,

00:28:04.666 1500, 1500,

 

00:28:07.666 in the case where the packets were

00:28:09.300 lost. Or, in the case where they

00:28:10.733 were all received, the data is coming

00:28:12.533 in quite smoothly. It's regularly spaced.

 

00:28:14.966 So it affects the timing, it effects

00:28:17.133 when the data is delivered to the

00:28:18.733 application, and it has a smaller effect

00:28:20.300 on the overall download times.

 

00:28:28.633 And if you're building real time applications,

00:28:32.000 this is a significant problem. We see

00:28:34.833 the case on the right, if everything

00:28:36.866 is delivered on time, then the data

00:28:39.566 is released to the application very quickly

00:28:41.800 and very predictably.

 

00:28:43.566 And you don't need

00:28:47.333 much buffering delay at the receiver.

00:28:49.600 Things can be just delivered, things are

00:28:51.600 just delivered to the application, repeatedly on

00:28:53.600 a regular schedule.

 

00:28:55.033 But the minute something gets lost,

00:28:57.233 it has to wait for the retransmission.

 

00:28:59.333 In this case it waits for one

00:29:00.966 round trip time, because the ACK has

00:29:02.866 to get back, and then the data has to be retransmitted.

 

00:29:05.200 Plus, it has to wait for four

00:29:07.100 times the gap between packets, to allow

00:29:09.500 for the four duplicates, the triple duplicate

00:29:12.066 ACK and the original ACK, so you

00:29:14.366 get one round trip time plus four

00:29:16.500 times the packet spacing.

 

00:29:18.066 So if you're using TCP to send,

00:29:20.266 for example, speech data, where it's sending

00:29:22.400 packets regularly every 20 milliseconds, you need

00:29:25.133 to buffer 80 milliseconds plus the round

00:29:27.666 trip time, to allow for these re-transmissions,

00:29:30.766 if you're using it for a real time application.

 

00:29:33.766 Because, it waits for the retransmissions, and because

00:29:38.433 of the head of line blocking.

 

00:29:41.133 And when you're using applications like Netflix

00:29:44.933 or the iPlayer, when you press play on the video

00:29:47.433 there’s a little pause where it says “buffering”.

 

00:29:49.700 This is what it's doing. It’s buffering

00:29:51.766 up enough data that it can wait

00:29:54.933 for the retransmissions to happen,

00:29:57.666 buffering up enough data in the TCP

00:29:59.866 connection that it can keep playing out

00:30:01.633 the video frames, in order, while still

00:30:04.633 allowing time for a retransmission to happen.

 

00:30:07.100 So it's buffering up the data waiting,

00:30:09.533 making sure there's enough data buffered up,

00:30:12.766 because of this head of line blocking

00:30:14.366 issue in TCP.

 

00:30:20.300 So that concludes the discussion of TCP.

 

00:30:23.700 It gives you an ordered, reliable, byte stream.

 

00:30:28.233 As a service model it's easy to

00:30:30.433 understand. It’s like reading from a file;

00:30:33.133 you read from the connection and the

00:30:35.733 bytes arrive reliably and in the order they were sent.

 

00:30:39.733 The timing, though, is unpredictable. How much

00:30:43.566 you get from the connection each time you read from it,

00:30:46.433 and whether the data arrives regularly,

00:30:48.800 or whether it's arrives in big bursts

00:30:50.700 with large gaps between them, depends on

00:30:53.100 how much data is lost, and depends

00:30:55.233 on whether the TCP has to retransmit missing data.

 

00:30:59.066 And if you're just using this to

00:31:00.633 download files that doesn't matter. It means

00:31:03.700 that the progress bar is perhaps inaccurate,

00:31:05.866 but otherwise it doesn't make much difference.

 

00:31:08.466 But, if you're using it for real

00:31:10.066 time applications, like video streaming, like telephony,

00:31:14.066 this head of line blocking can quite

00:31:15.866 significantly affect the play out.

 

00:31:18.966 And a lot of that is the

00:31:20.500 reason why applications use, why real time

00:31:23.366 applications use, UDP. And for those that

00:31:26.233 don't use UDP,

00:31:27.700 applications like Netflix that use adaptive streaming

00:31:32.633 over HTTP, which we'll talk about in

00:31:35.166 lecture seven, that's why there’s this buffering

00:31:37.466 delay before they start playing.

 

00:31:40.966 And, of course, the lack of framing

00:31:42.700 complicates the application design, you have to

00:31:44.900 parse the data to make sure you've got all the data;

00:31:47.166 there's no message boundaries in there,

00:31:50.033 so you have to parse the data.

00:31:51.966 It doesn't tell you, the connection doesn't

00:31:53.700 tell you, when you've received all the data.

 

00:31:57.433 So that's it for TCP.

 

00:32:00.433 It delivers data reliably. It uses sequence

00:32:03.533 numbers and acknowledgments to indicate when the

00:32:06.133 data arrived.

 

00:32:07.633 It uses timeouts to indicate that a

00:32:09.733 connection has failed. And it uses this

00:32:12.433 idea of triple duplicate ACKs to indicate

00:32:14.866 that a packet has been lost,

00:32:16.300 and trigger a retransmission of any lost data.

 

00:32:19.833 What I’ll talk about in the next

00:32:21.333 part is QUIC and how it differs

00:32:23.266 from the way TCP handles reliability.

 

00:00:00.100 In this final part I’d like to

00:00:02.533 talk about how reliable data transfer works

00:00:04.633 with QUIC, and how it's different to

00:00:07.100 reliable data transfer with TCP.

 

00:00:09.533 I’ll talk a little bit about the

00:00:11.733 QUIC service model, and how it handles

00:00:13.966 packet numbers and retransmission. I’ll talk about

00:00:16.166 the multi-streaming features of QUIC. And I’ll

00:00:19.133 talk about how it avoids head-of-line blocking.

 

00:00:23.333 The service model for TCP, as we

00:00:26.533 saw previously, is that it delivers a

00:00:29.100 single reliable, ordered, byte stream of data.

 

00:00:32.700 Applications write a stream of bytes in,

00:00:34.933 and that stream of bytes is delivered

00:00:37.033 to the receiver, eventually.

 

00:00:39.166 QUIC, by contrast, delivers several ordered reliable

00:00:42.200 byte streams within a single connection.

 

00:00:45.166 Applications can separate the data they're sending

00:00:47.933 into different streams, and each stream is

00:00:49.966 delivered reliably and in order.

 

00:00:52.066 QUIC doesn't preserve the ordering between the

00:00:54.666 streams within a connection, so if you

00:00:57.266 send in one stream, and then send

00:00:59.866 in a second stream, then the data

00:01:02.500 you sent second, in that second stream,

00:01:04.700 may arrive first, but it preserves the

00:01:06.666 ordering with a stream.

 

00:01:09.300 And you can treat each stream as

00:01:11.833 if it were running multiple TCP connections

00:01:15.366 in parallel, so it gives you the

00:01:17.100 same service model with several streams of

00:01:19.433 data, or you could perhaps treat each stream as a

00:01:22.900 sequence of messages to be sent,

00:01:25.600 with the streams indicating message boundaries.

 

00:01:30.366 QUIC delivers data in packets.

 

00:01:33.466 Each QUIC packet has a packet sequence

00:01:36.366 number, a packet number,

00:01:38.266 and the packet numbers

00:01:41.333 are split into two packet number spaces.

 

00:01:44.666 The packets sent during the initial QUIC

00:01:48.033 handshake start with packet sequence number zero,

00:01:50.900 and that packet sequence number increases by

00:01:53.033 one for each packet sent during the handshake.

 

00:01:56.066 Then, when the handshake’s complete, and it

00:01:58.800 switches to sending data, it resets the

00:02:01.666 packet sequence number to zero and starts again.

 

00:02:05.166 Within each of these packet number spaces,

00:02:07.666 the handshake space, and the data space,

00:02:10.833 the packet number sequence starts at zero,

00:02:13.400 and goes up by one for every packet sent.

 

00:02:16.566 That is, the sequence numbers in QUIC,

00:02:18.733 the packet numbers in QUIC, count the

00:02:20.966 number of packets of data being sent.

 

00:02:23.233 That's different to TCP. In TCP,

00:02:25.400 the sequence number in the header counts

00:02:27.966 the offset within the byte stream,

00:02:30.400 it counts how many bytes of data

00:02:32.166 have been sent. Whereas in QUIC,

00:02:34.300 the packet numbers count the number of packets.

 

00:02:38.033 Inside a QUIC packet is a sequence

00:02:40.833 of frames. Some of those frames may

00:02:43.100 be stream frames, and stream frames carry data.

 

00:02:46.600 Each stream frame has a stream ID,

00:02:50.066 so it knows which of the many sub-streams

00:02:52.200 it’s carrying data for, and it

00:02:53.766 also has the amount of data being carried,

00:02:57.033 and the offset of that data from the start of the stream.

 

00:02:59.866 So, essentially the stream contains sequence numbers

00:03:03.833 which play the same role as TCP

00:03:05.400 sequence numbers, in that they count bytes

00:03:07.366 of data being sent in that stream.

 

00:03:09.500 And the packets have sequence numbers that

00:03:11.766 count the number of packets being sent.

 

00:03:14.533 And we can see this in the

00:03:16.533 diagram on the right, where we see

00:03:18.366 the packet numbers going up, zero,

00:03:20.466 one, two, three, four. And the stream

00:03:22.433 numbers, packet zero carries data from the

00:03:24.566 first stream, bytes zero through 1000.

 

00:03:27.733 Packet one carries data from the first

00:03:29.733 stream, bytes 1001 to 2000. And packet

00:03:32.700 two carries bytes 2001 to 2500

00:03:36.833 from the first stream, and zero to

00:03:38.866 500 from the second stream, and so on.

 

00:03:41.566 And we see that we can send

00:03:44.333 data on multiple streams in a single packet.

 

00:03:50.400 QUIC doesn't preserve message boundaries within the

00:03:53.200 streams. In the same way that,

00:03:56.000 within a TCP stream, if you write

00:03:59.300 data to the stream and the amount you write is too big

00:04:02.300 to fit into a packet, it may

00:04:04.666 be arbitrarily split between packets.

 

00:04:06.900 Or if the data you send in a TCP Stream is too small,

00:04:09.566 and doesn't fill a whole packet,

00:04:11.500 it may be delayed waiting for more

00:04:13.433 data, to be able to fill up

00:04:15.033 the packet before it’s sent.

 

00:04:16.666 The same thing happens with QUIC.

 

00:04:18.633 If the amount of data you write to a stream is too big to

00:04:21.500 fit into a QUIC packet, then it

00:04:23.366 will be split across multiple packets.

 

00:04:26.166 Similarly, if the amount of data you

00:04:27.866 write to a stream is very small,

00:04:29.633 QUIC may buffer it up, delay it,

00:04:31.766 wait for more data, so it can

00:04:33.366 send it and fill a complete packet.

 

00:04:36.666 In addition, QUIC can take data from

00:04:39.466 more than one stream, and send it

00:04:41.300 in a single packet, if there’s space to do so.

 

00:04:44.566 And if there's more than one stream

00:04:46.833 with data that's available to send,

00:04:48.766 then the QUIC sender can make an

00:04:51.033 arbitrary decision, how it prioritises that data,

00:04:53.300 and how it delivers frames from each stream.

 

00:04:56.033 And usually it will split those,

00:04:59.200 the data from the streams, so each

00:05:01.700 packet has data from, half the data from, one stream,

00:05:05.200 and half from another stream. But it

00:05:07.400 may alternate them if it wants,

00:05:08.833 sending one packet with data from stream

00:05:10.966 1, one from stream 2, one from

00:05:12.600 stream 1, one from stream 2, and so on.

 

00:05:17.966 On the receiving side, the receiver sends,

00:05:20.566 the QUIC receiver sends acknowledgments for the

00:05:22.766 packets it receives.

 

00:05:24.166 So, unlike TCP which acknowledges the next

00:05:27.000 expected sequence number, a QUIC receiver just

00:05:29.566 sends an acknowledgement to say “I got this packet”.

 

00:05:33.500 So when packet zero arrives, it sends

00:05:35.866 an acknowledgement saying “I got packet zero”.

00:05:38.066 And when packet one arrives, it sends

00:05:39.900 an acknowledgement saying “I got packet one”, and so on.

 

00:05:43.566 The sender needs to remember what data

00:05:46.200 it puts in each packet, so it

00:05:47.800 knows when it gets an acknowledgement for packet two that,

00:05:51.033 in this case, it contained bytes 2001

00:05:54.800 to 2500 from stream one, and bytes

00:05:57.700 zero through 500 from stream two.

 

00:06:00.233 That information isn't in the acknowledgments.

00:06:02.766 What's in the acknowledgments it's just the

00:06:04.500 packet numbers, so the sender needs to

00:06:06.466 keep track of how it puts the

00:06:08.466 data from the streams into the packets.

 

00:06:12.366 The acknowledgments in QUIC are also a

00:06:15.133 bit more sophisticated than they are in

00:06:17.900 TCP, in that it doesn't just have

00:06:20.666 an acknowledgement number field in the header.

 

00:06:23.533 Rather, it sends the acknowledgments as frames

00:06:26.566 in the packets coming back.

 

00:06:28.833 And this gives a lot more flexibility, because

00:06:32.533 it can have a fairly sophisticated frame

00:06:35.700 format, and it can change the frame

00:06:37.400 format to include different, to support different

00:06:41.266 ways of sending a header, if it needs to.

 

00:06:45.233 In the initial version of QUIC,

00:06:47.133 what's in the frame format, in the

00:06:49.666 ACK frames coming back from the receiver to the sender,

00:06:53.266 is a field indicating the largest acknowledgement,

00:06:56.633 which is essentially the same as the

00:06:59.433 TCP acknowledgment – it tells you what's

00:07:02.866 the highest sequence number received.

 

00:07:06.166 There's an ACK delay field, that tells

00:07:08.933 you how long between receiving that packet

00:07:11.633 the receiver waited before sending the acknowledgement.

 

00:07:15.000 So this is the delay in the

00:07:16.866 receiver. And by measuring the time it

00:07:20.100 takes for the acknowledgment come back,

00:07:22.100 and removing this ACK delay field,

00:07:24.966 you can estimate the network round trip

00:07:27.366 time excluding the processing delays in the receiver.

 

00:07:31.466 There’s a list of ACK ranges.

 

00:07:35.300 And the ACK ranges are a way

00:07:37.100 of the receiver saying “I got a range of packets”.

 

00:07:40.366 So you can send an acknowledgement that

00:07:42.233 says, I got packets from five through seven

00:07:44.266 in a single go. And you can

00:07:46.800 split this up, with multiple ACK ranges.

00:07:48.833 So you could have an acknowledgement that

00:07:50.766 says “I got packet five; I got packets

00:07:53.466 seven through nine; and I got packets

00:07:55.433 11 through 15” and you can send

00:07:57.533 that all within a single acknowledgement block,

00:07:59.566 in an ACK frame, within the reverse path stream.

 

00:08:03.433 And this gives it more flexibility,

00:08:05.433 so it doesn't just have to acknowledge

00:08:07.833 the most recently received packet, which gives

00:08:11.200 the sender more information to make retransmissions.

 

00:08:14.466 This is a bit like the TCP

00:08:16.666 selective acknowledgement extension.

 

00:08:21.766 Like TCP, QUIC will retransmit lost data.

 

00:08:26.000 The difference is that TCP retransmits packets,

00:08:30.700 exactly as they would be originally sent,

00:08:33.400 so the retransmission looks just the same

00:08:35.466 as the original packet.

 

00:08:37.633 QUIC never retransmits packets.

00:08:40.500 Each packet in QUIC has a unique packet sequence number,

00:08:45.166 and each packet is only ever transmitted once.

 

00:08:48.366 What QUIC rather does, is it retransmits

00:08:51.000 the data which was in those packets

00:08:53.233 in a new packet.

 

00:08:55.533 So in this example, we see that

00:08:57.600 packet, on the slide, we see that

00:08:59.900 packet number two got lost, and it

00:09:01.633 contain the data bytes 2001 to 2500

00:09:06.033 from stream one, and bytes zero through 500 from stream two.

 

00:09:10.333 And, when it gets the acknowledgments indicating

00:09:12.933 that packet was lost, it resends that data.

 

00:09:16.233 And in this case it's sending in

00:09:18.733 packet six, it’s resending the first bytes

00:09:21.766 of data from stream, it’s sending the

00:09:25.333 bytes 2001 to 2500 from stream one,

00:09:28.533 and it will eventually, at some point

00:09:30.533 later, retransmit the data from stream two.

 

00:09:36.700 As we say, each packet has a

00:09:38.466 unique packet sequence number. Since we're not,

00:09:41.700 since each packet is acknowledged as it

00:09:43.666 arrives, and it's not acknowledging the highest,

00:09:46.666 not acknowledging the next sequence number expected

00:09:49.400 in the same way TCP does,

00:09:51.833 you can’t do the triple duplicate ACK

00:09:53.700 in the same way, because you don't

00:09:55.933 get duplicate ACKs. Each ACK acknowledges the

00:09:58.266 next new packet.

 

00:09:59.666 Rather QUIC declares a packet to be

00:10:02.333 lost when it's got ACKS for three

00:10:05.033 packets with higher packet numbers than the

00:10:07.500 one which it sent.

 

00:10:09.333 At that point, it can retransmit the

00:10:11.333 data that was in that packet.

 

00:10:13.366 And that’s QUIC’s equivalent to the triple

00:10:15.633 duplicate ACK; it's three following sequence numbers

00:10:18.600 rather than three duplicate sequence numbers.

 

00:10:20.766 And also, just like TCP, if there's

00:10:22.666 a timeout, and it stops getting ACKs,

00:10:24.533 then it declares the packets to be lost.

 

00:10:31.366 QUIC delivers multiple streams within a single

00:10:35.500 connection. And within each stream, the data

00:10:39.433 is delivered reliably, and in the order it was sent.

 

00:10:43.466 If a packet’s lost, then that clearly

00:10:46.100 causes data for the stream, streams,

00:10:48.533 where the data was included in that packet to be lost.

 

00:10:52.600 Whether a packet loss effects one,

00:10:55.600 or more, streams really depends on how

00:10:57.400 the sender chooses to put the data

00:10:59.266 from different streams into the packets.

 

00:11:02.300 It’s possible that a QUIC packet can

00:11:04.700 contain data from several streams. We saw

00:11:08.333 in the examples, how the packets contain

00:11:10.700 data from both stream one and stream two simultaneously.

 

00:11:13.566 In that case, if a packet is

00:11:15.833 lost, it will affect both of the

00:11:18.500 streams, all of the streams if there’s

00:11:20.333 data from more than two streams in the packet.

 

00:11:23.333 Equally, a QUIC sender can choose to

00:11:27.133 alternate, and send one packet with data

00:11:29.933 from stream one, and then another packet

00:11:32.066 with data from stream two, and only

00:11:34.266 ever put data from a single stream in each packet.

 

00:11:37.400 The specification puts no requirements on how

00:11:40.433 the sender does this, and different senders

00:11:42.766 can choose to do it differently depending

00:11:47.233 whether they're trying to make progress on

00:11:50.000 each stream simultaneously, or whether they want to

 

00:11:54.000 they want to alternate, and make sure

00:11:57.200 that packet loss only ever affects a single stream.

 

00:12:01.266 Depending on how they do this,

00:12:03.300 the streams can suffer from head of

00:12:05.366 line blocking independently.

 

00:12:07.500 If data is lost on a particular

00:12:09.800 stream, then that stream can't deliver later

00:12:14.866 data to the application, until that

00:12:18.033 lost data has been transmitted. But the

00:12:21.500 other streams, if they've got all the

00:12:23.533 data, can keep delivering to the application.

 

00:12:26.100 So streams suffer from head of line

00:12:28.300 blocking individually, but there's no head of

00:12:30.133 line blocking between streams.

 

00:12:32.600 This means that the data is delivered

00:12:35.466 reliably, and in order, on a stream,

00:12:37.866 but order’s not preserved between streams.

 

00:12:42.266 It’s quite possible that one stream can

00:12:45.033 be blocked, waiting for a retransmission of

00:12:47.000 some of the data in the packets,

00:12:48.800 while the other streams are continuing to

00:12:50.900 deliver data and haven't seen any loss

00:12:52.833 on that stream.

 

00:12:54.700 Each stream is sent and received independently.

 

00:12:57.866 And this means if you're careful with how you split data

00:13:00.800 across streams, and if the implementation is

00:13:04.300 careful with how it puts data from

00:13:05.900 streams into different packets, it can limit

00:13:08.233 the duration of the head of line

00:13:09.600 blocking, and make the streams independent in

00:13:11.766 terms of head of line blocking and data delivery.

 

00:13:18.566 QUIC delivers, as we've seen, several ordered,

00:13:21.900 reliable, byte streams of data in a single connection.

 

00:13:27.333 How you treat these different bytes streams,

00:13:30.000 is, I think, still a matter of interpretation.

 

00:13:33.600 It's possible to treat a QUIC connection

00:13:36.266 as though it was several parallel TCP connections.

 

00:13:40.333 So, rather than opening multiple TCP connections

00:13:42.700 to a server, you open one QUIC

00:13:45.100 connection, and you send and receive several

00:13:47.500 streams of data within that.

 

00:13:49.300 And then you treat each stream of

00:13:51.266 data as-if it were a TCP stream,

00:13:54.466 and you parse and process the data

00:13:56.800 as if it were a TCP stream.

00:13:58.500 And you possibly send multiple requests,

00:14:00.366 and get multiple responses, over each stream.

 

00:14:04.066 Or, you can treat the streams more as a framing device.

 

00:14:07.766 You can say that each stream,

00:14:10.300 you can choose to interpret each stream,

00:14:12.433 as sending a single object. And then,

00:14:15.466 when you send data from the stream,

00:14:17.000 on that stream, once you finish sending

00:14:18.833 that object, you close the stream and

00:14:20.933 move on to use the next one.

 

00:14:23.266 And, on the receiving side, you just

00:14:25.366 read all the data until you see

00:14:27.500 the end of stream marker, and then

00:14:30.200 you process it knowing you’ve got a complete object.

 

00:14:34.066 And I think that the best practices,

00:14:36.666 the way of thinking about a QUIC connection,

00:14:39.966 and the streams within a connection, is still evolving.

 

00:14:42.500 And it's not clear which of these

00:14:44.133 two approaches is the necessarily the right

00:14:46.433 way to do it. And I think

00:14:48.033 it probably depends on the application what

00:14:49.766 makes the most sense.

 

00:14:53.966 So, to conclude for this lecture.

 

00:14:57.366 We spoke a little bit about best

00:14:59.566 effort packet delivery on the Internet,

00:15:01.300 and why the IP layer delivers data

00:15:04.933 unreliably, and why it's appropriate to have

00:15:09.200 a best effort network.

 

00:15:11.200 Then we spoke a bit about the different transports.

 

00:15:14.266 The UDP transport that provides an unreliable,

00:15:17.500 but timely, service on which you can

00:15:20.433 build more sophisticated user space application protocols.

 

00:15:25.166 We spoke about TCP, that provides a

00:15:27.966 reliable ordered stream delivery service. And we

00:15:30.800 spoke about QUIC, that provides a reliable

00:15:33.600 ordered delivery service with multiple streams of

00:15:36.400 data. And it’s clear there’s different services,

00:15:38.800 different transport protocols, for different needs.

 

00:15:41.733 What I want to move on to

00:15:43.566 next time, is starting to talk about

00:15:45.300 congestion control and how all these different

00:15:49.166 transport protocols manage the rate at which they send data.