[AVTCORE] New Possible Errata in RFC2326 (And Draft) regarding Blocksize

[Julius Friedman <[e-mail]>]

Please see the following two paragraphs regarding Blocksize.

12.7 Blocksize

   This request header field is sent from the client to the media server
   asking the server for a particular media packet size. This packet
   size does not include lower-layer headers such as IP, UDP, or RTP.
   The server is free to use a blocksize which is lower than the one
   requested. The server MAY truncate this packet size to the closest
   multiple of the minimum, media-specific block size, or override it
   with the media-specific size if necessary. The block size MUST be a
   positive decimal number, measured in octets. The server only returns
   an error (416) if the value is syntactically invalid.


18.10 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-18.10>.
Blocksize

   The Blocksize request-header field is sent from the client to the
   media server asking the server for a particular media packet size.
   This packet size does not include lower-layer headers such as IP,

   UDP, or RTP.  The server is free to use a blocksize which is lower
   than the one requested.  The server MAY truncate this packet size to
   the closest multiple of the minimum, media-specific block size, or
   override it with the media-specific size if necessary.  The block
   size MUST be a positive decimal number, measured in octets.  The
   server only returns an error (4xx) if the value is syntactically
   invalid.


Both paragraphs go to specify that the number MUST be positive but
specify no LOWER bound.


A Blocksize of 12 or less will cause data loss under UDP and cause
invalid framing under TCP.


A Blocksize of >= 12 <= 20 will cause no payload data to be able to be
sent in most profiles which utilize a 4 - 16 byte header.


Therefore the minimum Blocksize must be 21 when RTP is in use and such
a low number of octets in the payload (1) would cause unnecessary
stain on the server.


It should be noted that the Blocksize MUST be a positive decimal
number greater than or equal to that supported by the underlying
transport.


This will prevent a client from undermining the MTU and attempting to
force a server to fragment packets against protocol rules OR perform
re-packetization which may interfere with packetization rates defined
in SDP or profile specific headers which require a fixed header size
greater than or equal to the specific Blocksize.


It may also be worth noting that even if a valid number is given for
Blocksize that the server would have to 're-packetize' the packet and
in most cases a packet CANNOT be re-packetized without re-packetizing
the entire frame where the packet was contained.


This adds an unnecessary delay and causes differentiation in reporting
to and from receivers especially in multicast situations.


It is therefore recommended that Blocksize be only used during a
'OPTIONS' or 'SETUP' request and if the server does not support the
given Blocksize that the status code returned be 'INFORMATIONAL' and
the Blocksize header in the response should indicate the minimum
required Blocksize.


-----------------


I would like to file this errata as soon as possible if everyone agrees;


If it's not erratum can we please also address this misnomer I seem to have.


Thank you!