Subject: Re: Extensions to CRTP

From: Tmima Koren <[email-masked]>
Date: Thu, 18 Nov 1999 09:54:22 -0800

At 02:13 PM 11/18/99 -0500, you wrote: 
>
> Steve, Tmima  & all, 
>
> This is regarding the ietf draft - Extensions to CRTP  :
> draft-koren-avt-crtp-enhance-00.txt 
> I have few doubts and could you please clarrify these points .. 
>
> In the section 1. COMPRESSED_UDP packet "T bit" .. 
>
> It is stated that CUDP packet reset the deltaT value to 0 and 
> therefore T bit avoids the need to send deltaT in the next CRTP. 
>
> 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 ? 
>
> Also You have stated that 
>
> >> Multiple COMPRESSED_UDP packets may be sent by the compressor when changes
> in the 
> >> compressor state need to be synchronized. Sending multiple packets will
> increase the 
> >> probability of delivery of the synchronized state in the event of packet
> loss. 
>
> 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. 
>
> If the draft reference you made was for loss of more than 16 packets from the
> same flow, 
> and the possible wrong decompression of headers .. 
> twice algorithm should detect this (But twice algo is not used if checksum is
> 0) 
> So here what exactly the limit could be , the sequence number space 1..16 
> Since this draft address the use of this algo over ATM/AAL5 links  I think 
> sequence number space 1..16 may not be sufficient. 
>  

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
...

We are trying to adopt CRTP to links that have some loss of packets and a long
round trip time (RT) 
We want to avoid the decompressor getting out of sync and having to send CS
because this will cause loss of many packets for this stream due to the long
RT.

Let's check what happens if some packets are lost
1. packet 4 was lost
    The decompressor will use the 'twice' and will stay in sync
2. packet 11 was lost
    The decompressor is out of sync
3. packet 11'  was lost
    The decompressor is out of sync

We see that there is a weak point in the compression at the beginning of a talk
spurt
We try to correct this by sending multiple CU+ 

11"    200       CU+    dt=10
12"    210       CU+    dt=10 
13"    220       CR
...

If the decompressor received any of 11"  or 12" ,  he is still in sync

How many CU+ do we want to send at the beginning of a talk spurt?
This depends on the quality of the link (which is good but not perfect).
If we know that on this link we may lose at most 2 packets in a row, we'll send
3 CU+ at the beginning of a talk spurt
The decompressor will stay in sync as long as he received at least one of the
CU+  

>
>  
>
> Q2) Can you explain the use of  "The NON-RTP stream flag" for this algorithm 

The compressor knows that this stream is a non-RTP stream, but he still wants
to compress the stream. The compressor will have to use CU only. If the
compressor can pass a hint to the decompressor that this is not an RTP stream,
the decompressor will save only the IP and UDP headers for this context, and
will not save the extra context of the RTP header (that does not exist here)
and will not try to calculate the deltas and other RTP-related calculations

>
> Q3) Section III : Acknowledgement to a new compressed stream 
>
> Context Invalidation was one point which I had pointed out to Steve/tmima
> long time back .. 
> I am having those mails with me .. 
>
> But, (i) Do we need ACCEPT and REJECT packet  ?? 
> Having a NACK mechnism sounds reasonable .. 
> I feel there shouldnt be both .. 
> But what compressor is supposed to do after sending the first FULL_HEADER
> packet 
> when compressor waiting for the ACCEPT or REJECT 
> should it queue the packets till the reply/or timeout 
> or Should it send the compressed packets assuming the decompressor will drop
> if there are 
> REJECT state at the decompressor side. 
>
> But (ii) what about the backword compatibility issue because this
> ACCEPT/REJECT mechanism has dependancy and it will not work with CRTP-2508 
>
> As per the current proposal we need to send ACCEPT/REJECT packet for every 
> FULL_HEADER packet ... (iii)Is it not adding extra bandwidth consuption .. 
> Draft talks about FULL_HEADER retransmit as well .. 

The REJECT packet is useful when the decompressor runs out of resources. The
compressor initiates compression of a stream by sending a FH. With CRTP today
the decompressor can send a CS to invalidate the context, but the compressor
does not know the reason and will attempt to compress this stream again. A
REJECT will notify the compressor that the decompressor cannot handle
compresstion of additional streams at this moment.
An implementation that was not enhanced to use REJECT will still use CS to
invalidate the context each time the compressor attempts to compress the
stream.
The compressor continues to send the compressed packets of the stream until he
receives CS or REJECT
The intent is to make the ACCEPT/REJECT packet optional - an optimization.

Tmima

>
> More questions after discussing these points .. 
> Please answer the questions ................... 
>   
>
> Regards 
>
> GVJ 
>   
>
> --
> --------------------------------------------------------------------------- 
> Geevarghese John,   DataCom Group, 
> Motorola India Electronics Ltd, 
> "The Senate", No-33 A, 
> Ulsoor Road, 
> Bangalore - 42. 
> Phone  : 91-80-5598615  Xnt-4005 
> E-mail : [email-masked] 
> --------------------------------------------------------------------------
> ----- 
> --------------------------------------------------------------------------
> ----- 
>

---

From: GeeVarghese John <[email-masked]>
Date: Fri, 19 Nov 1999 12:17:09 -0500

Hi,

My comments to you answers are added below  ..
Please have a look at that  //

Tmima Koren wrote:

>> Q1) My doubt is If the entire original RTP header is the in the CUDP
>> packet why to
>> >> Multiple COMPRESSED_UDP packets may be sent by the compressor
>> when changes in the
>> >> compressor state need to be synchronized. Sending multiple
>> packets will increase the
>> >> probability of delivery of the synchronized state in the event of
>> packet loss.
>>
>> if you send more CUDP packets, as long as the decomperssor look at
>> the seq number
>> If the draft reference you made was for loss of more than 16 packets
>> from the same flow,
>> twice algorithm should detect this (But twice algo is not used if
>> checksum is 0)
> We are trying to adopt CRTP to links that have some loss of packets
> and a long round trip time (RT)
> We want to avoid the decompressor getting out of sync and having to
> send CS because this will cause loss of many packets for this stream
> due to the long RT.
>
> We see that there is a weak point in the compression at the beginning
> of a talk spurt

Here, I think you assumed that 12"  packet will reach the compessor with

timestamp 210. But, unfortunately if it was lost what you get is 13" and
time stamp 220.
In that case again you have send dt again with your CU+ after sending
CU+ with dt 10.
In this type of situation processing due to delta encoding was double
and you send two
delta encoded bytes in two different packets insteadof one
You might have assumed that MOST of  the case packet loss doesnot happen
..
But I feel that is also purely dependant on the network where this
algorithm is executing ..

> If the decompressor received any of 11"  or 12" ,  he is still in sync

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 ..

> If we know that on this link we may lose at most 2 packets in a row,
> we'll send 3 CU+ at the beginning of a talk spurt

Looks OK, but How do we decide on the number of packet loss ?
Packet loss can be due to link quality and/or network congestion etc ..
If the loss was due network congestion or similar factor, behaviour vary
from time to time ..
So here also CU+ is giving disadvantage instead of the benifits
expected.

>
> The decompressor will stay in sync as long as he received at least one
> of the CU+

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 ?

I will include rest of the questions in another mail ..
Please reply back ..

Rgds
GVJ

---

From: GeeVarghese John <[email-masked]>
Date: Fri, 19 Nov 1999 12:51:02 -0500

Sorry, Please neglect my previous mail, this is the correct mail ..
I pasted my answers at the wrong place which might confuse those who
read ..

GVJ

GeeVarghese John wrote:

>> > Q1) My doubt is If the entire original RTP header is the in the
>> > CUDP packet why to
>> > >> probability of delivery of the synchronized state in the event
>> > of packet loss.
>> >
>> > Why do we need to send multiple packet  and how it will increase
>> > the probability even
>> > If the draft reference you made was for loss of more than 16
>> > packets from the same flow,
Here, I think you assumed that 12'  packet will reach the compessor with

timestamp 210. But, unfortunately if it was lost what you get is 13' and
time stamp 220.

And also are you not loosing the bandwidth saving by sending CU+ instead
of CR
because  you send the complete RTP hdr + delta encoded deltaT byte in
CU+.

>> We see that there is a weak point in the compression at the
>> beginning of a talk spurt

>>
>> The decompressor will stay in sync as long as he received at least
>> one of the CU+
>

---

From: Tmima Koren <[email-masked]>
Date: Mon, 22 Nov 1999 10:48:17 -0800

