Re: [Standards] Average packet size of XEP-0301
About XEP-0301 In-Band Real-Time Text www.xmpp.org/extensions/xep-0301.html On Fri, May 18, 2012 at 3:43 AM, Darren Sturman darren.stur...@teligent.co.uk wrote: Have you been able to test the formula that you have indicated? ** ** From a user perspective how do you rate word by word transmission as versus character by character. Personally I feel character by character has a smoother and cleaner transmission appearance for the user whereas word by word appears to be unnatural, however a design team member at our customer does not agree. About the formula for XEP-0301 bandwidth: I've been able to test this formula in a narrow variety of scenarios. The rationale of creating a formula is to predict bandwidth, partially because there has not yet been enough tests in a wide enough variety of situations yet. I am working with Gunnar to create a document that I can put on realjabber.org for vendors (like you) that find this data useful. I will email you a draft later today. About character output vs. word output: The XEP-0301 standard permits either way, but most of us personally prefer character output. There are pros and cons of each approach. You can also combine the two (time-smoothed word output) which is a good compromise that I believe Gunnar also likes. Theoretically, it's possible to make this a configurable option (character vs word output) either on the sender end, or on the recipient end. It's easier to do on the sender end, but there are advantages to letting the recipient end do it. I would suggest that you tell your party about this link: http://www.realjabber.org/real_time_text_demo.html And also tell them to read section 6.1.2 and 6.1.4 of XEP-0301: http://xmpp.org/extensions/xep-0301.html#preserving_key_press_intervals You can also tell them that there is already ready-made source code that already takes advantage of key press intervals, too. (for C# and Java projects, other languages coming over the next while) Pros and Cons of character vs word output: There are pros and cons of each approach. Generally, if it's a relay service, text-to-voice, voice-to-text, captioned telephone, stenotype machine, we prefer word output (preferably time-smoothed) since we don't really care about an operator's typing mistakes. However, if it is two deaf people typing directly to each other, most of us prefer keypress output. Normally, keypress output can become jerky because of network latencies (variable pings). However, XEP-0301 is specially designed preserve key press intervals (in a way fairly immune to ping variances/jitter/etc). Because this is possible with XEP-0301, we prefer to be able to see the emotion of typing. However, not everybody likes watching typing mistakes, but generally we found that most people we've chatted to prefer being able to see the typing flow naturally. Example of typing emotion: Look at the calm-versus-panicked typing at the beginning and the end of http://www.realjabber.org/real_time_text_demo.html and you can tell the difference between error-free calm typing and panicked hurried typing. You can't tell the difference if you don't preserve key press intervals. Compromise Idea: If this is a highly polarized or sensitive issue that can stall a project -- a diplomatic solution -- make it a configurable option (even just internally), and later let the customer decide or let the end-user choose in Preferences. Although it's easier to make this a configurable option on the sender end, it is preferable to make it a configurable option on the recipient side where the recipient's screen redraws the real-time-text buffer only when spacebar is rendered, or when a small amount of time elapsed with no incoming real time text). That way, the sender can send full key presses with intervals, and the recipient software can decide to display word-at-a-time (refresh incoming text when spacebar received, or small idle moment) or display keypress-at-a-time (refresh incoming text during every action element). Please note, on average, the use of Natural Typing (keypress intervals) can make some projects significantly more complicated. However, since ready-made modules (C# and Java) are available, it makes sense to take advantage of Natural Typing for XEP-0301 Cheers, Mark Rejhon Author of XEP-0301 ** Kind Regards ** ** *Darren Sturman BSc (Hons) IT Comp; MSc Soft Dev* *Senior Software Engineer* ** ** Teligent Limited Teligent House 2 Kings Hill Avenue Kings Hill, West Malling Kent ME19 4AQ England, UK ** ** Telephone: +44 (0) 1732 879 694 Mobile:+44 (0) 7968 130 668 Facsmile: +44 (0) 1732 879 601 Email:darren.stur...@teligent.co.uk Skype: darren.sturman.teligent Website: www.teligent.co.uk ** ** [image: Description: cid:image001.gif@01CAC4EF.5BFD8690] ** **
Re: [Standards] Average packet size of XEP-0301
mmm .. I have tested on mobile networks in Netherlands.It has many failures by provider T-mobile. Because quatity of GRPS or 3G are not very good. I have agreed with Gunnar that it's not only specific sitaution. it's now known isusse that capaction of mobile system is not good. Edward Tie On 2012-05-16 06:10, Mark Rejhon wrote: For the record, as an author of XEP-0301, I specifically designed XEP-0301 to have flexibility for a wide variety of situations. The official word (by the author, myself) or XEP-0301, is that there is no specific set average for XEP-0301. For that reason, Gunnar's average is for a very specific situation, and is not necessarily representative of an average appropriate for a telecom, which may already have their infrastructure that warrants different variables than Gunnar's average situation. Sincerely, Mark Rejhon On Tue, May 15, 2012 at 11:17 PM, Gunnar Hellström gunnar.hellst...@omnitor.se mailto:gunnar.hellst...@omnitor.se wrote: We never answered the original question. What is the average packet size of XEP-0301? Here it is: around 370 bytes per packet. Motivation: Still assuming that we send every 700 ms and the typing trate is 5 characters per second. The contribution from the characters will be 5*0.7*20 = 70 bytes per packet. With the general overhead in a packet and the XEP-0301 specific elements, it will be around 370 bytes per packet. The variations caused by variations in the general packet overhead from address length, compression or not, inclusion of various options etc, make it not feasible to predict it more closely. Is this sufficient for your use? Gunnar ___ Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se mailto:gunnar.hellst...@omnitor.se +46708204288 tel:%2B46708204288 Gunnar Hellström skrev 2012-05-15 22:19: In order to get an approximate value, we could check what we get with recommended values for the optional items. 1. I think it is quite common that the overhead in XMPP gets around 300 bytes per packet. (It might be 200 in some conditions.) 2. The recommended rate of packets is one every 700 ms as long as new text is produced. Thus 1.4 packets per second. = 420 bytes per second overhead. 3. The text plus keypress interval information is often 20 bytes per character. ( see XEP-0301 section7.9 ) 5 characters per second is then 100 bytes per second. 4. The sum with this example is 520 bytes per second or 4.2 kbit/s, in 1.4 packets per second. 5. Since the values for overhead were very coarse, we should round off to about 500 bytes/s and 4 kbit/s in 1.5 packets/s. 6. If you select options differently, you will have different results. Gunnar ___ Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se mailto:gunnar.hellst...@omnitor.se +46708204288 tel:%2B46708204288 Mark Rejhon skrev 2012-05-15 20:24: Hello Darren, The bitrate can pretty much range from less than 100 bytes a second (when XEP-0138 compression is used) to several kilobits per second (with Natural Typing at 300ms transmission intervals). Even at the worst case scenario, several kilobits per second is less bitrate than a cell phone call. Also, zero bandwidth is used when typing is not occuring. Also, there is a huge amount of variables that determine the bandwidth, some of which can be controlled by the software implementation: The biggest impact on bandwidth of XEP-0301 are as follows: (1) Is key press intervals being preserved? (Natural Typing) (uses more bandwidth) Section 6.1.1 at http://xmpp.org/extensions/xep-0301.html#text_presentation Animation: http://www.realjabber.org/real_time_text_demo.html (2) What transmission interval is being used? (shorter uses more bandwidth) Section 4.4 at http://xmpp.org/extensions/xep-0301.html#transmission_interval (3) Is XEP-0138 stream compression being used? (uses less bandwidth) See http://xmpp.org/extensions/xep-0138.html (4) Are you using an optimized XMPP server that keeps headers compact? (i.e. eliminates a lot of XMPP payloads such as noarchive indicators or x tags). This overhead is added by Google Talk's servers and adds an additional 100 bytes per message packet. Also, to help get started if you wish, are welcome to take my Apache 2.0 source code (commercial use allowed) to help make it easier to implement XEP-0301 in your network: C# -- http://code.google.com/p/realjabber/source/browse/trunk/CSharp/RealTimeText.cs Java -- http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.java My XEP-0301 standard is designed precisely for the purposes you're
Re: [Standards] Average packet size of XEP-0301
On Thu, May 17, 2012 at 7:20 AM, fam...@xs4all.nl fam...@xs4all.nl wrote: mmm .. I have tested on mobile networks in Netherlands.It has many failures by provider T-mobile. Because quatity of GRPS or 3G are not very good. I have agreed with Gunnar that it's not only specific sitaution. it's now known isusse that capaction of mobile system is not good. That is true, the capacity of many mobile systems are not good. That said, XEP-0301 is very capable of functioning over narrowband GRPS. Bringing this back on topic of Standards, there are many variables controlled by the user, by the XMPP server company and by the cellphone company: 1. Variables caused by XMPP server. When I snoop on the raw XMPP data transmitted to Google Talk, they add a lot of extra data that you can avoid if you run your own server. Some companies may set up their own server (on the public network) that avoids the extra XML that Google Talk adds to XMPP connections, such as noarchive elements and the x/ element. People with control over server deployment, can also choose server infrastructure that supports compression (i.e. TLS or XEP-0138). 2. Variables caused by the network level. The selection of the low level network will also determine whether TCP/IP header compression can be done. Timeouts caused within the routing (i.e. routers, mobile networks, reception loss, etc) can also dictate extra bandwidth required by reconnections or keepalive traffic. 2. Variables caused by the end user. The user may type fast, or slow, more often or less often. The user may have a big buddy list, which adds more data. 3. Variables caused by the author/developer. The author may or may not decide to support stream compression, if the server supports stream compression. The developer may or may not decide to support Natural Typing (keypress interval encoding) The developer may choose a longer or shorter transmission interval. The developer may add or remove data from the XMPP transmission, optimizing for efficiency on non-essential updates Some companies that run a lot of components of the network (i.e. companies like Google and Apple) may actually have control over a lot of these variables (#1 and #3), and it is definitely possible to *reduce the bandwidth of XEP-0301 by more than 90% *for the same typing speed by the end user, while still complying fully with ITU-T Recommendation F.703 of usable real-time text (less than 1 second end-to-end latency) Yes, it is more work if you want to heavily optimize for the bandwidth, but the point remains -- it is possible! Thanks, Mark Rejhon
Re: [Standards] Average packet size of XEP-0301
Some minor edits: On Tue, May 15, 2012 at 4:02 PM, Mark Rejhon webmail...@marky.com wrote: Regarding XEP-0301 at http://www.xmpp.org/extensions/xep-0301.html I have a mathematic formula for the bandwidth of XEP-0301 as follows: The biggest impact on bandwidth of XEP-0301 are as follows: (1) Is key press intervals being preserved? (Natural Typing) (uses more bandwidth) Section 6.1.1 at http://xmpp.org/extensions/xep-0301.html#text_presentation Animation: http://www.realjabber.org/real_time_text_demo.html (2) What transmission interval is being used? (shorter uses more bandwidth) Section 4.4 at http://xmpp.org/extensions/xep-0301.html#transmission_interval (3) Is XEP-0138 stream compression being used? (uses less bandwidth) See http://xmpp.org/extensions/xep-0138.html (4) Are you using an optimized XMPP server that keeps headers compact? (i.e. eliminates a lot of XMPP payloads such as noarchive indicators or x tags). This overhead is added by Google Talk's servers and adds an additional 100 bytes per message packet. [now edited for correctness] *Math Formula for Bandwidth of XEP-0301:* Here is a math formula for estimating the bandwidth of XEP-0301, for regular typing: X = (H + (M + (K * i * N)) * C) * (1 / i) Where: X = Average bandwidth, in bytes per second. H = Average TCP/IP packet header overhead. .40 if using regular headers. .10 if using header compression. (Average. This varies. Adjust appropriately for your network) M = Minimum message overhead in bytes, including rtt and one XEP-0301 action element. .120 if highly optimized XMPP is used. (super compact jid's) .200 if reasonably optimized XMPP is used. (public full jid's, infrequent extra payload) .400 if Google servers is used. K = Number of keypresses per second. (Divide WPM by 12, so use K=5 for 60 WPM) N = Overhead per keypress. .1 if Natural Typing is not used .20 if Natural Typing is used (Average. This varies a bit, i.e. editing vs typing) i = Transmission interval between packets in seconds. Note: Variable is used twice in formula. .Recommended value is between 0.3 to 1.0 C = Compression factor of XMPP .1 if no compression used .Less than 1 if compression used (XEP-0138 or TLS). Use a value of 0.2 for 5:1 ratio. Two edits were made: 1. N=20 instead of N=10 if Natural Typing is used. Gunnar pointed this out, and I realized I neglected to count the bytes of the w/ elements in addition to the bytes of the other action elements such as t/. 2. One pair of missing parantheses have been added. Recalculating the bandwidth of XEP-0301 with these minor adjustments, result in only a minor change to the calculated answers (a few bytes per second). Thanks, Mark Rejhon
Re: [Standards] Average packet size of XEP-0301
On Tue May 15 21:19:09 2012, Gunnar Hellström wrote: 1. I think it is quite common that the overhead in XMPP gets around 300 bytes per packet. (It might be 200 in some conditions.) Where did this figure come from? -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Average packet size of XEP-0301
Dave Cridland skrev 2012-05-16 21:45: On Tue May 15 21:19:09 2012, Gunnar Hellström wrote: 1. I think it is quite common that the overhead in XMPP gets around 300 bytes per packet. (It might be 200 in some conditions.) Where did this figure come from? My own brief observations, mainly using Google Talk and RealJabber. Do you have more figures? /Gunnar
Re: [Standards] Average packet size of XEP-0301
Hello Darren, The bitrate can pretty much range from less than 100 bytes a second (when XEP-0138 compression is used) to several kilobits per second (with Natural Typing at 300ms transmission intervals). Even at the worst case scenario, several kilobits per second is less bitrate than a cell phone call. Also, zero bandwidth is used when typing is not occuring. Also, there is a huge amount of variables that determine the bandwidth, some of which can be controlled by the software implementation: The biggest impact on bandwidth of XEP-0301 are as follows: (1) Is key press intervals being preserved? (Natural Typing) (uses more bandwidth) Section 6.1.1 at http://xmpp.org/extensions/xep-0301.html#text_presentation Animation: http://www.realjabber.org/real_time_text_demo.html (2) What transmission interval is being used? (shorter uses more bandwidth) Section 4.4 at http://xmpp.org/extensions/xep-0301.html#transmission_interval (3) Is XEP-0138 stream compression being used? (uses less bandwidth) See http://xmpp.org/extensions/xep-0138.html (4) Are you using an optimized XMPP server that keeps headers compact? (i.e. eliminates a lot of XMPP payloads such as noarchive indicators or x tags). This overhead is added by Google Talk's servers and adds an additional 100 bytes per message packet. Also, to help get started if you wish, are welcome to take my Apache 2.0 source code (commercial use allowed) to help make it easier to implement XEP-0301 in your network: C# -- http://code.google.com/p/realjabber/source/browse/trunk/CSharp/RealTimeText.cs Java -- http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.java My XEP-0301 standard is designed precisely for the purposes you're interested in! Once you can answer the variables #1,2,3,4, I can give you more accurate bandwidth estimates to your questions. Cheers, Mark Rejhon, deafie computer programmer Author of XEP-0301 On Mon, May 14, 2012 at 6:25 AM, Darren Sturman darren.stur...@teligent.co.uk wrote: Hi Mark ** ** I am proposing the use of XEP-0301 for Web and Smart Phone apps for a deaf telephony system in the UK. ** ** Could you give me an estimate of the bandwidth requirements for the following: **· **Connected user who is idle **o **I am assuming “XEP-0199: XMPP Ping” which from a forum I see is approx. 22 bytes/second – is this correct? **· **Connected user conversation **o **What is the average packet size assuming one packet is transmitted per second? **o **Assuming an average user types at 60 words per minute **§ **This would equate to 1 word per second which is classified as an average of 5 characters **§ **What is the XMPP packet size minus the actual typed text? I have seen on one forum that is approx. 200 bytes **· **So 200 bytes plus 5 bytes for 5 typed characters? ** ** ** ** Kind Regards ** ** *Darren Sturman BSc (Hons) IT Comp; MSc Soft Dev* *Senior Software Engineer* ** ** Teligent Limited Teligent House 2 Kings Hill Avenue Kings Hill, West Malling Kent ME19 4AQ England, UK ** ** Telephone: +44 (0) 1732 879 694 Mobile:+44 (0) 7968 130 668 Facsmile: +44 (0) 1732 879 601 Email:darren.stur...@teligent.co.uk Skype: darren.sturman.teligent Website: www.teligent.co.uk ** ** [image: Description: cid:image001.gif@01CAC4EF.5BFD8690] ** ** Disclaimer: The information in this email is confidential. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient, please notify the sender immediately at the above address. The sender cannot accept any responsibility for the accuracy or completeness of this message as it has been transmitted over a public network. If you suspect that the message may have been intercepted or amended, please contact the sender. ** ** Teligent Ltd is registered in England and Wales, registration number 2893478, registered office Lion House, Red Lion Street, London WC1R 4GB. VAT registration GB639938577 ** ** image001.gif
Re: [Standards] Average packet size of XEP-0301
Regarding XEP-0301 at http://www.xmpp.org/extensions/xep-0301.html I have a mathematic formula for the bandwidth of XEP-0301 as follows: The biggest impact on bandwidth of XEP-0301 are as follows: (1) Is key press intervals being preserved? (Natural Typing) (uses more bandwidth) Section 6.1.1 at http://xmpp.org/extensions/xep-0301.html#text_presentation Animation: http://www.realjabber.org/real_time_text_demo.html (2) What transmission interval is being used? (shorter uses more bandwidth) Section 4.4 at http://xmpp.org/extensions/xep-0301.html#transmission_interval (3) Is XEP-0138 stream compression being used? (uses less bandwidth) See http://xmpp.org/extensions/xep-0138.html (4) Are you using an optimized XMPP server that keeps headers compact? (i.e. eliminates a lot of XMPP payloads such as noarchive indicators or x tags). This overhead is added by Google Talk's servers and adds an additional 100 bytes per message packet. *Math Formula for Bandwidth of XEP-0301:* Here is a math formula for estimating the bandwidth of XEP-0301, for regular typing: X = H + (M + (K * i * N)) * C * (1 / i) Where: X = Average bandwidth, in bytes per second. H = Average TCP/IP packet header overhead. .40 if using regular headers. .10 if using header compression. (Average. This varies. Adjust appropriately for your network) M = Minimum message overhead in bytes, including rtt and one XEP-0301 action element. .120 if highly optimized XMPP is used. (super compact jid's) .200 if reasonably optimized XMPP is used. (public full jid's, infrequent extra payload) .400 if Google servers is used. K = Number of keypresses per second. (Divide WPM by 12, so use K=5 for 60 WPM) N = Overhead per keypress. .1 if Natural Typing is not used .10 if Natural Typing is used (Average. This varies a bit, i.e. editing vs typing) i = Transmission interval between packets in seconds. Note: Variable is used twice in formula. .Recommended value is between 0.3 to 1.0 C = Compression factor of XMPP .1 if no compression used .Less than 1 if compression used (XEP-0138 or TLS). Use a value of 0.2 for 5:1 ratio. _ *Low Bandwidth XEP-0301 Scenario:* A compact packet from a deaf-optimized XMPP network with compact headers could be: message to='u1152' from='u5168' type='chat' id='a1'rtt xmlns='urn:xmpp:rtt:0' seq='1234'tHELLO/t/rtt/message This is only 120 bytes to transmit five keypresses HELLO with no Natural Typing. 5 keypresses per second equals 60 WPM. Throw in TCP header compression and XEP-0138 stream compression and, presto, less than 50 bytes a second for ultra-efficient real-time text despite it being a XML based standard! Use TCP compression headers to reduce header overhead. No problem even for old-fashioned GPRS networks and slow Iridium Satellite networks! Variables: H=10, M=120, K=5, N=1, i=0.7, C=0.2 Formula: X = H + (M + (K * i * N)) * C * (1 / i) X = 10 + (120 + (5 * 0.7 * 1)) * 0.2 * (1 / 0.7) X ~= 10 + (120 + 3.5) * 0.2 * 1.43 X ~= 10 + 123.5 * 0.2 * 1.43 X ~= 10 + 35.3 X ~= 45 bytes per second! Rounded to the nearest byte, the low bandwidth XEP-0301 becomes an average of only 45 bytes per second for 60 words per minute typing in real time text at 0.7 second transmission interval! That is you're using compression, including TCP header compression _and_ stream compression. Small enough to squeeze over GPRS, dialup, and satellite. _ *High Bandwidth XEP-0301 Scenario:* An example bulky packet with Natural Typing, is the one in Example 7.9: http://xmpp.org/extensions/xep-0301.html#full_message_including_key_press_intervals Notice how each keypress has some bulky payload data to encode the key press intervals. Throw in Google padding, the TCP header and bulky addresses, and you're approaching 400 bytes per packet. Let's assume you are keeping the transmission interval the same, at 0.7 seconds too. Let's assume you're not using any compression at all. Variables: H=40, M=400, K=5, N=10, i=0.7, C=1 Formula: X = H + (M + (K * i * N)) * C * (1 / i) X = 40 + (400 + (5 * 0.7 * 10)) * 1 * (1 / 0.7) X ~= 40 + (400 + 35) * 1 * 1.43 X ~= 40 + 435 * 1 * 1.43 X ~= 40 + 622 X ~= 662 bytes per second In this high-bandwidth scenario, 662 bytes per second is about 5 kilobits per second. Throw in some stream compression and use a variable C of 0.2, you can get it down to 164 bytes per second with Natural Typing. So you can still have Natural Typing at less than 200 bytes per second, if using a compressed stream to the XMPP server. * * *TIP: You could automatically use High Bandwidth mode for EDGE/3G/LTE networks, and adjust certain variables automatically for older GPRS networks. **This will produce high-fidelity real time text like http://www.realjabber.org/real_time_text_demo.html when the network speed is sufficient.* * * I hope this answers your question, Cheers, Mark Rejhon, deafie computer
Re: [Standards] Average packet size of XEP-0301
On Tue, May 15, 2012 at 4:02 PM, Mark Rejhon webmail...@marky.com wrote: Regarding XEP-0301 at http://www.xmpp.org/extensions/xep-0301.html I have a mathematic formula for the bandwidth of XEP-0301 as follows: *Math Formula for Bandwidth of XEP-0301:* Here is a math formula for estimating the bandwidth of XEP-0301, for regular typing: X = H + (M + (K * i * N)) * C * (1 / i) Where: X = Average bandwidth, in bytes per second. H = Average TCP/IP packet header overhead. .40 if using regular headers. .10 if using header compression. (Average. This varies. Adjust appropriately for your network) M = Minimum message overhead in bytes, including rtt and one XEP-0301 action element. .120 if highly optimized XMPP is used. (super compact jid's) .200 if reasonably optimized XMPP is used. (public full jid's, infrequent extra payload) .400 if Google servers is used. K = Number of keypresses per second. (Divide WPM by 12, so use K=5 for 60 WPM) N = Overhead per keypress. .1 if Natural Typing is not used .10 if Natural Typing is used (Average. This varies a bit, i.e. editing vs typing) i = Transmission interval between packets in seconds. Note: Variable is used twice in formula. .Recommended value is between 0.3 to 1.0 C = Compression factor of XMPP .1 if no compression used .Less than 1 if compression used (XEP-0138 or TLS). Use a value of 0.2 for 5:1 ratio. Addendum, one minor correction to the math formula. X = H + (M + (K * i * N)) * C * (1 / i) Should be: X = (H + (M + (K * i * N)) * C) * (1 / i) As a result, the H variable (TCP header) is now included in the i variable calculation (interval). However, this only changes calculations by a few percent. Still less than 50 bytes per second for optimized/compressed XEP-0301 without natural typing. Thanks Mark Rejhon
Re: [Standards] Average packet size of XEP-0301
In order to get an approximate value, we could check what we get with recommended values for the optional items. 1. I think it is quite common that the overhead in XMPP gets around 300 bytes per packet. (It might be 200 in some conditions.) 2. The recommended rate of packets is one every 700 ms as long as new text is produced. Thus 1.4 packets per second. = 420 bytes per second overhead. 3. The text plus keypress interval information is often 20 bytes per character. ( see XEP-0301 section7.9 ) 5 characters per second is then 100 bytes per second. 4. The sum with this example is 520 bytes per second or 4.2 kbit/s, in 1.4 packets per second. 5. Since the values for overhead were very coarse, we should round off to about 500 bytes/s and 4 kbit/s in 1.5 packets/s. 6. If you select options differently, you will have different results. Gunnar ___ Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se +46708204288 Mark Rejhon skrev 2012-05-15 20:24: Hello Darren, The bitrate can pretty much range from less than 100 bytes a second (when XEP-0138 compression is used) to several kilobits per second (with Natural Typing at 300ms transmission intervals). Even at the worst case scenario, several kilobits per second is less bitrate than a cell phone call. Also, zero bandwidth is used when typing is not occuring. Also, there is a huge amount of variables that determine the bandwidth, some of which can be controlled by the software implementation: The biggest impact on bandwidth of XEP-0301 are as follows: (1) Is key press intervals being preserved? (Natural Typing) (uses more bandwidth) Section 6.1.1 at http://xmpp.org/extensions/xep-0301.html#text_presentation Animation: http://www.realjabber.org/real_time_text_demo.html (2) What transmission interval is being used? (shorter uses more bandwidth) Section 4.4 at http://xmpp.org/extensions/xep-0301.html#transmission_interval (3) Is XEP-0138 stream compression being used? (uses less bandwidth) See http://xmpp.org/extensions/xep-0138.html (4) Are you using an optimized XMPP server that keeps headers compact? (i.e. eliminates a lot of XMPP payloads such as noarchive indicators or x tags). This overhead is added by Google Talk's servers and adds an additional 100 bytes per message packet. Also, to help get started if you wish, are welcome to take my Apache 2.0 source code (commercial use allowed) to help make it easier to implement XEP-0301 in your network: C# -- http://code.google.com/p/realjabber/source/browse/trunk/CSharp/RealTimeText.cs Java -- http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.java My XEP-0301 standard is designed precisely for the purposes you're interested in! Once you can answer the variables #1,2,3,4, I can give you more accurate bandwidth estimates to your questions. Cheers, Mark Rejhon, deafie computer programmer Author of XEP-0301 On Mon, May 14, 2012 at 6:25 AM, Darren Sturman darren.stur...@teligent.co.uk wrote: Hi Mark I am proposing the use of XEP-0301 for Web and Smart Phone apps for a deaf telephony system in the UK. Could you give me an estimate of the bandwidth requirements for the following: · Connected user who is idle o I am assuming “XEP-0199: XMPP Ping” which from a forum I see is approx. 22 bytes/second – is this correct? · Connected user conversation o What is the average packet size assuming one packet is transmitted per second? o Assuming an average user types at 60 words per minute § This would equate to 1 word per second which is classified as an average of 5 characters § What is the XMPP packet
Re: [Standards] Average packet size of XEP-0301
On Tue, May 15, 2012 at 4:19 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: In order to get an approximate value, we could check what we get with recommended values for the optional items. [snip] 5. Since the values for overhead were very coarse, we should round off to about 500 bytes/s and 4 kbit/s in 1.5 packets/s. Yep -- Gunnar described almost exactly High Bandwidth Scenario. His independent calculations and analysis proves my formula is pretty accurate. Thanks Mark Rejhon
Re: [Standards] Average packet size of XEP-0301
We never answered the original question. "What is the average packet size of XEP-0301?" Here it is: around 370 bytes per packet. Motivation: Still assuming that we send every 700 ms and the typing trate is 5 characters per second. The contribution from the characters will be 5*0.7*20 = 70 bytes per packet. With the general overhead in a packet and the XEP-0301 specific elements, it will be around 370 bytes per packet. The variations caused by variations in the general packet overhead from address length, compression or not, inclusion of various options etc, make it not feasible to predict it more closely. Is this sufficient for your use? Gunnar ___ Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se +46708204288 Gunnar Hellström skrev 2012-05-15 22:19: In order to get an approximate value, we could check what we get with recommended values for the optional items. 1. I think it is quite common that the overhead in XMPP gets around 300 bytes per packet. (It might be 200 in some conditions.) 2. The recommended rate of packets is one every 700 ms as long as new text is produced. Thus 1.4 packets per second. = 420 bytes per second overhead. 3. The text plus keypress interval information is often 20 bytes per character. ( see XEP-0301 section7.9 ) 5 characters per second is then 100 bytes per second. 4. The sum with this example is 520 bytes per second or 4.2 kbit/s, in 1.4 packets per second. 5. Since the values for overhead were very coarse, we should round off to about 500 bytes/s and 4 kbit/s in 1.5 packets/s. 6. If you select options differently, you will have different results. Gunnar ___ Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se +46708204288 Mark Rejhon skrev 2012-05-15 20:24: Hello Darren, The bitrate can pretty much range from less than 100 bytes a second (when XEP-0138 compression is used) to several kilobits per second (with Natural Typing at 300ms transmission intervals). Even at the worst case scenario, several kilobits per second is less bitrate than a cell phone call. Also, zero bandwidth is used when typing is not occuring. Also, there is a huge amount of variables that determine the bandwidth, some of which can be controlled by the software implementation: The biggest impact on bandwidth of XEP-0301 are as follows: (1) Is key press intervals being preserved? (Natural Typing) (uses more bandwidth) Section 6.1.1 at http://xmpp.org/extensions/xep-0301.html#text_presentation Animation: http://www.realjabber.org/real_time_text_demo.html (2) What transmission interval is being used? (shorter uses more bandwidth) Section 4.4 at http://xmpp.org/extensions/xep-0301.html#transmission_interval (3) Is XEP-0138 stream compression being used? (uses less bandwidth) See http://xmpp.org/extensions/xep-0138.html (4) Are you using an optimized XMPP server that keeps headers compact? (i.e. eliminates a lot of XMPP payloads such as noarchive indicators or x tags). This overhead is added by Google Talk's servers and adds an additional 100 bytes per message packet. Also, to help get started if you wish, are welcome to take my Apache 2.0 source code (commercial use allowed) to help make it easier to implement XEP-0301 in your network: C# -- http://code.google.com/p/realjabber/source/browse/trunk/CSharp/RealTimeText.cs Java -- http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.java My XEP-0301 standard is designed precisely for the purposes you're interested in! Once you can answer the variables #1,2,3,4, I can give you more accurate bandwidth estimates to your questions. Cheers, Mark Rejhon, deafie computer programmer Author of XEP-0301 On Mon, May 14, 2012 at 6:25 AM, Darren Sturman darren.stur...@teligent.co.uk wrote: Hi Mark
Re: [Standards] Average packet size of XEP-0301
For the record, as an author of XEP-0301, I specifically designed XEP-0301 to have flexibility for a wide variety of situations. The official word (by the author, myself) or XEP-0301, is that there is no specific set average for XEP-0301. For that reason, Gunnar's average is for a very specific situation, and is not necessarily representative of an average appropriate for a telecom, which may already have their infrastructure that warrants different variables than Gunnar's average situation. Sincerely, Mark Rejhon On Tue, May 15, 2012 at 11:17 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: We never answered the original question. What is the average packet size of XEP-0301? Here it is: around 370 bytes per packet. Motivation: Still assuming that we send every 700 ms and the typing trate is 5 characters per second. The contribution from the characters will be 5*0.7*20 = 70 bytes per packet. With the general overhead in a packet and the XEP-0301 specific elements, it will be around 370 bytes per packet. The variations caused by variations in the general packet overhead from address length, compression or not, inclusion of various options etc, make it not feasible to predict it more closely. Is this sufficient for your use? Gunnar ___ Gunnar Hellström omnitorgunnar.hellst...@omnitor.se+46708204288 Gunnar Hellström skrev 2012-05-15 22:19: In order to get an approximate value, we could check what we get with recommended values for the optional items. 1. I think it is quite common that the overhead in XMPP gets around 300 bytes per packet. (It might be 200 in some conditions.) 2. The recommended rate of packets is one every 700 ms as long as new text is produced. Thus 1.4 packets per second. = 420 bytes per second overhead. 3. The text plus keypress interval information is often 20 bytes per character. ( see XEP-0301 section7.9 ) 5 characters per second is then 100 bytes per second. 4. The sum with this example is 520 bytes per second or 4.2 kbit/s, in 1.4 packets per second. 5. Since the values for overhead were very coarse, we should round off to about 500 bytes/s and 4 kbit/s in 1.5 packets/s. 6. If you select options differently, you will have different results. Gunnar ___ Gunnar Hellström omnitorgunnar.hellst...@omnitor.se+46708204288 Mark Rejhon skrev 2012-05-15 20:24: Hello Darren, The bitrate can pretty much range from less than 100 bytes a second (when XEP-0138 compression is used) to several kilobits per second (with Natural Typing at 300ms transmission intervals). Even at the worst case scenario, several kilobits per second is less bitrate than a cell phone call. Also, zero bandwidth is used when typing is not occuring. Also, there is a huge amount of variables that determine the bandwidth, some of which can be controlled by the software implementation: The biggest impact on bandwidth of XEP-0301 are as follows: (1) Is key press intervals being preserved? (Natural Typing) (uses more bandwidth) Section 6.1.1 at http://xmpp.org/extensions/xep-0301.html#text_presentation Animation: http://www.realjabber.org/real_time_text_demo.html (2) What transmission interval is being used? (shorter uses more bandwidth) Section 4.4 at http://xmpp.org/extensions/xep-0301.html#transmission_interval (3) Is XEP-0138 stream compression being used? (uses less bandwidth) See http://xmpp.org/extensions/xep-0138.html (4) Are you using an optimized XMPP server that keeps headers compact? (i.e. eliminates a lot of XMPP payloads such as noarchive indicators or x tags). This overhead is added by Google Talk's servers and adds an additional 100 bytes per message packet. Also, to help get started if you wish, are welcome to take my Apache 2.0 source code (commercial use allowed) to help make it easier to implement XEP-0301 in your network: C# -- http://code.google.com/p/realjabber/source/browse/trunk/CSharp/RealTimeText.cs Java -- http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.java My XEP-0301 standard is designed precisely for the purposes you're interested in! Once you can answer the variables #1,2,3,4, I can give you more accurate bandwidth estimates to your questions. Cheers, Mark Rejhon, deafie computer programmer Author of XEP-0301 On Mon, May 14, 2012 at 6:25 AM, Darren Sturman darren.stur...@teligent.co.uk wrote: Hi Mark I am proposing the use of XEP-0301 for Web and Smart Phone apps for a deaf telephony system in the UK. Could you give me an estimate of the bandwidth requirements for the following: · Connected user who is idle o I am assuming “XEP-0199: XMPP Ping” which from a forum I see is approx. 22 bytes/second – is this correct? · Connected user conversation o What is the average packet size assuming
