Outline

• Finish RPC
  • Sun-RPC
  • DCE-RPE
  • gRPC
• In-Class Exercise
• RTP

Introduction

• On Monday, we were considering alternative transport layer protocols beyond TCP and UDP.
• We gave a couple of ways to partition protocols between processes on different host (i.e., transport protocols): By whether they were stream-oriented or message-oriented and by whether they insisted on reliable delivery or not.
• We might relax reliable delivery by allowing the occasional dropped segment or by allowing data to be sent out of order and still be processed as received.
• We gave two protocols that allowed for out of order processing of segments: SCTP and QUIC.
• We then started talking about remote procedure call (RPC), a family of message-oriented protocols.
• We went over Java's old Remote Method Invocation library as one example of such a protocol.
• We begin today by looking at three other examples: SunRPC, DCE-RPC, and gRPC before we begin talking about RTP, the real-time transport protocol, a protocol that could be used for video, audio streaming and one in which we might allow for the occasionally lost segment.
• Before beginning I'd just like to mention that often when people come up with new transport protocols to get them up and running quickly they implement them on top of UDP.

SunRPC

• SunRPC is a protocol originally developed at Sun Microsystems in 1984 as part of it NFS (Network Filesystem) distributed filesystem.
• It was later adopted as an IETF standard internet protocol under the name ONC RPC (Open Network Computing RPC).
• SunRPC can be implemented over different transport layer protocols. The left diagram above shows the usual protocol stack if it is implemented over UDP.
• In SunRPC, remote procedures are identified using a 32bit program number, a 32 bit version number for the procedure (we'll ignore/assume always same value), and a 32 bit procedure number.
• For example, NFS has the program number 0x00100003, and for NFS, getattr is procedure 1, setattr is procedure 2, read is procedure 6, write is procedure 8, etc.
• These values are transmitted as part of a SunRPC request message header. The right diagram above shows what this header looks like.
• Different program numbers may belong to different servers on the same machine. These servers may be on different UDP ports, most of which are not well-known numbers but instead are assigned dynamically.
• These demux keys (ports) are called transport selectors.
• A program called the Port Mapper (later renamed as RPCBIND and extended to work for other underlying transport protocols) with program number x00100000 on the port 111 is used to tell a client on which point a given procedure has a server running. You can think of this port mapper as like the rmiresgistry service we discussed for Java RMI.
• When a SunRPC server starts, it calls an RPCBIND registration procedure on the server's home machine to register its transport selector and the program numbers that it supports.
• A remote client can then call an RPCBIND lookup procedure to look up the transport selector for a particular program number.

SunRPC Example

• Suppose we want to send an NFS read request.
  • As a client, we'd first send a request to the Port Mapper on port 111 asking that procedure 3 be invoked to map program number x00100003 to the UDP port where NFS resides.
  • The Port Mapper would return the UDP port for NFS from its table.
  • The client caches this value so it can now use it for multiple requests without needing to use the Port Mapper to look up NFS again.
  • The client then sends a SunRPC request message with program number x00100003 and procedure 6 to this port.
  • The SunRPC module listening at that port calls the NFS read procedure.
  • To match a reply with the corresponding request so that the result goes to the correct caller, both request and response include an XID (transaction ID) field. The XID is supposed to be unique and used for one request and reply only. The server does not remember the XID between requests.

More on SunRPC

• SunRPCs semantics does not depend on the underlying transport protocol.
• It does not implement its own reliability, so it is reliable only if the underlying transport is reliable.
• Any protocol over SunRPC, though, could implements its own reliability system.
• SunRPC also does not implement mechanisms to support messages that are larger than the network MTU, so the ability to do this falls to the transport layer it is implemented over.
• The Credentials and Verifier fields in the SunRPC header are used by the client to authenticate itself to the server -- that is to give evidence that the client has the right to invoke the server.
• How a client authenticates itself to a server is a general issue that must be addressed by any protocol that wants to provide a reasonable level of security.

DCE-RPC

• DCE-RPC is the RPC protocol at the core of the DCE (Distributed Computing Environment) system.
• DCE-RPC was commisioned by the Open Software Foundation in a "Request for Technology" (1993 David Chappell).
• One of the key contributors to its development was Apollo Computers (absorbed by HP).
• It was the basis of the RPC mechanism underlying Microsoft's DCOM and ActiveX.
• It can be used with the Network Data Representation (NDR) stub compiler, but it also serves as the underlying RPC protocol for Common Object Request Broker Architecture (CORBA) (remember Java RMI is a simplified version of this).

DCE-RPC Details

• Like SunRPC, DCE-RPC can be implemented over several transport protocols like UDP or TCP.
• It uses a two level addressing scheme: the transport protocol demuxes to the correct server, and DCE-RPC dispatches to a particular procedure exported by that server.
• Clients consult an "endpoint mapping service" (like a port mapper) to learn how to reach a particular server.
• Unlike SunRPC, DCE-RPC supports "at-most-once" call semantics (i.e., a message sent to a server is sent at most once -- not accidentally retransmitted).

DCE-RPC Message Exchange Timeline

• The image above shows a typical timeline of messages in DCE-RPC:
  • The client sends a Request.
  • The server does not acknowledge the Request, the client instead periodically sends Ping messages to the server asking the server if it is still working on the Request.
  • The server responds to Ping messages with Working messages to indicate that the remote procedure is still in progress.
  • The server eventually replies with a Response.
  • The client Acknowledges (Ack) the Response.
• To abort a Request the client can send a Quit message to which the server can respond with a Quack (quit acknowledgement).
• If the server didn't get the request mentioned in a Ping, it can respond with a Nocall message.

More on DCE-RPC

• Each request/reply transaction takes place in the context of an activity.
• An activity is a logical request/reply channel between a pair of participants.
• An activity only allows one ongoing transaction at a time.
• An application program has to open multiple channels if it wants more than one request/reply transaction at a time.
• The activity to which a message belongs is specified by it ActivityId field.
• A SequenceNum field is used to distinguish between calls made as part of the same activity.
• Unlike SunRPC (with its XID field), DCE-RPC keeps track of the last sequence number used as part of a particular activity so as to ensure at-most once semantics.
• Unlike SunRPC, DCE-RPC supports fragmentation and reasssembly in the RPC protocol. This is done using a FragmentNum field.
• (Fack) are used to acknowldge these for long messages. DCE-RPC also supports SelAck and SelAckLen fields to do selective acknowledgements.

gRPC

• gRPC is an RPC framework which has been under development at Google since 2001 (originally under the name Stubby).
• It is designed for cloud microservices rather than for a simpler client/server paradigm.
• In the client/server setting we imagine the client contacts a specific server running a specific process to handle the request.
• In the cloud setting, the client invokes a method on a service, which, in order to support arbitrarily many clients at the same time, is implemented by a scalable number of server processes, each potentially running on a different machine.
• The number of server processes depends on the workload. Often the cloud service doesn't actually create a new process, it launches a new container. A container is a process encapsulated in an isolated envrionment that includes all the software packages the process needs to run. I.e., something like Docker.
• When a caller identifies the process it want to run, a load balancer directs that invocation to one of many available server processes that implement that service.
• gRPC runs over HTTP/2 or HTTP/3. I.e., either HTTP messages with compression (as HTTP 2 not 1) + TLS (for security) +TCP or HTTP messages w/compression + QUIC (security and reliable delivery).
• To make a request in gRPC, an HTTP POST message is used and the message identifies the program and procedure as part of the path. The data in the message specifies the procedure arguments.

gRPC Request/Reply Patterns

gRPC supports different RPC mechanisms which to different degrees can incorporate streaming.

1. Simple RPC: The client sends a single request message and the server responds with a single reply message.
2. Server Streaming RPC: The client sends a single request message and the server responds with a stream of reply messages. The client completes once it has all the server's responses.
3. Client Streaming RPC: The client sends a stream of requests to the server, and the server sends back a single response, typically (but not necessarily), after it has received all the client's requests.
4. Directional Streaming RPC: This initiated by the client, but after that, the client and server can read and write requests and responses in any order; the stream are completely independent.

Example gRPC Request Response Messages

• Notice in the request the HTTP path identifies the service and the method. This is similar to what is usually done also with REST web services.
• The DATA in the request would then specify the arguments to the particular method called.
• In the reply, the line: content-type:application/grpc-proto, tells the client that the bits in the message can be interpreted according to the Protocol Buffer interface specification.

In-Class Exercise

• Imagine you were trying to come up with a gRPC service for Weather reports. What might be some possible message paths from the client you might support?
• What possible values for DATA might be sent from the client?
• Please post your solutions to the Apr 12 In-Class Exercise Thread.

Transport Protocols for Real-Time Applications

• An application is called real-time if it has a strong requirement for the timely delivery of information.
• For example, Voice over IP, video, audio conferencing, etc. are real-time applications.
• Streaming applications such as internet radio or YouTube, lack human-to-human interaction, and so often place less stringent requirements on the underlying protocols.
• Nevertheless, they share enough commonalities with real-time applications to warrant common protocols for both types of applications.
• One protocol for doing this is called RTP which derived many of its features from the vat application (a videoconferencing tool).
• RTP can run over many lower-layer protocols but commonly runs over UDP.

Requirements of Real-Time Applications

• The most basic requirement for a general-purpose multimedia protocol is to allow similar applications to interoperate with each other.
• For example, two independently implemented audio-conferencing tools should be able to interoperate.
• To handle this the protocol should provide a means to negotiate the kind of compression, encoding, etc of the audio data being sent. (Similarly, the codec if video conferencing was being done).
• Another important requirement for RTP is to enable the recipient of stream data to determine the timing relationship among the received data.
• The received data needs to be placed into a playback buffer to smooth things out like jitter.
• If a conference is being done, then synchronization of several streams needs to be done. Also, for video one needs to probably synchronize separate audio and video streams.
• The application must also be able to handle packet loss in a reasonable manner.
• RTP needs to be able to handle framing. For instance, know when data that has arrived constitutes a displayable unit.
• Finally, RTP needs to have some way of naming senders and receivers that is more friendly than IP addresses.

RTP Details

• RTP was developed at the IETF and was first published in 1996.
• It is commonly used to do VoIP and Video-teleconferencing.
• It is actually a pair of protocols: RTP and the Real-time Transport Control Protocol (RTCP)
• For each application (audio, video, etc) which makes use of RTP, a profile and one or more formats are defined.
• The profile provides a range of information used to ensure a common understanding of the fields in the RTP header for that application class.
• The format specification explains how the data that follows the RTP header is to be interpreted.
• For instance, for audio the format might say that each byte that follows is a sequence of sound samples.
• This use of profiles and formats is an example of application level framing.

Header Format

• The first 12 bytes of the header are always present, CSRCs and extensions may or may not be present
• The first two bits are a version identifier which is currently version 2.
• P is a "padding" bit which is set if the RTP payload needed to be padded to some size, for instance, because of the requirements of an encryption algorithm.
• The extension bit X is used to indicate the presence of an extension header; the 4 bit CC field is used to indicate the number of CSRCs.
• M is used for framing.
• PT is a 7 bit field that indicates the payload type. Using it an application could switch from one kind of coding scheme to a different one.
• The sequence number is used to detect missing or mis-ordered packets. RTP does not do anything when it detects a packet loss (the app decides what to do).
• The timestamp is used to enable playback from different portions of the stream and to synchronize tracks if more than one stream is in use (say audio and video).
• Timestamps represent the time at which the first sample in the packet was generated.
• The synchronizing source (SSRC) is a 32-bit number that uniquely identifies a single source of an RTP stream. In a multimedia conference each sender picks a random SSRC and is expected to resolve conflicts in case of a collision.
• The contributing source (CSRC) is only used when the RTP streams pass through a "mixer" of serveral other sources. In which case the mixer will be the SSRC and the other contributers are listed in the CSRC.

Control Protocol

• RTCP provides three main functions
  • Feedback on the performance of the application and the network
  • A way to correlate and synchronize different media streams that have come from the same sender.
  • A way to convey the identify of a sender for display on a user interface.
• The first function may be useful for rate-adaptive applications.
• The second function entails both being able to follow the name of a stream if its SSRC has to change because of a collision (using CNAMEs), and also synchronizing the clocks of different media that may be involved in the communication.

RTCP Packet Types

• RTCP supports four kinds of packets:
  1. Sender reports, which enable active senders to a session to report transmission and reception statistics.
  2. Receiver reports, which receivers who are not senders use to report reception statistics.
  3. Source descriptions, which carry CNAMEs and other sender description information
  4. Application-specific control packets.
• These packets are typically sent over UDP.
• RTCP also has a mechanism to scale back the reporting frequency of participants as the number of participant increases. The intent here is to reduce the fraction of the total bandwidth consumed by reporting.
• Sender and receiver reports are similar. However, a typical sender report also has in it: a time of day of when the report was generated; an RTP timestamp of when the report was generated; and a cumulative count of the packets and bytes sent by this sender since it began transmission.

Sender/Receiver Reports

These contain (it should be noted that a sender might send to some other sender a report concerning the data received from it):

• One block of source data that has been heard since the last report.
• Its SSRC.
• Fraction of lost packets since last report.
• Total number of packets lost from this source since it was first heard from.
• Highest sequence number received.
• Estimated inter-arrival jitter for the source.
• Last actual timestamp received via RTCP for this source
• Delay since last sender report received via RTCP for this source.