Ghyslain Pelletier (LU/EAB | 1 Jun 15:53 2006
Picon

RE: Interpretation intervals for TS encoding

Hi Endre,

It strikes me that the text that you are addressing in
draft-ietf-rohc-rtp-impl-guide-19.txt is rather old, it probably comes
from a version prior to this draft becoming a WG draft. Therefore I
think it is sound to revisit it.

I think that this sums up to answering to the following:

1) When does the HD start using TB decoding
2) What happens to the interpretation interval during
   transitions between Scaled TS encoding and TB encoding?
   (i.e. does the HC have to send more bit or some reason?)

My understanding is that if the answer to 1) is clear, than 2) is
irrelevant as, as you wrote yourself, the compressor will use a
reference that it has confidence that the decompressor has, and it will
use the correct interpretation interval as per section 4.3.

The answer to 1) is also clear, as you wrote yourself again, i.e. the
decompressor uses TB decoding as soon as it sees TIME_STRIDE>0, as per
section 5.7:

   TS: The compressed RTP Timestamp value.

      If value(TIME_STRIDE) > 0, timer-based compression of the RTP
      Timestamp is used (see section 4.5.4).

So, as a result of your comment, my proposal is to remove the last
paragraph in the text of section 4.3, i.e.:
(Continue reading)

Ghyslain Pelletier (LU/EAB | 1 Jun 17:10 2006
Picon

RE: Update of RTP P and X bits

Hi Lajos,

Regarding the text in section 6.4 on the R-P bit, I think that in short
you mean that:

- handling of the R-P bit is focusing on the
  case where RTP padding is not used (R-P=0)
- padding is application dependent
- this bit could be handled as any other semi-static field

Regarding the text in section 6.5 on the X bit, I think that in short
you mean that:

- handling of the X bit is focusing on the
  case where RTP extensions are not used (X=0)
- RTP extensions are not expected to be used
- there is little gain for the IR packet in updating
  context(X)=0 when RX=0, as RX will likely be 1
- there is little gain for the IR-DYN packet in updating
  context(X)=0 when RX=0, because context(X) will already
  be established
- this bit could be handled as any other semi-static field
  (provided there's a default initial value for context(X))

In both cases, I agree that this would be possible. However, we cannot
make any changes to draft-ietf-rohc-rtp-impl-guide-19.txt with respect
to your comments, for the following reasons:

- making a change at this point would go against what
  has already been agreed for a long time, from interop
(Continue reading)

Thomas Narten | 2 Jun 15:22 2006
Picon

Re: Liaison request from 3GPP2

Thanks all for the followup. It has been useful.

Note that 3GPP2 wants to make use of the new profile that deals with
packet reordering. Thus, it wants an updated profile published (as an
RFC) that it can formally reference as part of its standard.

What they want to know, is what is a reasonable/realistic target date
for that work to be finished (i.e., through the IETF and approved  by
the IESG)?

So, for the profiles document:

1) it seems that since -00 does not even exist, we are talking several
   more months (or maybe a year???) before the document is
   finished. Can the WG provide a target timeline for when that work
   might complete?

2) To help with a timeline, is there a sense for how much work is
   needed to get an updated profiles document? I.e., is it already
   generally understood what is needed and thus is the -00 draft
   likely to be mostly complete? Or, is the -00 document a first cut,
   and is it expected that more and more will need to be added as
   people start to review it?

3) Alternatively (and this may sound naive), is another possible
   avenue to have a separte (short and focused) document that aims to
   address just the reordering profile, in order to get that done
   relatively quickly?

Again, my goal is to have a realistic timeline for when this work will
(Continue reading)

Lars-Erik Jonsson | 2 Jun 16:43 2006
Picon

Re: Liaison request from 3GPP2

Thomas,

I am currently working with a charter and milestones update for ROHC, so 
I hope to have reasonable timeline estimates within one week (absolutely 
not more than two weeks). The technical content of the new profiles is 
pretty well known and agreed, but we really want to make a better 
specification this time (RFC 3095 was a mess to understand), and that 
will of course require some cycles. Doing an additional profile set only 
to improve reordering tolerance is not an alternative, we do not want to 
deliver another specification based on 3095. Also, I expect the 
reordering tolerance part to be the trickiest (technically) work of the 
new profile set.

So, during the next 1-2 weeks, expect to see both the -00 profiles draft 
and an update of the ROHC charter (at least a stable proposal, if not 
yet approved).

Rgds,
/Lars-Erik

----- Original Message ----- 
From: "Thomas Narten" <narten <at> us.ibm.com>
To: "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson <at> ericsson.com>
Cc: <rohc <at> ietf.org>; "Ghyslain Pelletier (LU/EAB)" 
<ghyslain.pelletier <at> ericsson.com>; "AC Mahendran" 
<mahendra <at> qualcomm.com>
Sent: Friday, June 02, 2006 3:22 PM
Subject: Re: [rohc] Liaison request from 3GPP2

