 We've defined what we mean by a packet and we've seen it's made up of a header, payload and trailer and we've looked at an example IP datagram, an IP packet. Now let's look at one issue that impacts on the performance of protocols and that is how big a packet should be, the packet size. Standards which describe protocols define the size of the headers and trailers. So the size, the fields, the field meanings are usually defined in the standard. In most cases there's some default header size and the header cannot be made any smaller. That is the information defined by the standard must be included in every packet. In some cases there may be some optional extra fields that can be included in the header or trailer depending upon which features of the protocol are being used. There's usually a fixed header, a set header size, a default header size but it can be also larger than the default in some cases. The purpose of the communication protocols are typically to transfer some user data from A to B, the payload. The headers and trailers from the user's perspective are considered overhead. They're not actual data we're sending but we need to send them to make sure the protocol worked correctly. So when we look at performance of protocols we usually want to minimize the overhead. So how big should a packet be, how much payload should it contain? It depends on many different factors and different factors cause a trade-off between different performance criteria of how long it takes to transfer the data, how long it takes to process and other issues as we'll see shortly. Normally a standard has considered those trade-offs, the people who designed the standard in the protocol and they will define a maximum packet or payload size. So a standard will define the header size, the trailer size if included and also the maximum size of the payload in that packet. For example an Ethernet frame typically has a 14 byte header, a 4 byte trailer and the payload can be up to 1500 bytes. But it is a maximum meaning the payload can be less. We can have 1000 bytes, 500 bytes for example. So if we have a fixed header or trailer for a particular protocol and the maximum payload size is defined then what payload size should we use? Should it be the maximum or less? What's the optimal size of that payload and the packet? Well in brief the larger the payload the less the overhead of the header in the trailer. So that's an advantage, use a large payload. But there's some advantages of using small payloads as well and we'll go through and show these for trade-offs that using a small payload in the case that we need to retransmit data we'll minimize overhead due to retransmissions. We can make more efficient use of buffers with a smaller payload and we can potentially offer some fairness amongst users when we have a shared medium using a small payload. So let's look at those four with some more examples. First the packet overhead due to the header or trailers. Let's consider an example where we have 2000 bytes of data from the user to be sent from A to B. And let's say the packet contains a 20 byte header, that's fixed. Assume there's no trailer. And let's consider two different payload sizes. The first one, let's say we have a payload size of 1000 bytes. So that means with our 2000 bytes of user data we'll need two packets. Each packet contains 1000 bytes of data, a payload plus 20 bytes of header. So in total to transmit all of the user data we actually need to transmit those 2000 bytes plus 40 bytes of overhead of header. And that's the top diagram here. We see the blue rectangles represent the header where the white rectangles are the payload of each packet. So we have two packets. If we had a smaller payload, say 200 bytes, then we'd need 10 different packets to make up the 2000 bytes of user data. And with 10 packets each containing 20 bytes of header we'd have a total of 20 bytes of header. 20 bytes and therefore 20 bytes, sorry, 200 bytes of header and 200 bytes of overhead. So we see that in the bottom diagram with the 10 packets each containing the header and under the same conditions therefore with a larger payload we have a smaller overhead. We spend less time transmitting to get the same data to deliver to the destination. So in general having a larger payload or a larger packet with a fixed size header we get less overhead of the headers and trailers that is a smaller transmission time. That's the benefit of a large payload. Let's consider another issue. Let's assume in our link when we send a packet or send a sequence of bits that there's one bit that is in error. So when we send our data the receiver receives the bits, all of them but one are correct where that one for example if it was sent as a bit one is received and interpreted as a bit zero. And let's say that that error occurs at a random bit in those bits that we transmit. And we'll consider the same payload size as before 1000 bytes in one case and 200 bytes in another. And let's just consider a single 1000 bytes to be sent. Using the larger payload of 1000 bytes as the top diagram shows we transmit the frame 20 bytes of header 1000 bytes of payload but one of those bits is in error shown as the red vertical line there. The receiver detects the error and let's assume that cannot fix that error and therefore that one packet must be retransmitted. So the entire 1000 byte packet would be retransmitted plus the extra 20 bytes of header. And that's shown as the red rectangle here, the retransmitted packet number one. So in total to deliver that 1000 bytes of user data we'd need to send actually 2040 bytes because we send two packets, the original and the retransmitted packet. Now what if we were using a smaller packet size, a smaller payload size of 200 bytes? We transmit five packets each containing 20 bytes of header. One bit is in error and in this example it turns out it's in the third packet. So the receiver detects the bit error and detects that packet three would need to be retransmitted and informs the sender which retransmits packet three only. There's no need to retransmit packets one, two, four and five because there are no errors in them. Of course this assumes we have an appropriate retransmission scheme. So in total to deliver that 1000 bytes of user data we've actually sent six packets, five original packets and one retransmitted packet. Each packet contains 200 bytes of payload and 20 bytes of header. So in total we transmit 1320 bytes. It takes less time to transmit the same amount of data as if using the larger payload size. So in the same circumstances using a smaller packet, a smaller payload is better in that if we have errors there's less to retransmit. So that's one trade-off and one issue or an advantage of using a smaller payload. Another issue, before we send packets and as we receive packets we normally store them in memory in a buffer. So let's assume the receiver as they receive packets stores the data in a buffer as it's being processed. And let's say the buffer is 1800 bytes in length. So how much of that buffer do we use when we receive packets? If we have a 1000 byte payload then we can only fit one full packet in the buffer. There's 780 bytes of buffer space wasted. We cannot split the packet and cannot store just a portion of the packet. We must store the entire packet while it's being processed. But if we used a smaller payload of 200 bytes, each packet 200 bytes of payload plus 20 bytes of header, we could fit 8 packets in the buffer at one time. And there would be 40 bytes of buffer space wasted that we couldn't make use of. So this is a case where again using a smaller payload gives us a benefit compared to a large payload. Because that buffer is memory allocated for this protocol. We don't want to be inefficient in using that memory. We want to make a full use of that memory, that buffer space. In general using a smaller packet or a smaller payload, we get less waste of that buffer space. So an advantage of using a smaller packet. One more issue. Let's assume we have 3 users using a shared medium. Which means that they need to take turn in transmitting packets. Only one user transmits at a time. So we have 3 users A, B and C. And they take in turns and that A transmits first and then B then C then A, B, C and so on. And let's assume in this scenario that 2 users, A and B, are going to transmit large packets with a large payload. Whereas the third user, C, will only transmit a small payload. Because maybe their application only has a small amount of data ready to send when they're allowed to. So we get what we see in this diagram of that with a large payload or a large packet, A spends a lot of time transmitting. Then B spends a lot of time transmitting. And then C with a small payload spends a small amount of time transmitting. And then A, B and C again. When we have 3 users sharing a medium, we'd like to have a fair system. With 3 users, we could say fair would be if each user gets to transmit a third of the time, 33% of the time. And if we take in turns, then it would be fair if each user waits the same amount of time as each other user. But we see in this case this example that's not fair. Because what's happening is that those 2 users, A and B with a large payload size, say 1,000 bytes, out of the total time for those 3 users to transmit, they spend, each user spends 1,020 time units out of a total of 2,260 time units transmitting. Where does 2260 come from? It's simply the sum of 1,020 for user A to transmit, 1,000 for the payload, 20 for the header, 1,020 for user B to transmit. Both have large packets. And then another 220 for user C to transmit. User C has a smaller payload. So as a fraction of time spent transmitting, A and B spend about 45% of the time each, 90% in total amongst them. Whereas user C only spends about 10% of the time transmitting. And unfortunately for user C, they spend a large amount of time waiting for the other users to stop transmitting. So we get this unfairness amongst the users. User C gets only a small amount of time transmitting and a large time waiting for the others. And that could have a negative impact on the application for user C. So generally, to achieve fairness amongst the users, we would use a small payload and an equal size payload amongst the users. So another reason for using a small payload. So we've looked at different issues with how we'd choose the packet size. And in particular, the payload given the header or trailer are fixed. We cannot change them. Going through four different issues and trade-offs. For example, the packet overhead is less when we have large packets. The retransmissions are less with small packets. We're more efficient in using the buffer with small packets. And in the case of a shared medium, we can be more fair with small packets. So it depends upon the network or the link we're using as to what the appropriate packet size should be. We'll finish with a few more examples of packets, packet structures and packet sizes.