RE: [rohc] 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
  events and discussions on the mailing list
- the current agreement works, and your proposals target
  only a possible very minor inefficiency in the protocol
  (i.e. the protocol is not broken)

I will, however, consider your proposals for the upcoming RoHCv2 update.

Thanks

/Ghyslain

Lajos Zaccomer (IJ/ETH) wrote:
> Hi RoHCers,
> 
> The latest Implementers' Guide (version 19) clarified the update of 
> RTP P and X bits in sections 6.4 and 6.5 in a strange way, at least 
> compared to other fields and the significance of these two bits:
>     - if 0, there is no need to send the optional packet part (but may

> be sent for other reasons)
>     - if 1, the optional packet part containing the P/X bit must be 
> sent
> 
> This solution is optimized for the case when X = 0 and P = 0.
> This is in contrast with RFC 3095 A.1.4 that says both P and X are 
> application dependent, even though X is expected to be 0 in most 
> cases.
> 
> If P/X is 1, the optional packet part containing the P/X bit must be 
> included, even though the value is not changed. This means one 
> additional octet in EXT-3 for P bit and one additional octet in RTP 
> dynamic part for X bit. As a compensation, the solution may save one 
> octet in RTP dynamic part for X bit if 0; however, even this is 
> unlikely to happen, as the TS_STRIDE is most probably sent in the 
> establishment.
> (As the value of P/X is not expected to change during the lifetime of 
> the packet flow, as said in RFC 3095 A.1.4, only the establishment 
> period is of concern.)
> 
> In case a CID is reused with the same X=1 value as of the previous 
> packet flow, it must be updated, even though it is not changed - 
> because of the value 1. Even if X=0, the optional part in the RTP 
> dynamic part is probably sent due to TS_STRIDE establishment - unless 
> it is also the same.
> 
> What is the advantage then? Is P=1 and/or X=1 really that unlikely 
> that it is worth deferring from the clean way of updating other fields

> not function of SN to save one octet per thousands of packets? EXT-3 
> must be quite common to cope with irregularities, therefore I'm not 
> quite comfortable with the idea to update a field based on its value 
> instead of being changed, as for all other fields not function of SN 
> (except RTP M bit, but that is reasonably explained in RFC
> 3095 A.1.4). This seems to be additional complexity mainly to send 
> more bytes in some cases.
> 
> Looking forward to reading your opinion and comments.
> 
> Best regards,
> Zacco
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc