Suppose the network layer provides the following service. The network layer in the source host accepts a segment of maximum size 1,200 bytes and a destination host address from the transport layer. The network layer then guarantees to deliver the segment to the transport layer at the destination host. Suppose many network application processes can be running at the destination host.
- Design the simplest possible transport-layer protocol that will get application data to the desired process at the destination host. Assume the operating system in the destination host has assigned a 4-byte port number to each running application process.
- Modify this protocol so that it provides a “return address” to the destination process.
- In your protocols, does the transport layer “have to do anything” in the core of the computer network?
- Call this protocol Simple Transport Protocol (STP). At the sender side, STP accepts from the sending process a chunk of data not exceeding 1196 bytes, a destination host address, and a destination port number. STP adds a four-byte header to each chunk and puts the port number of the destination process in this header. STP then gives the destination host address and the resulting segment to the network layer. The network layer delivers the segment to STP at the destination host. STP then examines the port number in the segment, extracts the data from the segment, and passes the data to the process identified by the port number.
- The segment now has two header fields: a source port field and destination port field. At the sender side, STP accepts a chunk of data not exceeding 1192 bytes, a destination host address, a source port number, and a destination port number. STP creates a segment which contains the application data, source port number, and destination port number. It then gives the segment and the destination host address to the network layer. After receiving the segment, STP at the receiving host gives the application process the application data and the source port number.
- No, the transport layer does not have to do anything in the core; the transport layer “lives” in the end syste
Consider a planet where everyone belongs to a family of six, every family lives in its own house, each house has a unique address, and each person in a given house has a unique name. Suppose this planet has a mail service that delivers letters from source house to destination house. The mail service requires that (1) the letter be in an envelope, and that (2) the address of the destination house (and nothing more) be clearly written on the envelope. Suppose each family has a delegate family member who collects and distributes letters for the other family members. The letters do not necessarily provide any indication of the recipients of the letters.
- Using the solution to Problem R1 (Simple Transport Protocol) above as inspiration, describe a protocol that the delegates can use to deliver letters from a sending family member to a receiving family member.
- In your protocol, does the mail service ever have to open the envelope and examine the letter in order to provide its service?
- a family member from house A gives his letter (destined to house B), recipient, and address to delegate A,
- delegate A writes the recipient on the letter
- delegate A puts the letter in an envelope
- delegate A writes address B on the envelope
- delegate A delivers the envelope to the mail service
- the mail service delivers the envelope to house B
- delegate B opens the letter and reads the recipient
- delegate B delivers the letter to the recipient
- No
How is a UDP socket fully identified? What about a TCP socket? What is the difference between the full identification of both sockets?
TCP uses src/dst port/ip (4-tuple) where UDP uses src/dst port (2-tuple).
In particular, and in contrast with UDP, two arriving TCP segments with different source IP addresses or source port numbers will (with the exception of a TCP segment carrying the original connection-establishment request) be directed to two different sockets.
Describe why an application developer might choose to run an application over UDP rather than TCP.
If the service does not deliver large chunks of data and speed is more valuable then reliability. If TCP’s congestion control reduces the bandwidth too much.
Why is it that voice and video traffic is often sent over TCP rather than UDP in today’s Internet? (Hint: The answer we are looking for has nothing to do with TCP’s congestion-control mechanism.)
Since most firewalls are configured to block UDP traffic, using TCP for video and voice traffic lets the traffic though the firewall.
Is it possible for an application to enjoy reliable data transfer even when the application runs over UDP? If so, how?
Yes. The application developer can put reliable data transfer into the application layer protocol. This would require a significant amount of work and debugging, however.
Suppose a process in Host C has a UDP socket with port number 6789. Suppose both Host A and Host B each send a UDP segment to Host C with destination port number 6789. Will both of these segments be directed to the same socket at Host C? If so, how will the process at Host C know that these two segments originated from two different hosts?
Yes, both segments will be directed to the same socket. For each received segment, at the socket interface, the operating system will provide the process with the IP addresses to determine the origins of the individual segment.
Suppose that a Web server runs in Host C on port 80. Suppose this Web server uses persistent connections, and is currently receiving requests from two different Hosts, A and B. Are all of the requests being sent through the same socket at Host C? If they are being passed through different sockets, do both of the sockets have port 80? Discuss and explain.
For each persistent connection, the Web server creates a separate “connection socket”. Each connection socket is identified with a four-tuple: (source IP address, source port number, destination IP address, destination port number).
When host C receives and IP datagram, it examines these four fields in the datagram/segment to determine to which socket it should pass the payload of the TCP segment. Thus, the requests from A and B pass through different sockets.
The identifier for both of these sockets has 80 for the destination port; however, the identifiers for these sockets have different values for source IP addresses.
In our rdt protocols, why did we need to introduce sequence numbers?
Sequence numbers are required for a receiver to find out whether an arriving packet contains new data or is a retransmission.
In our rdt protocols, why did we need to introduce timers?
To handle losses in the channel. If the ACK for a transmitted packet is not received within the duration of the timer for the packet, the packet (or its ACK or NACK) is assumed to have been lost. Hence, the packet is retransmitted.
Suppose that the roundtrip delay between sender and receiver is constant and known to the sender. Would a timer still be necessary in protocol rdt 3.0, assuming that packets can be lost? Explain.
A timer would still be necessary in the protocol rdt 3.0.
If the round trip time is known then the only advantage will be that, the sender knows for sure that either the packet or the ACK (or NACK) for the packet has been lost, as compared to the real scenario, where the ACK (or NACK) might still be on the way to the sender, after the timer expires.
However, to detect the loss, for each packet, a timer of constant duration will still be necessary at the sender.
With the Go-Back-N protocol when a receiver gets an out of order sequence numbered packet what does the receiver do?
What does a sender do when it detects a timeout for sequence N after having sent sequence numbers [N, N+1, …, N + k]?
What are the demarkation points in regard to a GBN protocol with N windows?
What are some issues related to GBN?
Packets with unexpected sequence numbers are dropped at the receiver and an ACK with the last valid sequence number is returned to the sender.
Once a sender timeouts they will go back and resend all packets after the last ACK’d packet. i.e. retransmit packets with sequence numbers [N, N+1, …, N+k].
Recall that sequence numbers in TCP indicate the byte number not a count.
Issues can arise when N becomes large and causes many uneeded retransmissions.
True or false?
- Host A is sending Host B a large file over a TCP connection. Assume Host B has no data to send Host A. Host B will not send acknowledgments to Host A because Host B cannot piggyback the acknowledgments on data.
- The size of the TCP rwnd never changes throughout the duration of the connection.
- Suppose Host A is sending Host B a large file over a TCP connection. The number of unacknowledged bytes that A sends cannot exceed the size of the receive buffer.
- Suppose Host A is sending a large file to Host B over a TCP connection. If the sequence number for a segment of this connection is m, then the sequence number for the subsequent segment will necessarily be m + 1.
- The TCP segment has a field in its header for rwnd.
- Suppose that the last SampleRTT in a TCP connection is equal to 1 sec. The current value of TimeoutInterval for the connection will necessarily be >= 1 sec.
- Suppose Host A sends one segment with sequence number 38 and 4 bytes of data over a TCP connection to Host B. In this same segment the acknowledgment number is necessarily 42.
- false
- false
- true
- false
- true
- false
- false
Suppose Host A sends two TCP segments back to back to Host B over a TCP connection. The first segment has sequence number 90; the second has sequence number 110.
- How much data is in the first segment?
- Suppose that the first segment is lost but the second segment arrives at B. In the acknowledgment that Host B sends to Host A, what will be the acknowledgment number?
- 20 bytes
- 90??
True or false? Consider congestion control in TCP. When the timer expires at the sender, the value of ssthresh is set to one half of its previous value.
When a timeout event occurs in cogestion controlled TCP the value of ssthresh is set to cwnd / 2 and cwnd is set to 1 MSS. So false.
Recall Events
Slow Start: cwnd = ssthresh -> CA, Ack, DupAck, 3DupAck -> FR, Timeout
Congestion Avoidance: Ack, DupAck, 3DupAck -> FR, Timeout -> SS
Fast Recovery: Ack -> CA, DupAck, Timeout -> SS
Describe a TCP header. (SDSAHUFRCUO)
Describe a UDP header (SDLC)
Describe the Selective-Repeat protocol.
Similar to GBN but the receiver buffers out of order packets after sending an ACK for that packet and once all packets are received it sends up to the application layer.
The sender maintains the ACK state for each packet is has sent within it’s window and only resends packets that have timed out.
A potential problem occurs when N is set to low.
