RE: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt

["Timur Friedman" <timur.friedman@lip6.fr>]

Hello Joerg,

Saving a full octet in an RTP XR block header is indeed tempting.  Thank you for bringing this issue to our attention again.  I don't think it has yet gotten the scrutiny it deserves.

The following concerns lead me to hesitate about making the change:

- Although RTP XR blocks should stay small (for scalability), one can envision good reasons for the occasional large report block.

- The large report blocks are the ones that would benefit the most from compression.  If the reported data are compressible, we wish to afford them a good compression ratio.  It could be that, by requiring the data to be divided up into pieces before being compressed (in order to fit into 1020 byte units), we hurt the compression ratio.  I do not have concrete examples to cite, but to my mind this is a real possibility.

- Fragmentation and reassembly (in this case of reports, at the RTCP level) impose overhead.

- It is true that SDES elements are limited by an 8 bit length field.  However the elements, names, e-mail addresses, phone numbers, etc., are relatively short.  The note or the private element might be an exception.  In the case of RTP XR, several of the blocks are potentially very long (timestamp reports, for example).  While it is a good general policy to limit their size, in my mind it is better to limit them as a function of the application's requirements and the environment (including MTU) rather than imposing an a priori constraint that is much less than the possible size of an RTCP packet.

- The usual MTU is a constraint.  But it is also something subject to change depending upon the environment, and a value that might well evolve over the long term.  We don't necessarily want to lock in to a constraint that is subject to such change.

- None of the report blocks currently defined in the RTP XR draft could be shortened by a full 32 bit word if the length field were reduced from 16 bits to 8 bits.

One compelling argument in favor of the shortening would be a report block that would benefit.  But I would remain concerned about the issues that I have listed.

Best regards,

Timur

> -----Original Message-----
> From: Joerg Ott [mailto:jo@tzi.uni-bremen.de]
> Sent: Monday, February 17, 2003 1:12 PM
> To: Timur Friedman
> Cc: avt@ietf.org; Ramon Caceres; Alan Clark; Kevin Almeroth; Kamil
> Sarac; Robert Cole; Kaynam Hedayat; Nick Duffield
> Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt
> 
> 
> Timur,
> 
> while we are at it: I am currently revising the SSM RTCP draft and
> hence came across an issue I also mentioned at the last IETF:
> wouldn't it make sense to slightly revise the first few bytes of the
> XR blocks defined in section 3:
> 
> (sorry if you have gone through this again and again)
> 
> From:
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      BT       | type-specific |         block length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     :                      type-specific data                       :
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> To:
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      BT       | block length  |       type-specific data      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     :                      type-specific data                       :
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The first byte of your type-specific data field could easily become
> the "type-specific" field before.
> 
> As you are measuring block size if multiples of 32 bits, an 8 bit
> value will cover block sizes of up to 1,020 bytes which seems quite
> a lot (particularly as the packets are supposed to fit into a usual
> MTU).  If you need more, you could just include the same block
> several times.  You'll save one byte or two per report block.
> 
> BTW: Except for the alignment requirement, the above structure would
> also mirror the SDES format.
> 
> Joerg

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt