Subject: [MMUSIC] New Possible Errata in RFC2326 (And Draft) regarding Blocksize

From: Julius Friedman <[email-masked]>
Date: Fri, 9 Jan 2015 03:46:58 -0500

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!

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 09 Jan 2015 21:28:22 -0500

> invalid framing under TCP.

Could you explain this in more detail?  Since the "Blocksize" number
"does not include lower-layer headers such as IP, UDP, or RTP", it seems
to me that it counts only the bytes after the "RTP Fixed Header Fields"
and any RTP header extensions, and that number legitimately could be
small (depending on the media encoding in the RTP).

> number greater than or equal to that supported by the underlying

In any case, *this* RFC does not *have* to state that, as that is a
requirement imposed by other RFCs. 

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

As far as I can tell, it's not an erratum, because there is no "error"
in the RFC.  What you're suggesting is that there is useful information
that the RFC does not include, but that information is not an error in
this RFC's text.

Dale

---

From: Julius Friedman <[email-masked]>
Date: Fri, 9 Jan 2015 22:38:35 -0500

...

", it seems
"

- There must be 12 octets which are the fixed header, this is where that
information comes from.

- If ROHC is used or some other encoding / compression which changes this
amount it is beyond the scope of RTP and that is why I say that the
underlying Transport should handle this.

We are not talking about other RFC's we are talking about the ones which
state the information (RFC2326 and it's biz draft), they introduce this
header and thus should concretely define it's functionality such that it
does not impose upon other requirements.

I am confused as how can you both say you don't understand and that there
is no error? It has now been explained further... Please re-consider, you
omitted to respond to other points within the same email chain which relate
to the problem so it imposes upon my response and would cause me to repeat
data here again which I was asked not to before.

If there is a better mechanism for communication of these issues please let
me know, I would be happy to prepare a summary and present it either as a
document or over a tele-conference to address this as well as any other
points which have yet to be addressed.

If there is no error then what is the process to include this useful
information in some way so that others may know as well?

I sincerely appreciate your time,
Julius

On Fri, Jan 9, 2015 at 9:28 PM, Dale R. Worley <[email-masked]> wrote:

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Jan 2015 14:51:24 +0100

Hi,

I also have some issues to see what your issue are.

The intent of this header is "can you please ensure that the media
payloads are never bigger than X". The server can either except it or
override it and respond with "No, I can only guarantee Y bytes".

And that will be dependent on both the media format and the capabilities
of the server. If the requested blocksize requires repackaging and you
don't support you will have to override the value which comes from the
packaging that do exist.

On 2015-01-10 04:38, Julius Friedman wrote:
> - If ROHC is used or some other encoding / compression which changes
> this amount it is beyond the scope of RTP and that is why I say that the

The text says that IP/UDP/RTP are all excluded from this so if you say
Blocksize=1 then you can only include one byte of RTP payload. Which
with the exception of some sample-based codecs are completely useless
and will have to be overridden to the minimal value the media format can
support.

But, the above appears to be irrelevant for this header.

> I am confused as how can you both say you don't understand and that
> there is no error? It has now been explained further... Please
> re-consider, you omitted to respond to other points within the same
> email chain which relate to the problem so it imposes upon my response
> and would cause me to repeat data here again which I was asked not to
> before.
> 
> If there is a better mechanism for communication of these issues please
> let me know, I would be happy to prepare a summary and present it either
> as a document or over a tele-conference to address this as well as any
> other points which have yet to be addressed.
> 
> On Fri, Jan 9, 2015 at 9:28 PM, Dale R. Worley <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Julius Friedman <[email-masked]
>     <mailto:[email-masked]>> writes:
>     > 18.10
>     <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-18.10>.
>     > Blocksize
>     >
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 29 Jan 2015 22:10:00 -0500

> - There must be 12 octets which are the fixed header, this is where that

That's incorrect.  See the text you quoted earlier:

   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. [...]

Note that it says "This packet size does not include ... headers such as
... RTP."  The RTP header is *not* counted in this blocksize, so its 12
octets do not constitute a minimum allowed value of blocksize

Dale

---

From: Julius Friedman <[email-masked]>
Date: Thu, 29 Jan 2015 22:22:34 -0500

Hence my argument about being supported by the underlying transport
session.

But just to be clear,   a client may request a blocksize of 1 and the
server would:

1) either be able to oblige and deliver a 13 byte packet at minimum

OR

2) respond with a blocksize of x where x is the lowest available closest
multiple supported.

There is no corner case.

I would also expect as a result that the transport level framing is not
included in this count either?  E.g. 4 for binary interleaved transport.

Thanks for clarifying this.

The problem is then with the binary interleaved section and I will wait for
further feedback in that regard.

Thanks again,

-Julius

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 Jan 2015 11:56:05 +0100

> included in this count either?  E.g. 4 for binary interleaved transport.

Yes, with the definition that exist this is focused on the media part
that will be excluded.

> The problem is then with the binary interleaved section and I will wait
> for further feedback in that regard.
> 
> Thanks again,
> 
> -Julius
> 
> On Jan 29, 2015 10:10 PM, "Dale R. Worley" <[email-masked]
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 

Magnus Westerlund