Outline

• More on Selective Acknowledgements
• Performance Experiments
• Alternative Design Choices for the Transport Layer
• Quiz
• Remote Procedure Calls

Introduction

• Last week, we were talking about the transport layer.
• At a minimum this layer is supposed to provided an end-to-end communication channel between two processes either on the same or different hosts across the internet.
• We looked at UDP (User Datagram Protocol) which allowed for the sending of unacknowledged datagrams between processes by making use of a header with two byte source and destination port numbers, a data length, and a checksum.
• We then looked at TCP (Transmission Control Protocol) that allowed two processes to send and receive bytes reliably and in-order.
• We went over its header components.
• We discussed the three-way handshake used to set up a TCP connection: SYN, SYN+ACK, ACK. Add the messages to close a connection such as: FIN, ACK, FIN/ACK.
• We said that to have reliable in-order delivery, sequence numbers and acknowledgements are used together with a sliding window protocol.
• We said, unlike in the Link Layer sliding window byte-ranges are acknowledged rather than frames. We described how this was done, how sender window sizes are advertised from the receiver, how the sender determines when to send a frame, how timeouts are determined by estimating the RTT of segments, etc.
• We finally concluded by talking about TCP extension headers to send 32 bit timestamps to improve RTT estimates and to avoid sequence number wrap around, to allow one to have specify larger advertised windows by saying a scaling factor, and to do selective acknowledgements.
• We begin today by looking at selective acknowledgements a little more.

More on Selective Acknowledgments

• A last common extension is to use the options field to do selective acknowledgements (SACK) 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.
• Without SACK there are two common strategies to handle timeouts:
  1. Pessimistic - retransmit the segment that timed-out together with any segments that followed. I.e., assume they will also timeout. This might cause unnecessary retransmission.
  2. Optimistic - only retransmit the segment that timed-out. This may be slow if in fact a sequence of segments was lost. This consumes one RTT/segment in the sequence.
• Using SACK, one can use the better strategy of retransmitting just the segments that fill the gaps between segments that have been selectively acknowledged.

Performance

• To evaluate protocols we have this semester used two quantitative metrics: latency and throughput (bandwidth).
• What is interesting in analyzing things at the transport layer is typically we have both hardware and software issues involved.
• Measurement of a given protocol is useful to understand the performance a particular application can expect to see.

How to Conduct Performance Experiments

• Any report of experimental results should begin by describing the experimental method. This consists of:
  • The experimental apparatus: What kind of machines, networks, etc. the experiment was conducted on, what OS and version was used, what was the test program used.
  • A description of each trial of the experiment.
  • The total number of trials.
• The report should then give the data in a meaningful format such as a graph, and discuss this data.
• For example, the book describes an experiment conducted between a pair of dual CPU 2.4 GHz Xeon processor workstations running Linux.
• The machines each have a pair of NIC Ethernet adapters and to achieve speeds above 1Gbps, the connections between the machines is than the length of a single machine room.
• Given this, processor/software overheads are what will mainly be measured as propagation is not an issue.
• The test program involved ping-ponging messages of various sizes between the two machines as quickly as possible using a standard benchmarking tool called TTCP.
• The use of standard benchmarking suites is important to allow your results to be compared with others.

Performance Experiment Example Results

• Message sizes from 256 bytes to 64 Kb were tested.
• Notice throughput improves as message sizes increase, but that the improvement flattens off on messages over 1kB.
• At that point, per-message overhead becomes insignificant compared to the large number of bytes the protocol stack needs to process.
• The maximum throughput is less than the 2Gbps available link speed.
• By looking at CPU load, one could try to determine if the bottleneck was memory bandwidth, adapter performance or some other issue.
• The test network is "perfect" in that there is almost no delay or loss, so the only factors affecting performance are TCP implementation and workstation hardware and software. This is in contrast with real-world networks where delay and loss would be an issue.
• Before we try to measure the affects of these, we will need to look at how TCP deals with congestion which we will talk about next week.

Quiz

Which of the following is true?

1. UDP doesn't allow for process to process communication.
2. Even if the advertised window goes to 0, a sender using TCP will still send segments periodically.
3. The Karn/Partridge Algorithm tries to take into account the standard deviation in the round trip time when determining how long time outs should be.

Alternative Design Choices for the Transport Layer

• So far we have seen two different transport protocols (i.e., way to set up channels between processes on hosts) UDP and TCP.
• One can classify transport protocols into two main types:
  1. Stream-oriented Protocols such as TCP where we send streams of in-order bytes back and forth between sender and receiver.
  2. Message-Oriented Protocols such a (RPC remote procedure calls) which are more request/reply protocols whether the smallest protocol unit is a message rather than a byte.
• Stream-oriented protocols can further be classified into two groups:
  1. Reliable we expect bytes to be acknowledge. (TCP)
  2. Unreliable we don't require bytes to be acknowledge. (Might be suitable for video/audio transmission and the like)

Why not use TCP for messages?

• First, we would then need some mechanism to convert from messages to bytes in segments and vice-versa (doable).
• If use native request reply, might be able to do things like fit both a request and a reply within the same IP packet.
• If TCP would need at least nine packets: three to establish a connection, two for message exchange, four to tear down the connection.
• This overhead reduces as message size grows but is still present.

Why not use a reliable message-oriented protocol rather than TCP?

• A reliable message protocol might make sense for a database application that wants to exchange records.
• For a message protocol to be about messages rather than streams needs to establish an upper bound on message size.
• Once this is fixed there will be application that will be constrained because of this upper bound.
• Although a reliable message protocol might be appropriate for applications that want to send records between each other, it is not hard to insert record boundaries into a byte stream to implement this functionality.

Transport Protocols that Relax In-order Delivery

• TCP ensures in-order delivery of bytes.
• So it may hold onto bytes that were received out of order, awaiting missing bytes to fill in a hole.
• This is unhelpful/slows things down if the application can process data out of order (a whole class of applications).
• For example, a Web Page might contain multiple embedded objects such as images, scripts, etc. It does not need to received all of these objects before starting to display the page.
• SCTP (Stream Control Transmission Protocol) and QUIC (Quick UDP Internet connections) are two IETF transport protocols that allow for out-of-order data.
• SCTP provides a partially ordered delivery service rather than strictly ordered like TCP. Packets are subdivided into chunks each with a one byte identifier types. Chunks of the same type should be in order. It also support message orientation and multi-homing (send to a first address, if fail try additional). Uses a notion of heartbeat message to check which home to use.

QUIC

• QUIC (Quick UDP Internet connections) originated at Google in 2012 and is used as part of HTTP/3 for web traffic. It is still undergoing standardization with RFCs: 8999, 9000, 9001, 9002.
• Besides the issue with embedded objects mentioned on the last slide, TCP can cause problems for web traffic on wireless devices. This is because such devices often switch back and form between wifi and cellular and switching between them might be slow because have to timeout and reestablish connections and often wireless networks have a fairly high latency.
• Another issue is that often security protocols such as TLS are run after connection establishment requiring additional handshakes to set-up connections.
• QUIC does both the connection and security in one RTT together speeding thing up.
• It uses a connection identifier that persists across changes in underlying network.
• It also supports multiplexing of several streams one a single transport connection to avoid the head-of-line blocking issue if multiple resources are needed for a web page.

Remote Procedure Call

• A common pattern used by client/server pairs is the request/reply message transaction: a client sends a request to the server, and the server responds with a reply message. While waiting for the reply, the client blocks.
• A transport protocol that supports this request/reply paradigm needs to be more than just send a UDP message in one direction followed by a UDP message in the other direction.
• It needs to correctly identify processes on the remote hosts and correlate requests and responses.
• We describe transport protocols for doing this under the heading of Remote Procedure Call (RPC).

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.

Java Remote Method Invocation

• Java Remote Method Invocation is a simplified mechanism for objects to communicate with each other over the web.
• It is a stripped-down version of a programming language non-specific protocol known as CORBA.
• The key participants in the RMI architecture are:
  • The Server: -- an object that provides services to objects residing on remote hosts
  • Service Contract: -- An interface that defines the services provided by the server
  • Client: -- an object that uses the services provided by the server
  • Stub: -- an object that resides on the same host as the client and serves as a proxy for the remote server
  • Skeleton: -- an object that resides on the same host as the server and serves as a proxy for the client.

Using RMI

• Get the rmi registry running on the server: rmiregistry&
• Define an interface for the remote object.

  public interface Contract extends Remote 
  {//Remote is in java.rmi 
  public void method1(...) throws 
  RemoteException; 
  //other methods 
  } 
  

• Implement the contract in some class on the server:

  public class ServiceProvider extends UnicastRemoteObject 
  implements Contract {/*code*/}
  

• ...

More Using RMI

• Create an instance of the server and register that server to the RMI registry:

  Contract server = new ServiceProvider(...); 
  Naming.rebind(name, server); 
  

• Generate the stub and skeleton classes, using the rmi compiler:

  rmic  ServiceProvider 
  

  This generates two files ServiceProvider_stub.class and ServiceProvider_Skel.class. The former should be on the client machine the latter on the server. These class files actually handle the communication over the internet.
• Develop a client that uses the services provided by the Contract interface:

  Remote remoteObj = Naming.lookup(name); 
   /*looking up rmi names is done with a URL like rmi://host:port/name where 
  name is the name of the service on the server */ 
  Contract serverObj = (Contract)remoteObj; 
  ...
  serverObj.method1(...);