[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] p for TS (and SN)
Zhigang,
Yes, you're right that we also have to think about
the behavior of TS and IP-PD (IPv4). And I have to
admit that I first thougt that IP-ID was not a
problem. Since the retransmission is controlled by the
applications it is not clear how the IP-AD will change
during the wrap-around. At the "encoder" side the
application will have a "packet" buffer and if the
application receives a retransmission request the
application will take the packet from the buffer and
send it again. If this is the case the IP-ID will not
follow the SN! The IP-ID will increase and the SN take
a "big" negative jump => we need many IP-ID bits to handle
this. This results in that we will probably need the
flexibility in ext 3 to handle retransmission. I think that
the interpretation interval for 14 SN bits is good enough
[-511, 15872] so there is no need for a new p definition
to handle retransmission!
BR,
Anton
> -----Original Message-----
> From: zhigang.liu@nokia.com [mailto:zhigang.liu@nokia.com]
> Sent: Monday, October 16, 2000 11:15 PM
> To: rohc@cdt.luth.se
> Subject: RE: [rohc] p for TS (and SN)
>
>
> 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
>
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
>