This test has six questions. The test runs the entire class period, starting at 4:30 and ending at 6:20. When you finish the test, you may leave.
Always justify answers unless the question explicitly states it’s not necessary. Some questions require reasonable assumptions in order to be answered. In such cases the answer should clearly state the assumptions made.• Transport layer• Go-back-n protocol• Connection-oriented protocol• Congestion control• Flow control
Keeping in mind that giving an example of X is not defining X, briefly (in one or two sentences, 25 to 30 words) define:
• Transport layer:The network layer providing end-to-end communication services.• Go-back-n protocol:A reliability protocol transmitting blocks of unacknowledged PDUs. Recovery is determined by the first PDU in the block, and the entire block is retransmitted when the first PDU is lost.• Connection-oriented protocol:A procotol maintaining state at the end-points of the connection to implement the protocol’s services.• Congestion control:A mechanism that modulates PDU transmission to maintain appropriate network characteristics.• Flow control:A mechanism that modulates PDU transmission so as not to overwhelm the receiver.
A successful TCP three-way handshake establishes common state at the end-points in a connection-oriented communication. Such state includes expected next sequence number, receive-window size, and addresses (port and host).
There are two approaches to provide flow control in UDP-based communication. The first uses some form of sliding window protocol — such as stop-and-wait (in the degenerate case) or sliding-window — to limit the number of PDUs in transit based on receiver feedback. The other, rate-based, approach negotiates a transmission rate based on receiver characteristics during connection set-up (which becomes part of the UDP-based protocol).
The performance of stop-and-wait is b/r bit/sec, where b is the PDU size in bits and r is the round-trip time in seconds. Go-back-n improves on stop-and-wait performance by sending n unacknowledged PDUs as a block. This is equivalent to sending a single PDU of size nb. The acknowledgments also come back as a block, although the spacing is a bit looser than it is for the PDU block. In this view go-back-n behaves like stop-and-wait with large PDUs, and the performance is approximately nb/r bit/sec, an factor of n improvement over stop-and-wait.
If you are upset about using r as the round-trip time for go-back-n, assume direction-uniform link rates and send-receive rates (t bit/sec) the same as the link rates, a reasonable assumption for low Gbit/sec links and modern network interface cards. A PDU is a few kbits in length and PDU send-receive time is 105/109 = 1 ms. It will take the receiver n ms to read the PDUs and write the acks (assume the acks are at least an order of magnitude smaller than the PDUs, so their send-receive times are negligible). The n PDUs are sent and acknowledged in r + (n ms). If r is large relative to n, the round-trip time is r. If r is small relative to n, the round trip time increases additively, but the bits transferred increases mutlipliciatively, still an improvement over stop-and-wait.
If an error-prone wireless network (or any kind of error-prone network) drops a PDU, it’s most likely because the PDU is corrupted, not because there’s congestion. TCP, however, always interprets a dropped PDU as congestion and throttles transmission in response. Slowing transmission is the wrong way to recover from corrupt PDUs. Better recovery involves speeding-up (re)transmissions to quickly replace corrupted PDUs, assuming an end-point can distinguish between PDUs lost to corruption and PDUs lost to congestion. (Even better recovery involves adding extra information to a PDU so corruption can be repaired instead being thrown away, but we haven’t talked about error-correcting codes yet.)
Some observations about well-known port numbers: 1) they are a push service; a sender knows a port number and pushes it to the receiver. 2) Well-known port numbers allow fast and efficient demultiplexing at the receiver. 3) For port numbers to be well-known requires some central mechanism to, at least conceptually, maintain the well-knownedness of port numbers. Without well-known port number these observations no longer hold and have to be replaced. There are lots of replacements possible, what follows is just an example.
Having nothing to push, senders have to pull. A sender requests from a receiver a list of services available from the receiver and gets back a list of port-service pairs. The port numbers returned are not well known; they are established locally by the receiver, and vary from system to system. The sender picks the service it wants, if it’s available, and returns (pushes) the associated port number.
Without well-known port numbers, their replacement has to be done at a non-multiplexing level in the transport layer. IP, for example, could add a new ICMP message to pull mappings, or define a new service. If the transport layer has no non-multiplexing level, then well-known port numbers are an essential part of the transport protocol, and removing them requires developing new transport protocols.Pulling mappings from receivers is decentralized to each sender, which is inefficient. Central mappings can be re-established by a DNS-like service, keeping in mind it has to be implemented in the non-multiplexing part of the transport layer.