Subject: [AVT] Another question on RFC 4103

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 18 Apr 2009 08:31:00 -0700

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: [email-masked]
Work: [email-masked]

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sat, 18 Apr 2009 21:33:02 +0200

Marc,
My calculations end up a factor 10 lower than yours.

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.

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. 

Gunnar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc
Petit-Huguenin
Sent: Saturday, April 18, 2009 5:31 PM
To: [email-masked]
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: [email-masked]
Work: [email-masked]
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

__________ NOD32 4018 (20090418) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 18 Apr 2009 13:14:52 -0700

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

> That is why the maximum required rate to support is specified to be 30

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

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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sun, 19 Apr 2009 23:03:37 +0200

Marc,
See answers inline: 

Gunnar
-----Original Message-----
From: Marc Petit-Huguenin [mailto:[email-masked]] 
Sent: Saturday, April 18, 2009 10:15 PM
To: Gunnar Hellstrom
Cc: [email-masked]
Subject: Re: [AVT] Another question on RFC 4103

> 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 

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Marc Petit-Huguenin
> 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).
> 

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 19 Apr 2009 14:59:57 -0700

> Subject: Re: [AVT] Another question on RFC 4103

[...]

> Or do you have any other proposal for how to handle your case? >    

I am not proposing anything, I am just trying to understand how this
is supposed to work.  My current understanding is that the cps is an
average of the 10 last seconds but that text blocks that creates RTP
packets exceeding the path MTU must be smoothed off multiple RTP
packets.

Thanks.