> Thanks all for the followup. It has been useful.
(Continue reading)

Cristian Constantin | 7 Jun 17:21 2006

sigcomp ACK (rfc 3321) vs NACK (rfc 4077)

hi!

suppose the following scenario takes place:

1. there is a compartment mapped to a a certain phone in an proxy; the
compartment has a certain lifetime and using the mech spec. in rfc3321
knows that some states are available at the other end (i.e. the phone).
2. the phone reboots (unexpectedly); all its state is lost.
3. the phone is now online again; the proxy maps the signalling with the
phone to the _same_ compartment as before. 
(it has no idea that the phone has rebooted...)
4. since the lifetime of the compartment in the proxy has not expired,
the proxy will still try to access the acke'ed states that are supposed
to be found at the phone.

what will it happen? is it true that rfc 3321 cannot cope with this but
rfc 4077 does?

bye now!
cristian
Rasheed Ahammad S | 8 Jun 07:51 2006

doubt in sigcomp decompression buffer


Hi ROHCians,

I have the following doubts regarding the decompression buffer.


1. End Point A  uses compression algorithm of his own choice and sends the sigcomp message to End Point B. How much decompression buffer  B should allocate in order to successfully decompress the message. B is not aware of the compression algorithm used at  A and also its not aware of the compression ratio. If B allocates buffer of its choice..then there is chance of buffer overflow in case the decompressed message is bigger than the size of the allocated buffer.

2. RFC 4077 discusses this problem in OUTPUT OVERFLOW  as one of the reason codes for the failure. It means in our scenario when the decompression buffer overflows at  B it will form the NACK message with the reason code as OUTPUT OVERFLOW and send it to A. But the RFC does not discuss about how this problem should be recovered at end point B. How much decompression buffer  B should allocate for the next messages from A.

Also, what end point A has to do when it receives  NACK message with OUTPUT OVERFLOW as the reason code.

The decompression buffer is not derived from any of the sigcomp parameters. So, there is no way that end point A can inform the end point B to increase its decompression buffer.

Regards,
Rasheed
Ext: 9113

***********************  FSS-Unclassified   ***********************
_______________________________________________
Rohc mailing list
Rohc <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rohc
Cristian Constantin | 8 Jun 15:55 2006

Re: doubt in sigcomp decompression buffer

On Thu, Jun 08, 2006 at 11:21:56AM +0530, Rasheed Ahammad S wrote:
> Hi ROHCians,
> 
> I have the following doubts regarding the decompression buffer.
> 
> 
> 1. End Point A  uses compression algorithm of his own choice and sends the 
> sigcomp message to End Point B. How much decompression buffer  B should 
> allocate in order to successfully decompress the message. B is not aware 
> of the compression algorithm used at  A and also its not aware of the 
> compression ratio. If B allocates buffer of its choice..then there is 
> chance of buffer overflow in case the decompressed message is bigger than 
> the size of the allocated buffer.

cristian: if you refer at the internal udvm buffer used for
decompression itself: overflow no bec. it's circular; more like overwrite. 
A should send the bytecode that runs in the minimum dms provided at B 
(for ims: 8k); the bytecode sent by A sets up the circular buffer.

for not overwriting already decompressed info you have to know for
example how much your decompression algo decompresses in "one"
decompression operation (i.e. by deflate what is the max length of the 
string that was matched in the window.)

> 
> 2. RFC 4077 discusses this problem in OUTPUT OVERFLOW  as one of the 
> reason codes for the failure. It means in our scenario when the 
> decompression buffer overflows at  B it will form the NACK message with 
> the reason code as OUTPUT OVERFLOW and send it to A. But the RFC does not 
> discuss about how this problem should be recovered at end point B. How 
> much decompression buffer  B should allocate for the next messages from A. 
> 
> 
> Also, what end point A has to do when it receives  NACK message with 
> OUTPUT OVERFLOW as the reason code.
> 
> The decompression buffer is not derived from any of the sigcomp 
> parameters. So, there is no way that end point A can inform the end point 
> B to increase its decompression buffer.

cristian: now I think you refer to the memory where the decompressed
message is stored... rfc3320 says that OUTPUT causes problems when it
outputs more than 64K (it is not allowed to do it)
either you set it directly to 64 K for each and every udvm instance; or
you dynamically increase it until you reach that value. (on B)

bye now!
cristian
Lars-Erik Jonsson (LU/EAB | 12 Jun 11:21 2006
Picon

RE: Interpretation intervals for TS encoding

Ghyslain, Endre, others,

I fully agree with your conclusions.

This paragraph originates from the initial individual version
of this draft, dated November 2001. It had its own section
called "4.2.  Transition to timer-based compression", but the
text was later incorporated into the section about
interpretation intervals (added in rev 02, Oct 2002).

When now looking into this again, I agree with the conclusion
that 1) is clear from section 5.7 of RFC 3095. It is a mystery
to me how and why anyone would interpret this differently.

