1. TheLISTEN call could indicate a willingness to establish new connections but not block. When an attempt to connect was made, the caller could be given a signal. It would then execute, say,OK orREJECT to accept or reject the con-nection. In our original scheme, this flexibility is lacking.
2. Since the two end points are peers, a separate application-level mechanism is needed that informs the end points at run time about which end will act as server and which end will act as client, as well as their addresses. One way to do this is to have a separate coordinator process that provides this information to the end points before a connection between the end points is established.
3. The dashed line from PASSIVE ESTABLISHMENT PENDING to ESTA-BLISHED is no longer contingent on an acknowledgement arriving. The tran-sition can happen immediately. In essence, the PASSIVE ESTABLISHMENT PENDING state disappears, since it is never visible at any level.
4. If the client sends a packet to SERVER PORT and the server is not listening to that port, the packet will not be delivered to the server.
5. The connect( ) may fail if the server hasn’t yet executed its listen( ) call.
6. One other criteria is how the client is affected by extra delay involved in pro-cess server technique. The server for the requested service has to be loaded and probably has to be initialized before the client request can be serviced.
7. (a) The clock takes 32768 ticks, i.e., 3276.8 sec to cycle around. At zero gen-eration rate, the sender would enter the forbidden zone at 3276.8 − 60 = 3216.8 sec.
(b) At 240 sequence numbers/min, the actual sequence number is 4t, where t is in sec. The left edge of the forbidden region is 10(t − 3216.8). Equating these two formulas, we find that they intersect at t = 5361.3 sec.
8. Look at the second duplicate packet in Fig. 6-11(b). When that packet arrives, it would be a disaster if acknowledgements to y were still floating around.
9. Deadlocks are possible. For example, a packet arrives at A out of the blue, and A acknowledges it. The acknowledgement gets lost, but A is now open while B knows nothing at all about what has happened. Now the same thing happens to B, and both are open, but expecting different sequence numbers.
Timeouts have to be introduced to avoid the deadlocks.
10. No. The problem is essentially the same with more than two armies.
11. Variation in the round trip time of a link is typically very low, and as a result, it is relatively straight forward to set an optimal timeout value for retransmit-ting a message. On the other hand, RTT can vary widely in an internet due to several reasons such as network congestion. As a result, timeout value needs to be updated dynamically based on current network conditions.
12. If the AW or WA time is small, the events AC (W) and WC (A) are unlikely events. The sender should retransmit in state S1; the receiver’s order does not matter.
13. Allocation for flow A will be 1/2 on links R1R2 and R2R3. Allocation for flow E will 1/2 on links R1R2 and R2R6. All other allocations remain the same.
14. The sliding window is simpler, having only one set of parameters (the win-dow edges) to manage. Furthermore, the problem of a winwin-dow being increased and then decreased, with the segments arriving in the wrong order, does not occur. However, the credit scheme is more flexible, allowing a dynamic management of the buffering, separate from the acknowledgements.
15. In AIAD and MIMD, the users will oscillate along the efficiency line, but will not converge. MIAD will converge just like AIMD. None of these policies are stable. Decrease policy in AIAD and MIAD is not aggressive, and increase policy in MIAD and MIMD is not gentle.
16. No. IP packets contain IP addresses, which specify a destination machine.
Once such a packet arrived, how would the network handler know which pro-cess to give it to? UDP packets contain a destination port. This information is essential so they can be delivered to the correct process.
17. It is possible that a client may get the wrong file. Suppose client A sends a request for file f1 and then crashes. Another client B then uses the same pro-tocol to request another file f2. Suppose client B, running on the same machine as A (with the same IP address), binds its UDP socket to the same port that A was using earlier. Furthermore, suppose B’s request is lost. When the server’s reply (to A’s request) arrives, client B will receive it and assume that it is a reply its own request.
18. Sending 1000 bits over a 1 Gbps line takes 1 µsec. The speed of light in fiber optics is 200 km/msec, so it takes 0.5 msec for the request to arrive and another 0.5 msec for the reply to get back. In all, 1000 bits have been transmitted in 1 msec. This is equivalent to 1 megabit/sec, or 1/10 of 1%
efficiency.
19. At 1 Gbps, the response time is determined by the speed of light. The best that can be achieved is 1 msec. At 1 Mbps, it takes about 1 msec to pump out the 1024 bits, 0.5 msec for the last one to get to the server, and 0.5 msec for the reply to get back in the best case. The best possible RPC time is then 2
msec. The conclusion is that improving the line speed by a factor of 1000 only wins a factor of two in performance. Unless the gigabit line is amaz-ingly cheap, it is probably not worth having for this application.
20. Here are three reasons. First, process IDs are OS-specific. Using process IDs would have made these protocols OS-dependent. Second, a single process may establish multiple channels of communications. A single process ID (per process) as the destination identifier cannot be used to distinguish between these channels. Third, having processes listen on well-known ports is easy, but well-known process IDs are impossible.
21. A client will use RPC over UDP if the operation is idempotent and the length of all parameters or results is small enough to fit in a single UDP packet. On the other hand if the parameters or results are large, or the operation is not idempotent, he will use RPC over TCP.
22. Audio/video streams are fairly insensitive to frame losses. However, they are very senstive to variation in transmission delays. TCP guarantees reliable delivery using retransimmsion of lost packets, but retransmissions introduce significant delays. The important fact is that some data that arrives too late is worthless. Also, TCP does not support multicast. RTP implemented over TCP is preferable if the audio/video stream being transmitted is not realtime and the network is highly lossy. TCP can run over highly lossy networks with acceptable throughput, but uncompensated losses in UDP would make audio or video quality extremely poor.
23. In N, since the maximum delay is 10 seconds, an appropriate buffer can be chosen to store a little more than 10 seconds of data at destination D. This will ensure that there will be no jitter experienced. On the other hand, in N 2, a smaller buffer, perhaps 2-3 seconds will be used, but some frames (that experience larger delays) will be dropped.
24. The default segment is 536 bytes. TCP adds 20 bytes and so does IP, making the default 576 bytes in total.
25. Even though each datagram arrives intact, it is possible that datagrams arrive in the wrong order, so TCP has to be prepared to reassemble the parts of a message properly.
26. Each sample occupies 4 bytes. This gives a total of 256 samples per packet.
There are 44,100 samples/sec, so with 256 samples/packet, it takes 44100/256 or 172 packets to transmit one second’s worth of music.
27. Sure. The caller would have to provide all the needed information, but there is no reason RTP could not be in the kernel, just as UDP is.
28. No. A connection is identified only by its sockets. Thus, (1, p) – (2, q) is the only possible connection between those two ports.
29. The ACK bit is used to tell whether the 32-bit field is used. But if it were not there, the 32-bit field would always have to be used, if necessary acknowledg-ing a byte that had already acknowledged. In short, it is not absolutely essen-tial for normal data traffic. However, it plays a crucial role during connection establishment, where it is used in the second and third messages of the three-way handshake.
30. The entire TCP segment must fit in the 65,515-byte payload field of an IP packet. Since the TCP header is a minimum of 20 bytes, only 65,495 bytes are left for TCP data.
31. One way starts out with a LISTEN. If a SYN is received, the protocol enters the SYN RECD state. The other way starts when a process tries to do an active open and sends a SYN. If the other side was opening too, and a SYN is received, the SYN RECD state is also entered.
32. Even though the user is typing at a uniform speed, the characters will be echoed in bursts. The user may hit several keys with nothing appearing on the screen, and then all of a sudden, the screen catches up with the typing.
People may find this annoying.
33. The first bursts contain 2K, 4K, 8K, and 16K bytes, respectively. The next one is 24 KB and occurs after 40 msec.
34. The next transmission will be 1 maximum segment size. Then 2, 4, and 8.
So after four successes, it will be 8 KB.
35. The successive estimates are 29.6, 29.84, 29.256.
36. One window can be sent every 20 msec. This gives 50 windows/sec, for a maximum data rate of about 3.3 million bytes/sec. The line efficiency is then 26.4 Mbps/1000 Mbps or 2.6 percent.
37. The goal is to send 232 bytes in 120 sec or 35,791,394 payload bytes/sec.
This is 23,860 1500-byte frames/sec. The TCP overhead is 20 bytes. The IP overhead is 20 bytes. The Ethernet overhead is 26 bytes. This means that for 1500 bytes of payload, 1566 bytes must be sent. If we are to send 23,860 frames of 1566 bytes every second, we need a line of 299 Mbps. With any-thing faster than this we run the risk of two different TCP segments having the same sequence number at the same time.
38. IP is a network level protocol while TCP is an end-to-end transport level pro-tocol. Any change in the protocol specification of IP must be incorporated on all routers in the Internet. On the other hand, TCP can works fine as long as the two end points are running compatible versions. Thus, it is possible to
have many different versions of TCP running at the same time on different hosts, but not this is not the case with IP.
39. A sender may not send more than 255 segments, i.e., 255 × 128 × 8 bits, in 30 sec. The data rate is thus no more than 8.704 kbps.
40. Compute the average: (270,000 × 0 + 730,000 × 1 msec)/1,000,000. It takes 730 µsec.
41. It takes 4 × 10 = 40 instructions to copy 8 bytes. Forty instructions takes 40 nsec. Thus, each byte requires 5 nsec of CPU time for copying. The system is thus capable of handling 200 MB/sec or 1600 Mbps. It can handle a 1-Gbps line if no other bottleneck is present. The size of the sequence space is 264 bytes, which is about 2 × 1019 bytes.
42. A 75-Tbps transmitter uses up sequence space at a rate of 9.375 × 1012 sequence numbers per second. It takes 2 million seconds to wrap around.
Since there are 86,400 seconds in a day, it will take over 3 weeks to wrap around, even at 75 Tbps. A maximum packet lifetime of less than 3 weeks will prevent the problem. In short, going to 64 bits is likely to work for quite a while.
43. With a packet 11.72 times smaller, you get 11.72 times as many per second, so each packet only gets 6250/11.72 or 533 instructions.
44. The speed of light in fiber and copper is about 200 km/msec. For a 20-km line, the delay is 100 µsec one way and 200 µsec round trip. A 1-KB packet has 8192 bits. If the time to send 8192 bits and get the acknowledgement is 200 µsec, the transmission and propagation delays are equal. If B is the bit time, then we have 8192B = 2 × 10−4 sec. The data rate, 1/B, is then about 40 Mbps.
45. The answers are: (1) 18.75 KB, (2) 125 KB, (3) 562.5 KB, (4) 1.937 MB. A 16-bit window size means a sender can send at most 64 KB before having to wait for an acknowledgement. This means that a sender cannot transmit con-tinuously using TCP and keep the pipe full if the network technology used is Ethernet, T3, or STS-3.
46. The round-trip delay is about 540 msec, so with a 50-Mbps channel the bandwidth-product delay is 27 megabits or 3,375,000 bytes. With packets of 1500 bytes, it takes 2250 packets to fill the pipe, so the window should be at least 2250 packets.