Subject: RE: [AVT] Action item #2: handling IP ID in crtp-enhance

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Tue, 9 Oct 2001 12:38:17 +0200

Andrew,

Thanx for your quick response...

> > > 1014            Send CR                    ID 1014, delta 1
> > > 1015            Send CR                    Dropped
> > > 1016            Send CR                    Dropped
> > > 1017            Send CR                    Dropped
> > > 1018            Send CR                    Dropped
> > > 1019            Send CR                    Dropped
> > > 1020            Send CR                    Dropped
> > > 1021            Send CR                    ID ????, lost too many.
> > 
> > What do you mean by Dropped here? Do you mean lost over the 
> > link? 
> 
> The decompressor wouldn't know a packet was dropped until the
> next successfully received packet was decoded.  Then the jump
> in sequence number would show that Twice should be attempted.

True, I have not been thinking CRTP for a long time...=)

> > Once again, I think we are getting close to a solution and I 
> > hope we can fix this so that ECRTP can finally be completed. 
> > By the way, what happens to RFC2507/08? It should be time to 
> > take those to DS.
> 
> The HDRCKSUM in the enhancements means we only have a problem
> with IPv4 with UDP checksums.  Should any scheme like the above
> be applied to all cRTP streams, or just IPv4 with UDP checksums?

We are only talking about E-CRTP here, and I agree with you that the outlined solution should not be needed in any other case than for IPv4 with UDP checksum enabled.

Rgds,
/Lars-Erik

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: Tmima Koren <[email-masked]>
Date: Tue, 09 Oct 2001 19:17:33 -0700

Hi all
Thanks for the ideas and the proposed solution

Here is a suggestion for a "Selected update repetition number" packet where 
the compressor notifies the decompressor about the currently used N in the 
N scheme

2.4  Selected update repetition number packet

When the compressor sends a packet that includes updates, the updates are 
repeated in N+1 packets (see section 2.3 CRTP operation in 'N' mode)
As long as less than N+1 adjacent packets are lost, the decompressor can 
recover from the loss by using the 'twice' algorithm. If N+1 packets or 
more were lost, a whole update sequence might have been lost. In this case 
the decompressor SHOULD invalidate the context and not try to recover using 
the 'twice' algorithm.
The compressor SHOULD notify the compressor about the current N used in the 
N scheme by sending the "Selected update repetition number" packet. The 
decompressor should assume that N=0 prior to receiving a "Selected update 
repetition number" packet.
The compressor may change the value of N and send additional "Selected 
update repetition number" packets.

The "Selected update repetition number" packet is a CONTEXT_STATE packet 
with type code 4.

              0   1   2   3   4   5   6   7
            +---+---+---+---+---+---+---+---+---+---+----+----+
            | Type code=4: Selected update repetition number  |
            +---+---+---+---+---+---+---+---+---+---+----+----+
            |                 Parameter: N                    |
            +---+---+---+---+---+---+---+---+---+---+----+----+

Is this an acceptable correction?
Regards
Tmima

At 12:38 PM 10/9/2001 +0200, Lars-Erik Jonsson (EPL) wrote:
>We are only talking about E-CRTP here, and I agree with you that the 
>outlined solution should not be needed in any other case than for IPv4 
>with UDP checksum enabled.
>
>Rgds,
>/Lars-Erik
>

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Wed, 10 Oct 2001 12:06:00 +0200

Tmima,

I think it is good to get to some concrete proposals for the scheme here. I have included a couple of comments and questions below.

BR
/L-E

> Here is a suggestion for a "Selected update repetition number"
> packet where the compressor notifies the decompressor about
> the currently used N in the N scheme

C: This then affects the N-scheme in 2.3, so that it requires negotiation either pre-negotiation or in-band. Now 2.3 says that N must not be negotiated.

Q: Further, here you say that it is the compressor that informs the decompressor, but below you propose to do this through a context state packet, which is sent from decompressor to compressor. Or?

> When the compressor sends a packet that includes
> updates, the updates are repeated in N+1 packets
> (see section 2.3 CRTP operation in 'N' mode)
> As long as less than N+1 adjacent packets are lost,
> the decompressor can recover from the loss by
> using the 'twice' algorithm. If N+1 packets or
> more were lost, a whole update sequence might have
> been lost. In this case the decompressor SHOULD
> invalidate the context and not try to recover
> using the 'twice' algorithm. The compressor SHOULD
> notify the compressor about the current N used in
> the N scheme by sending the "Selected update

