Problem 2 was done quite badly. Here is a ``model solution''. I may ask a similar question again on the final. 2a. 4W1: There is a four-way handshake with packets at times 12:26:01.583760, 12:26:01.583799, 12:26:01.716615, 12:26:01.716990. The connection being closed was between www.njit.edu port 80 and maan.njit.edu port 34559, protocl TCP. www.njit.edu initiates the closing. 3W1: There is a three-way handshake with packets at times 12:26:01.717912, 12:26:01.718352, 12:26:01.718382. The connection being opened is between maan.njit.edu port 34563 and www.njit.edu port 80, Protocol TCP. maan initiates the handshake. 4W2: There is a four-way handshake with packets at times 12:26:02.362607, 12:26:02.362658, 12:26:02.965855, 12:26:02.966253. The connection being closed was between maan.njit.edu port 24563 and www.njit.edu port 80, Protocol TCP. www.njit.edu initiates the closing. 3W2: There is a three-way handshake with packets at times 12:26:02.967207, 12:26:02.967636, 12:26:02.967665. The connection being openend is between maan.njit.edu port 34564 and www.njit.edu port 80, Protocol TCP. maan initiates the opening. 2b. 3W1 and 4W2 are the opening and closing of the same pair of flows. 2c. The packets concerned are indeed of the same flow and have the same acknowledgement numbers, but since the later packet contains data, it is NOT a duplicate acknowledgement. (It contains databytes 21534 - 22106, i.e. 572 databytes). 2d. If we look at 3W1 and 3W2 we see that the initiator (maan) advertises its willingness to use ``SACK'', but the responder (www) does not react to that willingness. Hence, maan understands SACK but www.njit.edu does not. 2e. If we look at the first FIN in 4W2, we see it contains databytes 2850 until 2850. This is the offset with respect to the original sequence number. Hence, in the flow between ports 80 and 34563, maan received about 2850 databytes. (It could be one more or one less, depending on exactly how the offset is computed). If we look at the second FIN in 4W2, we see it contains databytes 2836 until 2836. Hence, in the flow between ports 80 and 34563, www.njit.edu received about 2836 databytes. The conclusion can also be drawn from the ack numbers. In that case, don't forget to change the directions! 2f. From just about any packet, we see that www.njit.edu has IP address (80eb fb19) {hex}, i.e. 128.235.251.25 . For example, the source address in the first and second packets, or the destination address in the third packet. 4a: The ``Silly Window Syndrome'' describes ther situation where a TCP connection unnecessarily carries data packets where the number of data] bytes is small compared with th4e MSS (Maximum Segment Size). In this situation, the TCP connection makes bad use of network bandwidth. In the extreme, a TCP/IP datapacket can carry one data bytes and 40 header bytes: 40/41 0verhead and 1/41 payload. If you include the MAC header it is even worse, and with acknowledgements even worse. A TCP connection can get into this situation if either the source application or the destination application is slow. If the source application is slow and the advertised window sufficiently large, the source TCP can send a small packet every time it gets a few bytes from the source application. If the destination application is slow and the advertised window becomes the bottleneck, the destination TCP can send an acknowledgement increasing the right hand side of the window every time the application accepts a few bytes. The source TCP then sends sends a small packet every time it receives such an acknowledgement. Once a TCP connection is in this situation, the Silly Window Syndrome can become self-sustaining even if the original cause disappears: the source keeps sending small packets, the destination acknowledges each, causing the ``next expected byte'' to increase by a few bytes, which causes the source to send another small packet. 4b. There are three methods to counteract the ``silly window syndrome''. Of these, Nagle's Algorithm (at sender side) and Delayed Acknowledgements (at receiver side) are the most important. Clark's algorithm (receiver side) is less important. A. Nagle's algorithm: Apart from just after the three-way handshake (set-up), the source sends a packet only if (at least) one of the following two conditions holds: (i) It can send a packet containing a whole MSS, or (ii) It just received an acknowledgement increasing the ``next expected byte''. B. Delayed Acknowledgements: The receiver does not (necessarily) send an acknowledgement for every data packet it receives. It sends an acknowledgement (increased ack number) if either: (i) a data packet arrives and it already has an unacknowledged data packet, or (ii) the ``delayed ack'' clock ticks and it has an unacknowledged data packet. The frequency of the ``delayed ack'' clock is system dependent. The delayed ack mechanism depends on the fact that in TCP all acknowledgements are cumulative. Nagle's algorithm and Delayed Acknowledgements by themselves are not very effective in couteracting the Silly Window Syndrome. Together they are very powerful. ***** In the final I may ask how they work together. ***** C. Clark's solution. Dave Clark at MIT suggested the following: The receiver sends an acknowledgement every time it can increase the ack number, but unless it can advertise a window of at least 1 MSS it advertises a window of zero bytes. (And then later, as soon as possible, a window of at least one MSS). Clark's solution presumably is effective in case of a slow receiver application, but useless in case of a slow source application, such as many Telnet connections. **IF** I ask this question again you need not mention Clark's solution. Problem 5: See RFC 1122, sections 3.3.2. and 3.3.3. EMTU-R: Effective MTU for Receiving (or ``reassembly buffer size''). EMTU-S: Effective MTU for Sending. MTU: Maximum Transfer Unit. Problem 6: RIP = Routing Information Protocol. Problem 7a: Subnetwork: 1 2 3 4 5 6 7 8 9 10 distance: 0 2 2 0 1 4 0 5 3 5 Next Hop: DD B E DD B E DD E E E Discussion: (Not asked for) Route to subnet 3 changes to E (shorter distance). Route to subnet 6 becomes shorter distance, sticks with E. Route to subnet 8 becomes LONGER, sticks with E. Route to subnetwork 10 added. Route to subnetwork 2: no change (ty in hopcount). Routes to subnetworks 1, 4, 5, 7: no change, old one better. Route to subnetwork 9: Since E is the old ``next hop'' and also the router that sends the advertisement, E will be the next hop and the new hopcount will be the advertised value + 1. It just so happens that that is the old hopcount. (Will this happen often?). Problem 7b: Subnetwork: 1 2 3 4 5 6 7 8 9 10 distance: 0 16 3 0 16 5 0 2 3 (not advertised) Discussion: (Not asked for) Router A advertises its vector of distances. Only, for those routes where router B is the next hop, router A tells router B the distance is ``infinity'' (poisoned reverse). In RIP 1 the ``next hop'' is **NOT** advertised. In RIP 2 the ``next hop'' ***IS*** advertised. Problem 8a: the mask is 22 ones followed by 10 zeros. If you are willing to spend the time you can write that as 255.255.252.0 (easy: 255 - 3 = 252). 8b: 128.235.35.0 . The first 22 bits are the same as in the network. The last 10 bits are 11 0000 0000 . Neither all zeros nor all ones. This is a legal address in the network, it can occur as address of an interface. Therefore it can occur as both source address and destination address. 8c: 128.235.32.0 . This is the network address. It can not occur as source address or destination address (or address of an interface). 8d: 128.235.35.255 . The last 10 bits are ones, and the first 22 are the same as in the network address. This is a direct broadcast address to the network. It can occur as destination address. It can not occur as source address (or as address of an interface). 8e: 255.255.255.255 . This is the limited broadcast address. It can occur as destination address, not as source address or as address of an interface. 8f: 0.0.0.0 . This is the ``I am stupid'' address (also known as ``THIS host on THIS network''). It can occur as source address, not as destination address or as address of an interface.