Most IP datagram reassembly algorithms have a timer to avoid having a lost fragment tie up reassembly buffers forever. Suppose that a datagram is fragmented into four fragments. The first three fragments arrive, but the last one is delayed. Eventually, the timer goes off and the three fragments in the receiver's memory are discarded. A little later, the last fragment stumbles in. What should be done with it?

Most IP datagram reassembly algorithms have a timer to avoid having a lost fragment tie up reassembly buffers forever. Suppose that a datagram is fragmented into four fragments. The first three fragments arrive, but the last one is delayed. Eventually, the timer goes off and the three fragments in the receiver's memory are discarded. A little later, the last fragment stumbles in. What should be done with it?

Systems Architecture

7th Edition

ISBN:9781305080195

Author:Stephen D. Burd

Publisher:Stephen D. Burd

Chapter9: Computer Networks

Section: Chapter Questions

Problem 15VE

See similar textbooks

Similar questions

Most IP datagram reassembly algorithms have a timer to avoid having a lost fragment tie up reassembly buffers forever. Suppose that a datagram is fragmented into four fragments. The first three fragments arrive, but the last one is delayed. Eventually, the timer goes off and the three fragments in the receiver's memory are discarded. A little later, the last fragment stumbles in. What should be done with it?
R6Fragmentation of an IP datagram takes place if its size is larger than the MTU of the subnet over which the datagram will be routed. Most IP datagram reassembly algorithms have a timer to avoid having a lost fragment tie up reassembly buffers forever. Suppose a datagram is fragmented into four fragments. The first three fragments arrive, but the last one is delayed. Eventually the timer goes off and the three fragments in the receiver's memory are discarded. A little later, the last fragment stumbles in. What should be done with it?
Write a program to simulate the behavior of the CSMA/CD protocol over Ethernet when ther are N stations ready to transmit while a frame is being transmitted. Your program should report the times when each station successfully starts sending its frame. Assume that a clock tick occurs every slot time (51.2 microsec) and a collison detection and sending of a jamming sequence takes one slot time. All frames are the maximum length allowed.
In an RPC-like protocol, where numerous requests can be active at the same time and responses can be given in any sequence, the following is possible: Pretend requests are sequentially numbered, and that ACK[N] confirms the receipt of reply[N]. Should the number of ACKs be cumulative? If not, what should happen in the event that an ACK is not received?
In an RPC-like protocol in which multiple requests can be outstanding, and replies can be sent in any order: Assume that requests are numbered and that ACK[N] acknowledges reply[N]. Should ACKs be cumulative? If not, what should happen if an ACK is lost?
Write a program to simulate the behaviour of the CSMA/CD protocol over Ethernet when there are N stations ready to transmit while a frame is being transmitted your program should report the times when euch station successfully starts sending its frame. Assume that a clock tick occurs once every slot time (57.2 usec) and a collision detection and sending of a jamming sequence. takes one slot time. All frames are the maximum length allowed
Consider a scenario in which Host A wants to simultaneously send packets to Hosts B and C. A is connected to B and C via a broadcast channel—a packet sent by A is carried by the channel to both B and C. Suppose that the broadcast channel connecting A, B, and C can independently lose and corrupt packets (and so, for example, a packet sent from A might be correctly received by B, but not by C). Design a stop-and-wait-like error-control protocol for reliably transferring packets from A to B and C, such that A will not get new data from the upper layer until it knows that both B and C have correctly received the current packet. Give FSM descriptions of A and C.
Material must be played out in a specific time intervals in order to be correctly interpreted by the recipient. Real-time protocols take varying transit times to get from source to destination. Even if packets are sent with the correct intervals, they will arrive at the other end with varying arrival times. Jitter is referred to as a fluctuation of pause time. We can buffer the packets for jitter reduction Let us say that, for the sake of argument, the noise is random, and the buffer is adequate. Armed with this knowledge, tell us what other difficulties are there?
Material must be played out in a specific time intervals in order to be correctly interpreted by the recipient. Real-time protocols take varying transit times to get from source to destination. Even if packets are sent with the correct intervals, they will arrive at the other end with varying arrival times. Jitter is referred to as a fluctuation of pause time. We can buffer the packets for jitter reduction Let us say that, for the sake of argument, the noise is random, and the buffer is adequate. Armed with this knowledge, tell us what other difficulties we can face.
Take for example a scenario in which one computer on the Internet sends a packet to another computer via the network layer. The information included in the packet's logical destination address has been tampered with. Where is the item supposed to be delivered? How will the situation be relayed to the computer that is the cause of the problem?
In TCP Fast Retransmit, if we receive three duplicate ACKS after sending out a packet that is not incrementally ACK-ed but before the time-out associated with that packet, we immediately retransmit the packet without waiting for the timeout to occur. Why do we wait for three duplicates instead of just one?
One of the problems with timeout-triggered retransmissions is that the timeout period can be relative long. When a segment is lost, this long timeout period forces the sender to delay resending the lost packet, thereby increasing the end-to-end delay. Is there any remedy for this?