Q: First, what was the intention of this text?
"...compressor SHOULD notify the compressor..." does
not make sense. Further, what happens if this is
not done?

> The decompressor should assume that N=0 prior to
> receiving a "Selected update repetition number"
> packet. The compressor may change the value of N
> and send additional "Selected update repetition
> number" packets.

C: Assuming that it is the compressor that informs the
decompressor, and the decompressor assumes N=0 if
nothing else has been indicated, it should then be
mentioned that N=0 means Twice SHOULD NOT be applied
at all.

> The "Selected update repetition number" packet is
> a CONTEXT_STATE packet with type code 4.

Q: Does this mean CONTEXT_STATE packets may also be
sent from compressor to decompressor??

---

From: Tmima Koren <[email-masked]>
Date: Mon, 15 Oct 2001 16:52:55 -0700

Hi Lars-Erik
Thanks for your comments

The packet type for the 'Selected update repetition number' is 
CONTEXT_STATE, but the type code is 4, and this packet is sent from 
compressor to decompressor.
The decompressor assumes that N=0 until he receives a 'Selected update 
repetition number' with a different N
When N=0, the decompressor can't use 'twice'
Also, this applies only to IPv4, so I added this too.

Here is the updated text:

2.4  Use of the 'twice' algorithm and the "Selected update repetition 
number" packet

When the context state is synchronized between the compressor and 
decompressor, the decompressor can recover from packet loss by using the 
'twice' algorithm, and the resulting packet is guaranteed to be identical 
to the compressed packet.

Since updates are repeated in N+1 packets (see section 2.3 CRTP operation 
in 'N' mode), if at least one of these N+1 update packets is received by 
the decompressor, the context at the decompressor will get updated and will 
stay synchronized with the context at the compressor. We can conclude that 
as long as less than N+1 adjacent packets are lost, the context at the 
decompressor is guaranteed to be synchronized with the context at the 
compressor, and use of the 'twice' algorithm to recover from packet loss 
will successfully update the context and restore the compressed packets.

When more than N packets are lost, a whole update sequence might have been 
lost. The shared state may now be different at the compressor and 
decompressor. The decompressor can still try to recover by applying the 
'twice' algorithm and validating the packet with the UDP checksum (or the 
HDRCKSUM), but since the IPv4 IP ID is not included in the checksums, this 
does not validate the IPv4 IP ID.
The conclusion is that in IPv4 if more than N packets were lost, the 
decompressor SHOULD invalidate the context and not try to recover using the 
'twice' algorithm. In IPv6 the decompressor may always try to recover from 
packet loss by using the 'twice' algorithm and verifying the result with 
the UDP checksum.

When compressing IPv4 packets, the compressor SHOULD notify the 
decompressor about the current N used in the N scheme by sending a 
"Selected update repetition number" packet. The decompressor should assume 
that N=0 prior to receiving a "Selected update repetition number" packet. 
When N=0, the 'twice' algorithm SHOULD NOT be used in IPv4.
The compressor may change the value of N and send additional "Selected 
update repetition number" packets.

The "Selected update repetition number" packet is a CONTEXT_STATE packet 
type with type code 4 and is sent from compressor to decompressor.

              0   1   2   3   4   5   6   7

Hope this text explains the idea better
Regards
Tmima

At 12:06 PM 10/10/2001 +0200, Lars-Erik Jonsson (EPL) wrote:
>Tmima,
>
>I think it is good to get to some concrete proposals for the scheme here. 
>I have included a couple of comments and questions below.
>
>BR
>/L-E
>
>
>
>C: This then affects the N-scheme in 2.3, so that it requires negotiation 
>either pre-negotiation or in-band. Now 2.3 says that N must not be negotiated.
>
>Q: Further, here you say that it is the compressor that informs the 
>decompressor, but below you propose to do this through a context state 
>packet, which is sent from decompressor to compressor. Or?
>
>

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Tue, 16 Oct 2001 08:43:18 +0200

Hi Tmima,
 
This looks fine to me! 
Since there seems to be no other concerns, are you preparing an update of the draft, ready for WG last-call?
 
Cheers,
/L-E

Hi Lars-Erik
Thanks for your comments

---

From: Tmima Koren <[email-masked]>
Date: Tue, 16 Oct 2001 14:01:10 -0700

>the draft, ready for WG last-call?

Yes, I'll send out an update soon
Thanks
Tmima