Subject: Re: Extensions to CRTP

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Thu, 25 Nov 1999 09:01:07 +0100

>> = GVJ
>  = Tmima

>>Could you please explain, how IP id variance should be treated in this
case ?
>>For IP id field  first order difference is sent as delta in CUDP with I
bit set.
>>In this case, if there is a CU+ packet loss how IP ID delta encoding
should be treated ..

>Usually the IP id will not increment uniformly in packets of an RTP stream
(the host sends packets other >then the RTP streams, silence periods).
>This means that if we want to compress a stream, we might have to send a
new deltaID often, maybe in each >packet. This will increase the size of the
packets.
>To optimize the compression, the host can assign IP id's to the packets of
each stream in a constant >increment.
>This keeps the deltaID constant for each stream.

>The advantage of a CU+ packet is that in one packet we restore all
RTP-related parameters at the >decompressor.
>The sequence of:  CU followed by a CR+  is very vulnerable: the CU zeroes
the deltaT, so if the CR+ was lost, >the decompressor is out of sync.
>The CU+ does not restore the IP id. But if the implementation keeps the
deltaID constant..

Yes, IF the deltaID was constant. But you can never expect it to be.....so
the compression should handle non-constant deltaID's also (without too much
overhead).

>After a silence period, the sequence number will still increment by 1 and
the IP id by deltaID: there is no >reason to skip RTP sequence numbers or IP
id's. deltaT is the only difference that is not correct for the first
>packet after a silence period.

Yes, and therefore the additional overhead introduced by sending CU (or CU+)
packets seems to me indefensible. What you relly want is to send something
more than just ONE packet with a different deltaT and avoid the situation
below:
...
...
N+1: deltaT=10
N+2: deltaT=100
N+3: deltaT=10
N+4: deltaT=10
...
...
Because a loss of packet N+2 would NOT be recoverable with Twice. That is
the point? Right?? I think (even if I do not trust Twice to be reliable,
both due to the weak UDP checksum and to the fact that the checksum will not
always be present) it would be nice to have a better way to do this, but I
think it could be done cheaper than by sending full RTP header++...=)

>To optimize CRTP over lossy links
>1. Use a constant deltaID

Do not expect it to be constant. To do so, you either need to change the
IP-stacks OR you must violate the end-to-end integrity of the packets and
reassign the ID "somewhere" in the path.....=(

>2. Check udp checksum

The Twice idea makes some sence, BUT you should not expect the checksum to
be enabled. It is up to the application to decide whether to use it (and you
can not expect the application to know that it is needed for header
compression purposes).

>3. Use CU+ as necessary

Even if I am a little bit sceptical to some of your arguments, I still think
it is a good idea to improve the CU packet type and make it more flexible,
especially since there are "unused" bits in it.

Cheers!!
/Lars-Erik

--------------------------------------------------------------
Lars-Erik Jonsson, M.Sc.
Voice Processing and Radio Network Research
Ericsson Erisoft AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]
Phone: +46 920 20 21 07
Mobile: +46 70 365 20 58
Fax: +46 920 20 20 99
Home: +46 920 999 57

---

From: Mikael Degermark <[email-masked]>
Date: Thu, 25 Nov 1999 11:35:36 +0100

I also think it is a good idea to make CRTP more robust.

We cannot, however, expect that it can be made good enough
for the more severe cases (e.g., cellular) unless rather radical 
modifications are done. The place to ponder such modifications
is the robhc WG, which will be announced shortly. 

Micke Degermark