>From the mail archive we can find some discussions with
interpretations in line with the questioned paragraph in the
implementer's guide, but without arguments *why* that
should be needed (see thread titled "What is p value for TS?"
from September-October 2002).

So, I agree with the suggestion to remove this paragraph from
section 4.3 of the current draft. Since I have not seen any
objections, I will do this change to the draft right now.

/L-E

> Hi Endre,
> 
> It strikes me that the text that you are addressing in
> draft-ietf-rohc-rtp-impl-guide-19.txt is rather old, it probably
> comes from a version prior to this draft becoming a WG draft.
> Therefore I think it is sound to revisit it.
> 
> I think that this sums up to answering to the following:
> 
> 1) When does the HD start using TB decoding
> 2) What happens to the interpretation interval during
>    transitions between Scaled TS encoding and TB encoding?
>    (i.e. does the HC have to send more bits for some reason?)
> 
> My understanding is that if the answer to 1) is clear, than 2) is
> irrelevant as, as you wrote yourself, the compressor will use a
> reference that it has confidence that the decompressor has,
> and it will use the correct interpretation interval as per
> section 4.3.
> 
> The answer to 1) is also clear, as you wrote yourself again, i.e.
> the decompressor uses TB decoding as soon as it sees
> TIME_STRIDE>0, as per section 5.7: 
> 
>    TS: The compressed RTP Timestamp value.
> 
>       If value(TIME_STRIDE) > 0, timer-based compression of the
>       RTP Timestamp is used (see section 4.5.4).
> 
> So, as a result of your comment, my proposal is to remove the
> last paragraph in the text of section 4.3, i.e.:
> 
>    Since two different p-values are used, the compressor must
>    take this into account throughout the process of enabling
>    timer-based compression (see section 4.8 of this document).
>    During transition from window-based compression to timer-
>    based compression, it is thus necessary that the compressor
>    keep k large enough to cover both interpretation intervals. 
> 
> as it is not relevant (besides that it was in itself rather
> unclear in its own magical ways!). 
> 
> Thanks
> 
> /Ghyslain
> 
> Endre Szalai (IJ/ETH) wrote:
>> Hi ROHCers,
>> 
>> reading the "Corrections and Clarifications to RFC 3095"
>> (draft-ietf-rohc-rtp-impl-guide-19.txt) document, the last paragraph
>> of section 4.3 is not really clear for me.
>> 
>> "Since two different p-values are used, the compressor must take this
> 
>> into account throughout the process of enabling timer-based
>> compression (see section 4.8 of this document).
>> During transition  from window-based compression to timer-based
>> compression, it is thus  necessary that the compressor keep k large
>> enough to cover both  interpretation intervals."
>> 
>> When the HC wants to use timer based compression, it will start
>> sending a positive TIME_STRIDE value (after of course a valid CLOCK
>> option is propagated from the HD). If the HD receives such a packet,
>> it will switch to timer based compression immediately. This means,
>> that the HD will use the value for "p" as specified in section 4.5.4
>> in RFC 3095) when decompressing received TS bits (if any), and not
>> the 
> 
>> "p"
>> value for the W-LSB encoding.
>> 
>> Why and how the HC should consider the "p" value for W-LSB encoding
>> in 
> 
>> this case ?
>> 
>> The HC keeps track of all possible references the HD may have, and
>> the 
> 
>> HC will simply apply timer based compression with the proper "p"
>> value. Since HD will use the same "p" value (TIME_STRIDE > 0), how
>> could the 2 different interpretation intervals interfere ?
>> 
>> Could someone give a clarification on this (maybe an example) ?
>> 
>> Thanks,
>> Endre
Cristian Constantin | 12 Jun 18:10 2006

lost (sigcomp) ACK

hi!

nothing can be said about the remote end state config (and free state
memory) if an ACK for a state with priority p gets lost and the remote
end already has some priority p states, right?

in such a case, always switch back to the initial state, right?
(i.e. dictionary)

bye now!
cristian
Rasheed Ahammad S | 13 Jun 10:04 2006

Doubt regarding forming NACK message



Hi ROHCians

1) Incase of decompression failure SIGCOMP has to send NACK message to other end.  RFC 4077  figure 1 contains NACK message structure which has "returned feedback item" is one of the field. So when forming the message how can we encorporate "returned feedback item" in NACK message since we don't know the compartment id ( received message is not decompressed successfully).

2) If an End receives NACK message what actions it should take..?.

Thanking you very much



Regards,
Rasheed
Ext: 9113

***********************  FSS-Private   ***********************
_______________________________________________
Rohc mailing list
Rohc <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rohc

Gmane