Subject: RE: [AVT] eCRTP - does it work well over wireless links?

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 13 Aug 2002 14:56:03 +0200

Chris,

As indicated by Dan's mail, the main motivation for developing an 
enhanced CRTP version (ECRTP) was compression over tunnels, where
long RTT's and losses makes CRTP performance non-optimal. ECRTP
has thus been created to solve the problems encountered when doing
tunneling of compressed RTP, see <draft-ietf-avt-tcrtp-06.txt>.
Although ECRTP is a different scheme than CRTP, it was built with
minimal changes and fixes to CRTP, to simplify implementation.

ROHC RTP on the other hand was developed with wireless networks as
the main target, and was built from scratch as a new scheme
utilizing new compression methods and addressing an extensive list
of well-documented requirements (RFC 3096).

Although the targets were different for the two schemes, 
there is of course a significant overlap in applicability, and
ECRTP might potentially be a useful alternative in other scenarios
than tunneling. Regarding your question about applicability over
wireless links, it is important to note that there is a wide range
of different wireless links imposing different requirements on a
header compression scheme, and one will have to consider the
differences in how the schemes can meet the requirements for each
specific case. When talking about cellular links, compression 
efficiency is for example an important aspect.

One could say that ECRTP adds three components to CRTP:
1) An enhanced COMPRESSED_UDP packet with better flexibility and
   the ability to convey absolute values for some fields.
2) The added "header checksum", which makes the Twice algorithm
   applicable also when the UDP checksum is disabled (IPv4 only). 
3) A description of how to achieve a more robust CRTP operation
   by making use of 1) and 2) above. This section also fixes
   a minor CRTP error when using the Twice algorithm, which
   might validate incorrect IP-ID values if not implemented
   properly.

Both 1) and 2) have been added to provide robustness, and the
major robustness problems are indeed resolved with proper
implementation of these mechanisms (which to some extent are
similar to mechanisms used in ROHC RTP). However, the price of
using these is additional overhead. ECRTP still uses delta
coding, compared to the LSB coding used by ROHC RTP, which is
a less efficient method for achieving the same degree of
robustness. To convey changes, more bits are thus needed when
extending the compressed headers, which are then repeated 
according to the N-scheme. Further, it is not possible to get
as small minimal compressed headers as with ROHC RTP. ROHC RTP
has a minimal compressed header size of one (1) octet, while
the minimal ECRTP compressed header size is four (4) octets.

To summarize and answer your questions: ECRTP was not designed
with wireless links as the major target, but primarily to 
address tunneling. ECRTP might be applicable also in other 
scenarios, but e.g. not if compression efficiency is a major
concern. 

Rgds,
/Lars-Erik

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: den 7 augusti 2002 21:22
> To: [email-masked]
> Subject: [AVT] eCRTP - does it work well over wireless links?
> 
> 
> Hello,
> 
> A question about enhanced compression of RTP (eCRTP).  Can 
> someone please summarize what are the primary improvements 
> over RFC 2508 (CRTP)?  Are those improvements added in order 
> to enable operation over wireless (e.g. cellular) radio 
> links, or is it just to correct some known problems with CRTP?
> 
> Any strong technical reasons why eCRTP should not be used 
> (compared to something like ROHC RTP)?  I seem to remember 
> that CRTP has some inefficiences when used over links with 
> delay and non-trivial packet loss characteristics (mostly 
> designed for wireline networks) so it implies that there 
> could be big changes needed to get it to work well over 
> wireless links.
>
> Rgds,
> Chris Clanton
> Nokia Research Center 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt