Subject: Re: [AVT] Comments on draft-koren-avt-ecrtp-reorder-00.txt

From: Tmima Koren <[email-masked]>
Date: Tue, 01 Mar 2005 12:17:49 -0800

Hi Haipeng
Thanks for your comments
You're right, it might be clearer to say that the decompressor needs to 
remember the last RTP SN where IPID changed irregularly.
What I was trying to say is that I want to remember the last RTP SN where 
the IP ID always changes by delta IP ID from this packet to the next. Maybe 
I can say the effective delta IP ID does not change.
Then, as you said, to increase the ability of the decompressor to verify 
the IP ID the decompressor can remember more about the history of the IP ID 
changes.
Regards
Tmima

At 08:24 AM 2/17/2005 -0800, Haipeng Jin wrote:
>Hi,
>
>Here are some comments on this ID. It seems that remembering the last RTP 
>SN where delta IPID has changed may not be enough.
>
>For example, for a sequence of RTP packet with sequence number from 1 to 
>100. Suppose delta IPID changed on packet(1) to 1 and stays the same all 
>the time, however, IPID jumped  on packet(50) by 10, on packet(75) by 10, 
>as a result, packet(100) has IPID 120 (assume IPID is 1 for packet(1)).
>
>Now let's look at packet 101 ~ 104:
>101: IPID = 121, compressed_RTP,
>102: IPID = 130, CUDP, IPID = 130
>103: IPID = 131, CUDP, IPID = 131
>104: IPID = 132, CUDP, IPID = 132
>
>Now if  packet(103) is received before packet(101), the decompressor 
>context will have IPID = 131, delta IPID = 1, RTP SN = 103, last RTP SN 
>with delta IPID change = 1. When the decompressor receives packet(101),
>1) it cannot decompress IPID based on (SN =103, IPID = 131) because IPID 
>has jumped and the difference in RTP SN tells nothing.
>2) it cannot decompress IPID based on the knowledge that last RTP SN with 
>delta IPID change = 1, because there have been multiple IPID jumps between 
>packet(1) and packet(100) even though delta IPID doesn't change.
>To solve the above problem, the decompressor actually needs to remember 
>the last RTP SN where IPID changed irregularly.
>
>Another  example is
>101: IPID = 121, CRTP
>102: IPID =  131, CUDP, IPID = 131, delta IPID = 10
>103: IPID = 141, CUDP, IPID = 141, delta IPID = 10
>104: IPID = 151, CUDP, IPID = 151, delta IPID = 10
>
>If packet(103) is received before packet(101), the decompressor context 
>will have IPID = 141, delta IPID = 10, RTP SN = 103, last RTP SN with 
>delta IPID change = 103. Again, the decompressor will have trouble 
>decoding the late packet(101). One way to solve this problem is for the 
>decompressor to remember both the last and the  next to last RTP SNs where 
>IPID changed irregularly.
>
>
>To summarize,  the decompressor needs to remember the following info for 
>the last and the next to last packets where IPID changed irregularly: RTP 
>SN, delta IPID, and IPID.
>
>Regards,
>Haipeng
>
>At 12:59 PM 2/16/2005, Colin Perkins wrote:
>>Begin forwarded message:
>>>From: [email-masked]
>>>Date: 16 February 2005 15:14:15 GMT
>>>To: [email-masked]
>>>Subject: I-D ACTION:draft-koren-avt-ecrtp-reorder-00.txt
>>>Reply-To: [email-masked]
>>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>>
>>>
>>>         Title           : Packet reordering in Extended CRTP (ECRTP)
>>>         Author(s)       : T. Koren, P. Ruddy
>>>         Filename        : draft-koren-avt-ecrtp-reorder-00.txt
>>>         Pages           : 0
>>>         Date            : 2005-2-15
>>>
>>>Extended RTP Header Compression (ECRTP) is tolerant to packet
>>>    misordering. This document describes how ECRTP validates packets
>>>    that arrive out of order.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-koren-avt-ecrtp-reorder -00.txt
>>
>>
>>_______________________________________________
>>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

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

---

From: Tmima Koren <[email-masked]>
Date: Tue, 01 Mar 2005 13:53:51 -0800

Hi Lars-Erik
Thanks for your comments. We'll add more implementation guidelines in the 
next revision of the draft
Regards
Tmima

At 08:38 AM 2/18/2005 +0100, Lars-Erik Jonsson (LU/EAB) wrote:
>An other general comment on the draft:
>
>   The draft title should rather be "Validating the IP-ID field
>   value with eCRTP in case of packet reordering", as the draft
>   does not address any other aspects of how to make eCRTP work
>   in such scenarios. The current title can give the reader the
>   impression this is the only thing to consider when using
>   eCRTP over links that can reorder packets, which is for sure
>   not correct.
>
>   The ROHC document draft-ietf-rohc-over-reordering-02.txt makes
>   a detailed analysis of what to consider in case of link-level
>   reordering. If the authors of draft-koren-avt-ecrtp-reorder
>   want to provide good guidelines for implementers of eCRTP in
>   reordering scenarios, I would suggest looking at the ROHC
>   reordering draft for inspiration.
>
>
>For a study of eCRTP operation in reordering scenarios, please
>refer to the following document:
>http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf
>
>BR
>/L-E
>