Outline

• Finish RTT Estimation in TCP
• Quiz
• Remote Procedure Calls

Introduction

• Last day, we were talking about different algorithms for estimating round trip times in TCP.
• 2×EstimatedRTT is used as the TimeOut for segment acknowledgment.
• We looked at the original algorithm to compute the EstimatedRTT based on a weighted sum of the EstimatedRTT together with the most recent SampleRTT time.
• We then looked at the Karn/Partridge algorithm (1987) which rather than including every SampleRTT into the running average, only includes those RTTs of segments which were sent and acknowledged without having to be re-sent.

Jacobson/Karels Algorithm

• In 1988, Jacobson/Karels proposed several changes to TCP to battle congestion.
• One source of congestion is re-sent segments because TCP timed-out too soon on a segment.
• The running average approach of the original and Karn/Partridge EstimateRTT algorithms does not take into account the variance one would expect in the RTT.
• The reason why variance might be important is that if it is small then the EstimatedRTT can be trusted and there is no reason to multiply it by 2 to compute the timeout; however, if it is large then it suggests the EstimatedRTT is untrustworthy and should not be couple too tightly to the timeout period.
• So one thing that Jacobson/Karels proposed was a means to take this into account.
• They compute the EstimatedRTT and TimeOut periods as follows:

  Difference = SampleRTT - EstimatedRTT
  EstimatedRTT = EstimatedRTT + (δ×Difference)
  Deviation = Deviation + δ(|Difference| - Deviation)
  
  Timeout = μ×EstimatedRTT + φ×Deviation
  

• Here δ is between 0 and 1 and μ and φ are typically set by hand commonly to the values 1 and 4.
• The book shows how to scale things by a factor of 2ⁿ so that the above calculations can be done without the need of floating point.
• Another thing to note is that the calculations above are only as good as the clocks on which they are based.
• Some old Unix implementations of TCP only checked to see whether a timeout should occur every 500ms, so this actually swamps the 100-200ms RTT for a transcontinental connection.
• There are extensions to TCP to make the timing mechanisms more robust.

Record Boundaries

• TCP is a byte-stream protocol. The sender sends bytes which happen to be put into segments.
• For instance, the sender might send 10 bytes in the first segment 20 in the next.
• Usually, the application at the receiver is only aware that there are bytes it can read from the receiving TCP laye, and not the segment boundaries. i.e., for the example above, the receiving application would not know the 10th byte was in one segment and the 11th in the next.
• TCP does support two features that can be used to inform the receiver of a message boundary: the URG flag and the push operation.
• The URG flag and the UrgPtr in the TCP header were originally supposed to be used to send "out of band data"; that is, to send things like commands to interrupt an operation already underway.
• This data would be sent to the receiving process as soon as it arrived, even if this meant delivering it before data with an earlier sequence number.
• This original use of the URG flag was not used so often; and over time, the URG pointer switched to be used to signify special data, such as a record marker.
• Similarly, the PUSH flag can also be used to flush data from the receiving buffer to a receiving process that supports PUSH, so setting this flag can also be used to indicate record boundaries.

TCP Extensions

• We have mentioned a few times that there are extensions to TCP to mitigate against problems in the original design as networks get faster.
• These extensions are realized as options that can be added to the end of the TCP header.
• Since they are designed to be optional and since they are at the end of header, if a host does not understand these options then it can still communicate using usual TCP.
• The first common extension is used to improve TCP's timeout mechanism by including a 32 bit timestamp into the segments header.
• The receiver echoes this back to the sender when it acknowledges segments. The sender subtracts the timestamp from the current time to estimate the RTT.
• A second use for the timestamp is to extend the SequenceNum. If this is used, TCP accepts or rejects a segment based on the 64 bits consisting of the timestamp in the high 32 bits and the SequenceNum in the low 32 bits.
• Another extension to TCP is to use the options to define a scaling factor for the two-byte AdvertisedWindow. i.e., rather than the AdvertisedWindow saying the window in units of bytes it says it in units of some number of bytes given by the scaling factor.
• A last common extension is to use the options field to do selective acknowledgements of data received but not contiguous to data that had been previously received.
• This enables the sender to resend only the just the segments that have not arrived.

Quiz

Which of the following statements is true about Nagle's Algorithm?

1. If there is no unacknowledged sender data in flight, then it says for new data to be put it into a segment to send immediately.
2. It solves the problem of 32 bit sequence numbers wrapping too quickly.
3. It gives a better way to estimate RTT.

Remote Procedure Call

• TCP uses a byte-oriented connection.
• Another common communication paradigm used by applications programs is the request/reply paradigm.
• A transport protocol that supports request/reply is more than simply UDP going in one direction followed by a UDP message going in the other direction.
• Besides needing to correctly identify processes on the remote host, such a protocol needs to correlate requests with responses.
• We next look at Remote Procedure Call transport protocols which are designed to give this facility.

RPC Fundamentals

• RPC is based on the semantics of a local procedure call -- the application programs makes a call into a procedure without regard to whether it is local or remote -- and blocks until the call returns.
• When the procedure being called is actually a method of a remote object in an object-oriented language RPC is known as Remote Method Invocation (RMI).
• There are two main ways that RPC is more complicated than local procedure calls:
  1. The network might do things like limit message sizes, or might lose or reorder messages.
  2. The computer on the calling side and called processes may have significantly different architectures and data representation formats.
• Thus, a complete RPC mechanism involves two main components:
  1. A protocol to manage messages sent between the client and the server processes that deals with the underlying network issues that might cause problems.
  2. Programming language and compiler support to package the arguments into a request message on the client and then to translate this message back into the arguments on the server machine. Likewise, the return values needs to be handled. This mechanism is often called a stub compiler.

The RPC Protocol

• The RPC protocol needs to:
  • Provide a name space for uniquely identifying the procedure to be called
  • Match each reply message to the corresponding request message.
• Common choices for the namespace problem are to either make it flat or to make it hierarchical.
• In the first choice an unstructured identifier like an integer ID would be carried in a single field in an RPC message.
• Some kind of central coordination would be needed to avoid assigning the same number to different procedures.
• In the second choice, some kind of analog to a file path in a filesystem is used.
• To match a reply with a corresponding request, message ID's are used. A reply should use the same message ID as the request.
• To make the RPC transaction appear like a local procedure call, the caller is blocked until the reply message is received.
• To ensure that a message ID does not get re-used because a machine went down or something, the protocol also uses a boot ID which gets incremented each time the machine is booted.

Overcoming Network Limitations

• RPC protocols often perform additional functions to deal with the fact that networks are not perfect channels. Two of these functions are: Provide reliable message delivery, and support large message sizes through fragmentation and reassembly.
• RPC might need to do the first as it is often implemented on top of IP or UDP which do not provide for reliable delivery.
• One way to do this is to have the server acknowledge requests (then start running the procedure), and the client acknowledge replies.
• The client and the server need to save a copy of their messages until they see the ACK.
• Each side also sets and uses a RETRANSMIT timer to resend the message if it is delayed too long.
• As you might guess, the server can use the reply message to implicitly acknowledge the request.
• We could also use a subsequent request to acknowledge a previous reply.
• To allow for greater flexibility, RPC often makes use of an abstraction known as a channel.
• The idea is that within a channel, request/reply transactions are sequential -- there can be only one transaction active on a given channel at a given time. The protocol then allows that there can be multiple channels.
• If this is used, in addition, to a message ID one also has a channel ID.
• To distinguish between slow versus dead server, the client periodically sends messages to a server that hasn't sent a reply asking if it is still calculating.