At 12:51 PM 11/19/99 -0500, GeeVarghese John wrote: 
> I pasted my answers at the wrong place which might confuse those who read .. 
>
> GVJ 
>
> GeeVarghese John wrote: 
>>
>> Hi, 
>>
>>>> >> Multiple COMPRESSED_UDP packets may be sent by the compressor when
>>>> changes in the 
>>>> If the draft reference you made was for loss of more than 16 packets from
>>>> the same flow, 
>>>> twice algorithm should detect this (But twice algo is not used if checksum
>>>> is 0) 
> timestamp 210. But, unfortunately if it was lost what you get is 13' and time
> stamp 220. 
> In that case again you have send dt again with your CU+ after sending CU+
> with dt 10. 
> In this type of situation processing due to delta encoding was double and you
> send two 
> You might have assumed that MOST of  the case packet loss doesnot happen .. 
> But I feel that is also purely dependant on the network where this algorithm
> is executing .. 
>
> And also are you not loosing the bandwidth saving by sending CU+ instead of
> CR 
> because  you send the complete RTP hdr + delta encoded deltaT byte in CU+. 
>   
>>
>>>
>>>   
>>> ... 
>>>
>>> We are trying to adopt CRTP to links that have some loss of packets and a
>>> long round trip time (RT) 
>>> because this will cause loss of many packets for this stream due to the
>>> long RT. 
>>>
>>> We see that there is a weak point in the compression at the beginning of a
>>> talk spurt 
> I think this is not correct, If the decompressor receives 12" insted of 11", 
>>> If we know that on this link we may lose at most 2 packets in a row, we'll
>>> send 3 CU+ at the beginning of a talk spurt
>>
>
> If the loss was due network congestion or similar factor, behaviour vary from
> time to time .. 
> So here also CU+ is giving disadvantage instead of the benifits expected. 
>>
>>>
>>>   
>>> The decompressor will stay in sync as long as he received at least one of
>>> the CU+
>>
>
> 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
Tmima

---

From: GeeVarghese John <[email-masked]>
Date: Tue, 23 Nov 1999 22:17:03 -0500

>> >>
>> >>  The decompressor will stay in sync as long as he received at
>> >>  least one of the CU+
>> >
>> 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
> Tmima

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 ..

and also I am not still convinced with the advantage of CU+ over CR+
after
the  silence period. Could you please explain your point  ..(please ref
my previous mail)

Please reply .

Rgds

GVJ

---

From: Tmima Koren <[email-masked]>
Date: Wed, 24 Nov 1999 15:19:29 -0800

At 10:17 PM 11/23/99 -0500, GeeVarghese John wrote: 
>>> decompressor to compressor because of the link seq number mismatch ..Is nt
>>> it ?
>>
>>
>>
> 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..

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.

To optimize CRTP over lossy links 
1. Use a constant deltaID
2. Check udp checksum
3. Use CU+ as necessary

>
> and also I am not still convinced with the advantage of CU+ over CR+ after 
> the  silence period. Could you please explain your point  ..(please ref my
> previous mail) 

Let's say that the characteristics of the link is that we may lose at most 1
packet in a row
If we use:

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

If 11 is lost, the decompressor does not have the correct RTP timestamp for
packet 12.
If 12 is lost, the decompressor has a wrong deltaT.
In both cases the decompressor is out of sync. 
This is a very weak sequence to use after a silence period.

If instead we use:

11"    200       CU+    dt=10 
12"    210       CU+    dt=10 
13"    220       CR

In this case If one of 11" or 12" is lost, the decompressor remains in sync. So
this is a very strong sequence

Tmima

---

From: GeeVarghese John <[email-masked]>
Date: Thu, 25 Nov 1999 18:25:50 -0500

Tmima,

Thanks for the reply and I have added some more comments on the CU+
packets in this
mail. I read the first mail from "Lars-Erik Jonsson", and your reply to
that, Good
you are changing the CU+ with IP ID but you may not need to set M bit
there,
by settting deltaT bit you can encode both deltaT and IP ID, because you
need both values...
I have added whatever comments I have about CU+,  please read that below

According to me CU+ with IP ID also will not give a robust solution.
Reason stated below.

I think we should windup our discussion on CU + with this mail unless
someone else is
interested. If you want to reply to me please ..If you want more
clarrification on my point
I will reply back.

My next mail will address few things about ACCEPT/REJECT
packet use, you & team proposed. Please reply to that mail.

My comments on CU+ are :

Point 1.1:

IP ID can be assigned by an host in three ways
a) sequence number in ascending order with variace 1
b) random number
c) sequence number with variance n (n >1)

I am not aware of any other implementation ..(May be possible)
IF the IP id variance is not in the ascending order,
CU+ will have problem. You expect that, host will implement this
while transmitting the RTP packets. I dont know how many (non compliant)
people
will change this for the new proposal came in "extending CRTP".
Or you are agreed for IP ID in CU+, it is a positive move.

