Subject: [AVT] Re: avt digest, Vol 1 #392 - 1 msg

From: Somu Perianayagam <[email-masked]>
Date: Sat, 10 Aug 2002 13:46:38 -0700

[email-masked] wrote:

>Send avt mailing list submissions to
>	[email-masked]
>
>To subscribe or unsubscribe via the web, visit
>	https://www1.ietf.org/mailman/listinfo/avt
>or, via email, send a message with subject or body 'help' to
>	[email-masked]
>You can reach the person managing the list at
>	[email-masked]
>
>When replying, please edit your Subject line so it is more specific than
>"Re: Contents of avt digest..."
>
>
>Today's Topics:
>
>  1. RE: eCRTP - does it work well over wireless links? (Dan Wing)
>
>--__--__--
>
>Message: 1
>From: "Dan Wing" <[email-masked]>
>To: <[email-masked]>, <[email-masked]>
>Subject: RE: [AVT] eCRTP - does it work well over wireless links?
>Date: Fri, 9 Aug 2002 10:01:58 -0700
>charset="iso-8859-1"
>
>>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?
>>
>
>CRTP works link-by-link.  That is, CRTP works between two routers,
>and both routers are involved in the compression/decompression of
>the RTP/UDP/IP headers.
>
>ECRTP works end-to-end over some kind of tunneling protocol.  That 
>is, ECRTP works between two systems which do the compression, and 
>the ECRTP packets are tunneled over a network of multiple routers.  
>The multiple routers are not involved in the compression/decompression
>of the RTP/UDP/IP headers -- rather, only the two systems at the
>edges are involved in the compression/decompression.
>
Dan, I agree that the above was cited as an example in the draft. But I 
am pretty sure there
is nothing which stops ECRTP from being used on a hop by hop basis

>
>
>So, they have completely different design goals.  ECRTP doesn't
>replace CRTP, and CRTP doesn't replace ECRTP.  For example, CRTP
>expects the link to be relatively lossless; ECRTP expects the
>tunnel to be relatively lossy.  ECRTP sends occasional "key 
>frame"; CRTP doesn't.  CRTP allows the receiver to ask the
>sender to retransmit a frame that was lost; ECRTP doesn't (the
>round-trip expected for the expected use of ECRTP [over 
>multiple router hops] makes such a request meaningless for 
>realtime audio or video).  CRTP expects packets will never
>be misordered (because they never get out of order over a 
>link); ECRTP expects some packets to be misordered (because
>they could be misordered over an IP network).
>
This I agree too. :)  There is nothing such as "retransmission" in case 
of CRTP. Dan,
is probably talking about the header requests to get the context on 
compressor and
decompressor in sync. ECRTP also has the same but does have a lighter 
dependency
on it compared top CRTP.

>
>>Any strong technical reasons why eCRTP should not be used (compared 
>>to something like ROHC RTP)? 
>>
Sure yes. First and foremost if you are talking about cellular links, 
then ECRTP even with its repetitions
will do bad. ECRTP still depends upon header requests for its error 
recovery mechanism. But ROHC
can work in a unididrectional mode. One thing for sure is that since 
ECRTP is still a draft you probably
can tune it to adapt to cellular links and I am trying to look into that 
angle of ECRTP.

>
>Not to my eyes.
>
>>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.
>>
>
>That's correct regarding CRTP.
>
>Those "big changes" were done to ECRTP.  ECRTP may well be very applicable
>to wireless links, as their characteristics are similar to a high-loss
>and high-delay wired network.
>
"High loss": my guess would be better of not compressing :) I donot have 
the stats for this. But surely
can do the needful at the earliest.

Cheers
Somu

>
>-d
>
>>Have there been any testing/generation of results for eCRTP over 
>>wireless links?
>>
No. But we surely intend to have something like that done.

>>
>>Rgds,
>>Chris Clanton
>>Nokia Research Center 
>>
>>
>>_______________________________________________
>>Audio/Video Transport Working Group
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/avt
>>
>
>
>
>--__--__--
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt
>
>
>End of avt Digest
>

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

---

From: Tmima Koren <[email-masked]>
Date: Fri, 16 Aug 2002 18:25:18 -0700

At 01:46 PM 8/10/2002 -0700, Somu Perianayagam wrote:
>>>(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?
>>
>>ECRTP works end-to-end over some kind of tunneling protocol.  That is, 
>>ECRTP works between two systems which do the compression, and the ECRTP 
>>packets are tunneled over a network of multiple routers.
>Dan, I agree that the above was cited as an example in the draft. But I am 
>pretty sure there
>>tunnel to be relatively lossy.  ECRTP sends occasional "key frame"; CRTP 
>>doesn't.  CRTP allows the receiver to ask the
>>round-trip expected for the expected use of ECRTP [over multiple router 
>>hops] makes such a request meaningless for realtime audio or 
>>video).  CRTP expects packets will never
>>be misordered (because they never get out of order over a link); ECRTP 
>>expects some packets to be misordered (because
>This I agree too. :)  There is nothing such as "retransmission" in case of 
>CRTP. Dan,
>>>Any strong technical reasons why eCRTP should not be used (compared to 
>>>something like ROHC RTP)?
>Sure yes. First and foremost if you are talking about cellular links, then 
>ECRTP even with its repetitions
>can work in a unididrectional mode.

Periodic updates are also used in IPHC, CRTP (and ECRTP) for context 
refreshes, so these protocols can also be used on unidirectional links.
When a long loss occurs and a whole update sequence is lost, both ECRTP and 
ROHC are out of sync and rely on feedback from the decompressor, or wait 
for the next refresh
Regards,
Tmima

>  One thing for sure is that since ECRTP is still a draft you probably
>>>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.
>>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 16 Aug 2002 18:38:32 -0700

> refreshes, so these protocols can also be used on unidirectional links.

Yes, but this depends on the implementation and how it is configured.
Most cRTP implementations are used on full duplex links so there aren't
any refresh packets, and simply moving such a cRTP implementation onto
a simplex link (or a link with high delay) is prone to problems.  
(for anyone following along, this is discussed in section 2.1 of 
RFC2508).

> ROHC are out of sync and rely on feedback from the decompressor, or wait 

Good point.

-d