RE: [rohc] p for TS (and SN)

[zhigang.liu@nokia.com]

Hi Anton,

I understand that you only want to change the case of bits(SN) > 6. 
However, I'm not sure the additional p formula is necessary. 
It boils down to two questions:
1) How frequent the retransmission can happen, if it indeed happens?
2) What is the distribution of the negative jump of SN, TS? Besides, 
IP-ID in IPv4 should also be considered, since it's compressed as 
offset to SN.

I've given some analysis on the two questions (see below). 
It looks to me that the retransmission should be rare anyway and 
current p formula is good enough to handle it (9 bits does tolerate
up to -15 SN jump). But I'm willing to see your analysis, since I may 
miss something here.

Furthermore, we should think about the behavior of the tuple 
(SN, TS, IP-ID in IPv4) during a retransmission. It's not only
about changing the negative coverage of SN. I did some mind exercise
using different packet formats (different modes and different IP version). 
For example, UO mode in IPv4, we need at least to send UO-1-ID with
extension 1, or with extension 3. The difference is only 1 byte while
the extension 3 can give 14 bits which virtually covers all the SN jumps.

Br,
Zhigang

 
> Zhigang and all,
> I don't want to change anything for 4 and 6 SN bits!
> The only thing I want to change is how we interpret
> the SN bits if we have more than 6 bits. We can only
> have more than 6 bits if we use extensions. With extension
> 0-2 we will have 9 SN bits and with extension 3 14 SN bits.
> If we use the definition in the current draft the interpretation
> of the bits is as follows:
> 
> 9 bits:   [-15, 496]
> 
> 14 bits:  [-511, 15872]
> 
> My proposal was to change the interpretation of the SN bits for
> 9 and 14 bits SN so we can handle retransmission of RTP packets
> without using the more "expensive" extension number 3. With the 
> new definition we will get:
> 
> 9 bits: [-127, 384]
> 
> 14 bits: [-4095, 12288]
> 
> I don't understand why it is so important to handle
> up to 496 packet losses with extension 0-2. I don't
> see a difference in performance between 496 and 384. 
> Give me an example where 384 is not enough while
> 496 had make it (it must be very rare)! Remember that 
> we are only talking about
> extensions. We will not reduce the "performance" for "ordinary"
> headers! 
> 
> With the new definiton we will be able to handle retransmission
> of RTP packets in a more effective way. We can save 2 bytes
> for every retransmitted packet while the robustness from my
> point of view is unchanged. 
> 
> BR,
> Anton
> 
> > -----Original Message-----
> > From: zhigang.liu@nokia.com [mailto:zhigang.liu@nokia.com]
> > Sent: Friday, October 13, 2000 9:36 PM
> > To: cabo@informatik.uni-bremen.de
> > Cc: krister.svanbro@lu.erisoft.se; khiem.le@nokia.com; 
> > rohc@cdt.luth.se
> > Subject: RE: [rohc] p for TS (and SN)
> > 
> > 
> > > zhigang liu writes:
> > > > Without knowing the nature of the RTP retransmission, it's
> > > > difficult to judge a solution, if it will ever be needed.
> > > > Can someone give us a pointer to the draft?
> > > 
> > > There are several drafts, generally being discussed in AVT.
> > > Try:
> > > 
> > > draft-ietf-avt-rtprx-00.txt
> > > draft-wenger-avt-rtcp-feedback-00.txt
> > > draft-friedman-avt-rtcp-report-extns-01.txt
> > > draft-fukunaga-low-delay-rtcp-00.txt
> > > 
> > > (I may have missed one.)
> > > 
> > > Gruesse, Carsten
> > 
> > Thanks, Carsten. I've found and read the first one. I'll read the
> > others. Here is my summary of the first one:
> > 
> > 1) The idea is to use RTCP receiver report to send NACK to 
> the sender,
> > asking for retransmission of a lost packet.
> > 2) Assuming 1 Kbytes RTP payload size and 40 bytes RTCP size, 
> > the NACK 
> > is allowed to be sent at every other packet interval, and 
> > still meets the 
> > limitation of 3.75% of total bandwidth (to avoid congestion).
> > 3) The receiver only sends NACK if the lost packet is still in the
> > the playback time window.
> > 
> > Regarding that draft, I think it's good enough to use extension 3
> > to handle the retransmission and not adding a new p formula.
> > 
> > a) The probability of the retransmission 
> > = packet loss rate * the lost packet in playback window
> > 
> > b) The above probability has an upper bound because of the RTCP
> > bandwidth limitation. The assumption of 2) is not true for voice.
> > Assuming 40 RTP payload size for voice, the NACK can only be sent
> > every 30 packet. On the other hand, if it's true (for video), then
> > the additional 2 bytes of extension 3 is not a big deal anyway.
> > 
> > I'll have to read the other drafts to see if the same is true.
> > 
> > Br,
> > Zhigang