Re: [AVT] Another question on RFC 4103

[Marc Petit-Huguenin <petithug at acm.org>]

Gunnar Hellstrom wrote:
> Marc,
> My calculations end up a factor 10 lower than yours.

Section 6 of RFC 4103 states that "The [cps] value shall be used as
a mean value over any 10-second internal."  So at 30 cps, one can
send nothing for 10 seconds then send a block of 300 characters
without triggering the rate limiter.  This can be the case when a
text (e.g a long URL) is copied and pasted in the UI.

> 
> You are right that we did not think there was any reason to go deep in a
> discussion on MTU sizes in RFC 4103.
> 
> Instead we specify the intended use, that is for human input, and human
> reading in a real-time conversation. 
> 
> The most rapid input I can imagine is from a speech-to-text application,
> that maybe can reach 20 characters per second from a rapid speaker. 
> That is why the maximum required rate to support is specified to be 30
> characters per second.

RFC 4103 says that the _default_ value is 30, but where is it said
that the _maximum_ is 30?

> 
> The recommended sample time is 300 ms, resulting in sending 3.3 packets per
> second when there is text to send. With an even caracter rate, that results
> in 9 new characters per packet. 
> 
> With the recommended two generations of redundancy, it will mean that 27
> characters are packed in each packet.
> 
> If they are from a language that make use of three UTF-8 bytes per
> character, there will be a mean of 81 bytes text per packet.
> 
> Add the IPv4, UDP, RTP and RFC2198 overhead of -say 70 bytes, the packet
> size that will be close to maximum is 151 bytes. That is so far from the
> maximum MTU size 
> 
> This is a maximum. In reality, text is usually entered by typing, resulting
> in only 1-4 new characters per packet. 
> 
> Even if the reasoning above tells that there is no risk at all for exceeding
> the maximum MTU-size, the application should follow a reasonable strategy to
> be sure: The application should check so that the maximum MTU is not
> exceeded. If there is a risk for that, excess characters should be delayed
> and transmitted in next regular packet to transmit. 

OK, so your answer is that the PMTU must be considered as an
implicit maximum character transmission rate, and must override the
provided cps if it is higher than the value calculated from the PMTU.

Thanks.

> 
> Gunnar
> 
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Marc
> Petit-Huguenin
> Sent: Saturday, April 18, 2009 5:31 PM
> To: avt at ietf.org
> Subject: [AVT] Another question on RFC 4103
> 
> RFC 4103 does not give any advice on what to do when a t140block to send
> will create an RTP packet that will exceed the PMTU.  Should the PMTU be
> considered as an implicit maximum character transmission rate, or should
> multiple RTP packets with the same timestamp be sent? (for the latter there
> is the additional issue that RFC 2198 does not provide any advice on the
> same problem).
> 
> For example let say that the cps is 30 and the PMTU is unknown so
> 576 bytes is the maximum IPv4 packet size that can be sent.  With 30 cps and
> a language that makes use of three bytes per character, the maximum block
> size is 900 bytes which is more than the maximum IPv4 packet size without
> even counting the overhead.  In this case the maximum implicit cps would be
> 17 cps.

-- 
Marc Petit-Huguenin
Home: marc at petit-huguenin.org
Work: petithug at acm.org