A Study on UDP / TCP / PGM

1st Feb 2000

Contact: sales@atlasindia.com

Back

Questions to answer here:

• Multicast Applications necessarily use UDP rather than TCP. Why ? and what are the consequences ?
• PGM ("Pretty Good Multicast") is one proposal for building reliability into Multicast. How does it do so, and how does it stack up against other schemes for doing reliable Multicast.

To answer the first question let us look at the general properties of UDP and TCP.

It seems fairly obvious that UDP is a fairly "lenient" protocol as compared to TCP. So looking at the general properties of UDP, a hypothetical situation where the protocol would be preferred over TCP would be where the following characteristics hold true:

• Messages that require no acknowledgement
• Messages between hosts are sporadic or irregular
• Reliability is implemented at the process level.

In real terms this would be something like an online video broadcast where frame losses are pretty much tolerable. In other words this is pretty much what Multicast needs. A Multicast server would not have to be concerned about re-transmitting packets once they are sent out using UDP.

Other advantages of UDP are:

It provides Port Numbers to distinguish between different user requests and OPTIONALLY a capability to verify that the data ARRIVED intact.

1. UDP does not provide the service of dividing a message into packets Sequencing of packets that the data arrives in is also not provided. Therefore the application program that uses UDP is responsible for making sure that the sequencing and re-assembly of data packets is done right. So this is useful for networks that want to save on processing time. The Trivial File Transfer Protocol also uses UDP instead of TCP. So UDP fits into applications that have very small data units to exchange too.

Consequences of using UDP over TCP:

The increase in transmission speed to the lower amount amount of processing at the source network leads to lower reliability.

1. If the transmission protocol does not provide for reliability – the application most probably will have to.
2. While video in theory tolerates LOSS, for better picture quality more error compensating algorithms will have to be built into the software application. So the time saved at one end is bound to inversely affect the processing time at the receiving end.
3. The bottom line is that nothing is stopping a TCP/IP stack vendor from making his TCP processing faster than UDP.

In answer to the second question:

PGM satisfies most of the Multicast requirements. The keyword here is MOST.

• The source sends (in intervals) Source Path Messages to its broadcast recipients. This is useful when lost data is detected and the receiver can send a NAK to the nest upstream hop – the address which it would have received in the Source Path Message (SPM).
• On receiving a NAK the next upstream hop sends a Multicast NAK Confirmation to the receiver that sent it. This message also reaches all other receivers and they stop their NAKs.
• A receiver may volunteer to retransmit data for local recovery by responding to a normal NCF with one with a certain REDIRECTION option enabled. In this case the receiver becomes a Designated Local Retnsmitter and all subsequent NAKs are directed there.
• If this is not possible all NAKs are forwarded upstream all the way back to the source by each network element.
• After a NAK is received, the source or local receiver retransmits the lost data.

All of the above features enhance the reliability of receiving all the data sent out. In commercial terms this translates to easy adaptibility to PUSH applications say for example a live 24 hour stock prices broadcast. Now instead of sending a retransmit signal to the original broadcast source a closer recipient can be requested the same information.

Also it is important to note the CISCO has brought out PGM (TIBCO invented it). So it is ideal that the weight of CISCO (a router specialist) be behind a promising Protocol. PGM relies intensively on routers. Also there is a great demand for applications which require features supported by PGM.

How does PGM compare to other schemes for Reliable Multicast ?

There are over 30 different multicast schemes that have been proposed by various quarters. RMP (Reliable Multicast Protocol), RMTP ( Reliable Multicast Transport Protocol) and MFTP (Multicast File Transfer Protocol) are some of the more commonly accepted methods for implenting multicast.

As discussed earlier the MAIN difference is DLR (Designated Local Retransmitters).

Important Notes:

• None of the new multicast methods are actually standardized.
• PGM does not have CONGESTION control.
• Late Joining facility where the source can specifiy whether or not data can be retransmitted to receivers when they initially join the session is supported by PGM..
• PGM does not support Group Management. The advantage of which is that PGM can scale easily.
• The name "PRETTY GOOD MULTICAST" is subject to change to "PRAGMATIC GENERAL MULTICAST" because "PRETTY GOOD" is a Registered Trademark.

Sources Used for this Report:

• Adding Pretty Good Reliability to IP Multicast By Eamonn Sullivan
• PC WEEK
• Reliable IP Multicast – PGM Overview
• A Stardust Forums State of the Art Report
• UDP-TCP Presentations
• A Comparison of IP, UDP and TCP.
• The IP Multicast Initiative http://www.ipmulticast.com