Subject: Comparison between TCRTP and GeRM

From: Tmima Koren <[email-masked]>
Date: Mon, 09 Aug 1999 13:41:35 -0700

In 'Draft AVT meeting minutes' there is a request for opinions about GeRM as an
RTP multiplexing scheme

TCRTP was presented in Oslo as an alternative scheme for multiplexing RTP
streams 

Here is a comparison between the two schemes:

Comparison between  TCRTP and GERM
TCRTP: draft-wing-avt-tcrtp-00.txt
GERM: draft-ietf-avt-germ-00.txt

GERM and TCRTP are two schemes that are trying to solve the same problem:
reducing header overhead in RTP streams. Both schemes achieve this by
compressing RTP headers and , when possible, multiplexing RTP streams into one
IP packet. Both GERM and TCRTP are end-to-end protocols.

Advantages of TCRTP over GERM
1.      With TCRTP, destination hostid/port# is preserved  
·       The CRTP compression (RFC2508) assigns a Context ID (CID) to each
compressed RTP stream. The CID is associated to 5 parameters of the RTP stream:
source hostid + port#, destination hostid + port# and SSRC. This association
works very well in multiplexing CRTP streams because the demultiplexor can
easily restore the destination port# from the CID and deliver the packet to the
appropriate application.  
2.      With TCRTP, parameters of RTP streams don’t need to be related  
·       The parameters of RTP streams (SSRC, Timestamp, Sequence number) are not
related. TCRTP does not require any relation between the multiplexed streams’
parameters and not any sampling coordination. 
·       In TCRTP packets from streams can be multiplexed in any order. In GERM
you should multiplex by SSRC ascending order. 
3.      With TCRTP, bandwidth is saved even when only one stream is multiplexed.
·       With GERM we lose bandwidth when only one stream is multiplexed. 
·       Headers size for one multiplexed packet:  
·       TCRTP: 24 (40 when not multiplexed) 
·       GERM: 43 (40 when not multiplexed) 
4.      With TCRTP, gateways can multiplex streams from Multiple
sources/destinations  
·       As shown in the TCRTP presentation, when two gateways multiplex RTP
streams, we map the CID to the ORIGINAL sender/receiver hosts/ports. This
allows the gateways to multiplex any stream from any source to any destination
in one packet. The demultiplexing gateway restores the real destination from
the CID and can forward the packet to its destination. This cannot be done with
any of the other suggested multiplexing schemes. 
5.      With TCRTP, multiplexing is not restricted to RTP streams  
·       Similar to CRTP (RFC2508), TCRTP allows any UDP stream to be compressed
and multiplexed: for non-RTP streams we use only COMPRESSED_UDP type packets. 
·       GERM is defined only for RTP streams 
6.      Comparing the size of multiplexed TCRTP and GERM packets.  
·       In the GERM draft, section 3.2 there is an example of a multiplexed
packet. This example is one of the most favorable cases for the GERM
multiplexing where all the timestamps and SSRC’s are fully coordinated, the
payload types are identical and the payload lengths are equal. In this example
6 streams are multiplexed. The header overhead is: 60 bytes 
·       When multiplexing 6 streams using TCRTP the header overhead is 44 bytes
(20+6x4), and there is no need to assume any relation between the streams 
Advantages of GERM over TCRTP
1.      In GERM, each multiplexed packet is compressed within itself. A lost
packet cannot affect the decompression of other packets. In TCRTP a lost packet
may affect the decompression of subsequent packets.
            ·   To correct this effect of lost packets in TCRTP, packets of type
CX are sent when necessary 

TCRTP presentation:
ftp://ftp-eng.cisco.com/tmima/tcrtp.ppt