Point # 1.2

Infact looking at the sequence number of CUDP packets helps to  get rid
of
IP id sync problem which we discussed .  (What I meant is if CUDP came
in with a
non expected link seqnumber, decompressor send out a CS packet to
compressor to synchronise the context)
This will take care all issues with the IP id variance (variance in any
manner random, ascending order).
If we extend CRTP with the new extension you proposed,
we may loose this synchronization chance between compressor and
decompressor,
because we are NOT expected to look at CUDP+ (or CU+) link sequence
number
to synchronize anymore as far as IP ID variance is concerned.
Otherwise CU+ packet should always carry IP ID field then we can avoid
looking at sequnce number but not in the case with CU packet.

What is your comment about CUDP with extension co-exist?
Should it look for link seq number match further also  ?

Point #2

One solution to IP ID prolem you stated as "Twics Algo"
Solution to this problem could be using twice algorithm.
But "twice" algorithm is not mandatory. There are implementations
without preserving UDP checksum. In this case I dont have an answer.
May be we have to force a standard that everyone should implement
UDP checksum while transmitting out. I dont know how many people will do
that.

Point #3.1

In our discussion we have addressed two kinds of packet loss

1)  RTP packet loss in the network before reaching compessor (Say L1)
2) Compressed packet loss sent from compressor to decompressor (Say L2)

In a lossy environment (L1), we end up in sending more number of encoded
bytes
with CU+ than what we used to send with CR+.
Because in CU+ we encode deltaT of the next expected RTP packet, with
the current packet.
I can understand your point that source generate with same periodic time
gap for
each packet within a talkburst. But the carrier network is IP datagram
service and
(+ link lossy nature). So should we rely on the possible network
behaviour or should we, on the source behaviour.

If L2 is greater than L1 then you claimed advantage of CU+ sync between
compressor
and decompressor can be achieved.

But What is the likely chance for L2 >  L1 ?
Only for some specific lossy links.

Point # 3.2

As far as I know CRTP use some heuristic mechanism to identify a RTP
flow.
It is not a definite mechanism. In this case  does it make sense to
send the deltaT of the next expected packet. Consider L1 case mentioned
above.
Not only that, assume the time gap between talkburst is (T1) and time
gap between
inter packet arrival of same session is T2. Consider a case of,
If we have identified a non-RTP flow as RTP flow and started compression

with our heuristics how do we determine when to send CU+.
Will we end up in sending continuous CU+ ?  we may ..
There need not be talkburst gap with some what high definite gap
when  compare to interpacket gap of the same session...
(See Pt # 4 on CU+ size comparison with CR+)

Point #4

Size of the CU+ is more than CR+ because of the compressed RTP header ..

in CR+. In CU+ you send complete RTP header as it is (i.e 12 byts).
In old CRTP, Assume that for some situation we have to encode RTP seq
number and
Timestamp, For ideal case encoded byte size will be 2 byts (1 for seq
number
+ 1 for deltaT) or otherwise 4 or max 6 (still less than 12 bytes).
Over a lossy link (L2), which is particular to the link, advantage of
CU+ is missing.

Continuous sending of CU+ for a talk burst may avoid send CS from
decompressor to
compressor. But What kind of loss is more likey L1 or L2.

My personal comment to CU+ is

May be we can claim some advantage only if
the stated assumptions (about packet loss (L1 < L2),  twice algo..etc)
are met ..
That also with the modification of IP ID inside the CU+  packet.

Thanks & Rgds

GVJ

Tmima Koren wrote:

>> >>  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
>> > Tmima
>>
>> Tmima,
>>
>> For IP id field  first order difference is sent as delta in CUDP
>> with I bit set.
> 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.
> 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..
>
> 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.
>
>> the  silence period. Could you please explain your point  ..(please
>> ref my previous mail)
>
>
> Let's say that the characteristics of the link is that we may lose at
> most 1 packet in a row
> If we use:
>
> 11      200       CR+    dt=100
> 12      210       CR+    dt=10
> 13      220       CR
>
> If 11 is lost, the decompressor does not have the correct RTP
> timestamp for packet 12.
> In this case If one of 11" or 12" is lost, the decompressor remains in
> sync. So this is a very strong sequence
>
> Tmima
>
>
>
>> Please reply .
>>
>> Rgds
>>
>> GVJ
>
-