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

[Anton Mårtensson (ERA) <anton.martensson@era.ericsson.se>]

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
> 
> 
> 1) The receiver only sends it 
> 
> 
>  and will go over
> the others.  
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
>