Subject: T-bit extension for CRTP

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Tue, 23 Nov 1999 11:20:48 +0100

I have a number of comments both to what is said in the draft
(draft-koren-crtp-enhance-00.txt) and to the previous discussions about it.
All are included below:

- Draft: The purpose

Tmima: In the draft you state that you need this to be able to do periodic
refreshing of the context when CRTP is used over links with large RTT.
However, in the previous discussion you are only talking about what happens
after silence periods. I think you should clarify what you are really aiming
for, maybe the draft should also talk about the implications after silence
periods.

- Draft: Packet types for refreshing

In the draft it is stated that there are TWO packet types that can be used
to periodically refresh the context of an IPv4 CRTP decompressor,
FULL_HEADER and COMPRESSED_UDP packets. This is not really correct. For
IPv4, the COMPRESSED_UDP packet does NOT refresh the context completely,
because the IP-ID is communicated as a delta. The COMPRESSED_NON_TCP packet
type should instead be used with IPv4. For IPv6, the two packet
types(C_NON_TCP and C_UDP) carries the same information and are identical in
size.

- Discussion: GeeVarghese Q1

>Q1) My doubt is If the entire original RTP header is the in the CUDP packet
why to
>send the delta also with the original header ..
>why can't the decompressor findout the new delta to be used
>from the RTP header in the  CUDP packet itself, Is it not redundancy ?

The decompressor can NOT find out the delta for sure, because its context
could have been invalid when the C_UDP was received. So, if the intention is
to have the delta "correctly" set (not reset to 0) after a C_UDP, then you
must include it. The question is whether this is advantageous compared to
the current solution, sending the delta in subsequent C_RTP.

- Discussion: GeeVarghese about multiple packets

>Why do we need to send multiple packet  and how it will increase the
probability even
>if you send more CUDP packets, as long as the decomperssor look at the seq
number
>and detect  packet loss  it should send a CONTEXT_STATE packet.

Yes, but if the RTT is large, the update procedure would take a long time.
If Twice is used (requires UDP checksum and should be used carefully), loss
of packets that DO NOT change the decompressor context could be handled
without discarding additional packets. On the other hand, if packets that DO
change the context are lost, Twice would fail and subsequent packets must be
discarded while waiting for a refresh. If context update information was
repeated in more then one packet, a higher tolerance against packet loss
could be achieved.

- Discussion: The example

>Some notations:
>dt         deltaT
>FH        FULL_HEADER
>CR       COMPRESSED_RTP
>CR+     COMPRESSED_RTP with deltaT (dt)
>CU       COMPRESSED_UDP
>CU+     COMPRESSED_UDP with dt
>CS       CONTEXT_STATE

>I'll use an example
>The sender sends a sample every 10 ms
>Using CRTP, the sequence of packets will be:

>seq#   Time     pkt type
>1        10         FH
>2        20         CR+    dt=10
>3        30         CR
>...
>10      100       CR

>At this point this side stops talking. Talking resumes at time 200

>11      200       CR+    dt=100
>12      210       CR+    dt=10
>13      220       CR
>....

>With the extension of T-bit in CU, we can send:

>11'     200       CU+    dt=10
>12'     210       CR
>...

When I look at the two different solutions 11+12 and 11'+12' I can not
really see the big advantage of 11'+12'. First of all, the latter requires
more overhead. While 11 would have a 3 octet header, the 11' header would be
at least 15 octets large. The idea is certainly to have the context
completely refreshed, but that could not be achieved with CU+ because it
does not include the IP ID in absolute terms. IF you want to refresh the
context with a CU packet as packet #11, you could also still use the old CU
and send the dt-value in the next compressed packet, it would require one
octet less in the CU and one more in the CR(+). Also the dt information
could be repeated in more than one CR-packet for use with "sophisticated
Twice".

- Discussion: GeeVarghese about FH

>I think this is not correct, If the decompressor receives 12" insted of
11",
>he is not in sync because of link seq number mismatch and
>will send a CONTEXT_STATE packet.
>This will lead to FH sending from compressor to decompressor ..

Not necessarily a FULL_HEADER, a COMPRESSED_NON_TCP would be a better
choice.

- Discussion: GeeVarghese and Koren about CONTEXT_UPDATE

>>I think any of the CU+ loss will lead to CONTEXT_STATE packet generation
from
>>decompressor to compressor because of the link seq number mismatch ..Is nt
it ?

>The decompressor should be in sync after receiving a CU+. There is no
reason for a CS

As the CRTP RFC says: "Note, however, that there is a nontrivial risk of an
incorrect positive indication. It may be advisable to request a FULL_HEADER
or COMPRESSED_NON_TCP packet even if the "twice" algorithm succeeds." The
UDP checksum is rather weak, so especially if you use more complex "twice"
solutions, the advice above should be followed, meaning that a CONTEXT_STATE
packet should be sent.

Regards!!
/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: Tmima Koren <[email-masked]>
Date: Wed, 24 Nov 1999 16:01:49 -0800

>for, maybe the draft should also talk about the implications after silence

Thanks, I'll clarify this point.
The idea is that once the deltas are set at the decompressor and you are sending CR packets, if you lose packets you can recover using 'twice'.
But if you try to change a delta by sending a CR+ or CU, and if this packet is lost, the decompressor cannot recover using 'twice'.
A silence period is just an example of a time when you need to change the deltaT. 

>types(C_NON_TCP and C_UDP) carries the same information and are identical in

You are right - I'll correct this
A FH does not refresh the context: it starts a new context
And a CU+ restores all RTP-related parameters at the decompressor. The IP id is not restored.

I checked the COMPRESSED_NON_TCP packet and I can't use it to fully refresh the state at the decompressor: it will set the deltaT to zero.

I think I'll propose an additional change to the CU packet:

In a CU packet the M and S bits are always 0.
I propose that if the M bit is set instead of the I bit, then the packet carries the full IP id and not only the delta IP id.

Tmima