[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Another question on RFC 4103
Marc,
See answers inline:
Gunnar
-----Original Message-----
From: Marc Petit-Huguenin [mailto:petithug at acm.org]
Sent: Saturday, April 18, 2009 10:15 PM
To: Gunnar Hellstrom
Cc: avt at ietf.org
Subject: Re: [AVT] Another question on RFC 4103
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.
<GH: The application is allowed to smear the transmission over a number of
packets so that any known MTU size limit can be obeyed. >
>
> 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?
<GH: No, that is right. But in a couple of places it is said that it is
intended for human conversation and that automatic transmission of large
texts shall be avoided. Your example though, of pasting a URL into the text
stream is a good and valid example of actions that are common between
real-time text users, and one of the great benefits of complementing the
voice channel with a real-time text channel in the call. (Your example of a
URL with 300 bytes is a bit unusually long but can appear.)>
>
> 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.
<GH: No, if you really have a low limit in allowed datagram size, I suggest
that you occasionally reduce the packet interval. Not to zero as you
proposed, because that is not allowed in RTP, but just as much shorter than
300 ms as you need to get your long text transmitted.
Or do you have any other proposal for how to handle your case? >
Gunnar
--------------
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
__________ NOD32 4018 (20090418) Information __________
Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com