Subject: RE: [Simple] Using MSRP for real time text conversation

From: [email-masked]
Date: Mon, 28 Jun 2004 11:37:58 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Gunnar Hellstrom
> Sent: 26.June.2004 10:38
> To: STF267; SIMPLE; Toip list
> Subject: [Simple] Using MSRP for real time text conversation
> 
> 
> This is a continuation of the discussion about the 
> feasability of using simple:s instant
> messaging protocol MSRP for real time text conversation.
> 
> (The discussion was held under the subject: "RE: [Simple] RE: 
> [Sipping] RE: text/T140 and
> audio/t140was:[avt]Comments/questions on 
> draft-ietf-avt-rfc2793bis-04". I thought it was
> time to make it more clear what the real subject is.)
> 
> One factor for checking the feasibility of using MSRP for 
> real time text conversation is
> the bandwidth it creates.
> 
> We have just had a discussion about the real time 
> requirements for the real time
> experience of a text conversation. We have an old recommended 
> figure saying that we should
> ship session conencts at least every 300 ms.

Where did this figure come from? What does it mean in practice? Who recommended it and why is it needed?

> This is 
> confirmed to give a good real time
> experience. Some voices have been for transmission more 
> often, but I think they are not
> based on real experienced needs. Transmission less often 
> creates an unpleasant chunkiness
> in the perception of the dialogue.
> 
> So, for now, let us assume that transmission in 300 ms 
> intervals is used (when there is
> new text available for transmission ).
> 
> I made a calculation of a normal MSRP based text conversation 
> exchange with material from
> the MSRP specification.

I don't understand why you would send the MSRP message before a user has finished typing it. MSRP is for conversations between participants using intant messages. It follows the definitions and requirements defined in RFC2778 and RFC2779 respectively.

If you have requirements for real time character by character text sending with video for the hearing impared, for example, then you might consider not using MSRP at all since this was not a requirement for it. Again, MSRP is for conversations, mainly text.

Regards,
Hisham

> 
> This is the packet that needs to be sent for theree 
> characters of text from the session:
> ------------------Lower level headers - do not bother to calculate
> here----------------------
> --------------------------IP V4 header  20 bytes -----
> ----------------------------TCP header  24 bytes -----
> ----------------------------MRSP SEND -189 bytes-including 3 bytes
> payload--------------------
> MSRP SEND
> Boundary: d93kswow
> To-Path:msrp://bob.atlanta.com:8888/9di4ea
> From-Path:msrp://alicepc.atlanta.com:7777/iau39
> TR-ID: 123
> Message-ID: 123
> Content-Type: "text/t140p"
> Hi,
> -------d93kswow+
> --------------------------------End of SEND request-----------
> 
> So, it sums up to 233 bytes transmission = 1864 bits.
> 
> In order to get the real time experience we should allow 3.3 
> packets per second. That
> makes 6150 bits/second.
> 
> 
> The return direction will have approximately the same load by 
> the 200 OK and the TCP
> acknowledgements.
> 
> 
> So, we would need approximately 6 kbit/s both ways for this 
> text session. Most of it is
> overhead, so it does not change much if we use the highest 
> typing speed we design for,
> that is 30 characters per second and type in Korean that will 
> require 3 bytes UTF-8 per
> character.
> 
> 
> Using RTP, with text/t140 and two generations of redundancy 
> that give good reliability,
> consumes around 2 kbit/s in the same situation.
> 
> 6 kbit/s is a bit high load, but I would say that it is not 
> totally out of scope.
> 
> What do you think?
> 
> Gunnar
> -------------------------------------------
> Gunnar Hellström
> Omnitor AB
> Renathvägen 2
> SE 121 37 Johanneshov
> SWEDEN
> +46 8 556 002 03
> Mob: +46 708 204 288
> www.omnitor.se
> [email-masked]
> --------------------------------------------
> 
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Mon, 28 Jun 2004 21:27:31 +0200

Hisham

------snip------
We have an old recommended
>> ship session contents at least every 300 ms.
>
-------snap------------

The tradition from real time text conversation is that immediate sending gives best
opportunity to have a good conversation.
There are two services defined in ITU with real time text conversation. It is Text
telephony, with the capability to use real time text and voice. View it as a modern
extension to voice telephony. And it is Total Conversation, with an opportunity to use
video, text and voice in a call. View that as a modern extension to video telephony.

These services are defined in ITU-T F.703 Multimedia Conversation service descriptions.
The media involved in the multimedia services are described in ITU-T F.700, where Annex 3
describes the text medium.

There it is stated:
"T2	-  Good text conversation quality characterised by
Font support for all characters in ISO-10646-1
No more than 1 corrupted, dropped or marked missing character per 500.
Delay from character input in the transmitter to display in the receiver shorter than 1
s."

Next level is the presentation level, where ITU-T T.140 is the text cconversation
presentation protocol that specifies in section 6.1.1:

"The requirements and the specific mechanisms for buffering are beyond the scope of this
Recommendation. However if buffering is provided in the data channel, it should not delay
transmission more than 0.5 seconds and not be related to complete lines of input. Any
grouping of data into blocks for transmission should be transparent to the text protocol."

Then we have the transport levels, where we so far have had RFC2793 for RTP packetization
of conversational text, where the following is stated:

"Packets are transmitted when there is valid T.140 data to transmit.

   T.140 specifies that T.140 data MAY be buffered for transmission
   with a maximum buffering time of 500 ms. A buffering time of 300 ms
   is RECOMMENDED, when the application or end-to-end network
   conditions are not known to require another value.  "

This all is to meet the balance between human need of flow in the discussion, and the
technical need of keeping low on bandwidth requirements.

By using real time text conversation you simply relieve the transmittting user from all
stress of finishing a sentence so that the receiver can get it. And you relieve the
receiver from nervous idling waiting for next complete sentence to arrive.

I do not know how so much text handling ended up to become message oriented.

But I know that text messaging is valuable as well as text conversation, and that we need
to provide both services.

Next question:
>I don't understand why you would send the MSRP message before a user has
>finished typing it. MSRP is for conversations between participants using instant
>messages. It follows the definitions and requirements defined in RFC2778 and
>RFC2779 respectively.

What we aim at is not only for hearing impaired users. And even if it was, hearing
impaired users tend to communicate with all users. I admit that the service is essential
for hearing impaired users, but it should be evident from the motivation above that it is
of interest for all.
We are in the era of rapid deployment of real time conversational services in the
Internet, and need to have industry agreements on how to do that most efficiently.

>
>If you have requirements for real time character by character text sending with
>video for the hearing impared, for example, then you might consider not using
>MSRP at all since this was not a requirement for it. Again, MSRP is for
>conversations, mainly text.

Sure, we already have RTP with text/t140 packetization, complete SIP sdp declaration,
awareness among emergency service actors, etc.
So, this is so far only a feasability test initiated by simple members in order to check
if we could gain anything by joining the efforts.

Your views in this discussion are valuable.

Gunnar

>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, June 28, 2004 10:38 AM
>To: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Subject: RE: [Simple] Using MSRP for real time text conversation
>
>
>
>
>I don't understand why you would send the MSRP message before a user has
>finished typing it. MSRP is for conversations between participants using intant
>messages. It follows the definitions and requirements defined in RFC2778 and
>RFC2779 respectively.
>
>If you have requirements for real time character by character text sending with
>video for the hearing impared, for example, then you might consider not using
>MSRP at all since this was not a requirement for it. Again, MSRP is for
>conversations, mainly text.
>
>Regards,
>Hisham
>
>>

---

From: Adam Roach <[email-masked]>
Date: Mon, 28 Jun 2004 16:38:00 -0500

Gunnar:

I'm very confused. Why do you want to use MSRP for T.140 text? You don't 
*need* MSRP to have T.140 conversations. You just carry them like any 
other real-time streams -- isn't that the point of RFC 2793?

  INVITE sip:[email-masked] SIP/2.0
  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
  To: Bob <[email-masked]>
  From: Alice <[email-masked]>;tag=1928301774
  Call-ID: a84b4c76e66710
  CSeq: 314159 INVITE
  Max-Forwards: 70
  Date: Thu, 21 Feb 2002 13:02:03 GMT
  Contact: <sip:[email-masked]>
  Content-Type: application/sdp
  Content-Length: 147
 
  v=0
  o=UserA 2890844526 2890844526 IN IP4 here.com
  s=-
  c=IN IP4 pc33.atlanta.com
  t=0 0
  m=text 49172 RTP/AVP 97
  a=rtpmap:97 t140/1000

What are you trying to do that cannot be accomplished by this?

/a

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 29 Jun 2004 07:49:48 +0200

Adam,
Sorry for the confusion.
Yes, we have what we need for real time text in RTP with text/t140.

The discussion was started by a suggestion that use of MRSP for real time text would cause
a better uptake by the industry.

I do not know how that suggestion can be evaluated. Text/t140 is so easy to do, so it is
merely the understanding of the opportunities that is needed.

--------------------------

A lot has been said about good behaviour in the Internet in the thread, possibly
indicating that using real time text would not be good behaviour in the Internet. I think
it is. With MRSP we saw that we would have a load of about 6 kbit/s when actively typing,
and with text/140 it will be around 2.5 kbit/s when actively typing. Occasional jitter of
1 second is of no major concern. At severe congestion, some hampered conversation could
continue even if buffering was increased to 5 seconds, and that way of handling congestion
is now in rfc2793bis-07 that was published yesterday.

So, with this reasonable behaviour compared to the real time companions voice and video,
who gladly grab 40 kbit/s or more and require to have an even flow, I think text behaves
very well. I hope all are prepared to include it in real time conversational designs in
order to make conversational services a bit more usable for all.

Gunnar

>From: Adam Roach [mailto:[email-masked]]
>Sent: Monday, June 28, 2004 11:38 PM
>To: Gunnar Hellstrom
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Subject: Re: [Simple] Using MSRP for real time text conversation
>
>
>Gunnar:
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jun 2004 10:45:04 -0500

> other real-time streams -- isn't that the point of RFC 2793?

Darn these cross-list discussions. You and Hisham seem to have missed 
the first forty messages in this thread, and reacted with justifiable 
surprise.

Recap, for those who missed the first season of our serial drama:

Gunnar does NOT "want" to use MSRP -- he proposed using T.140 exactly as 
you discussed it above. He also wants real-time text in every phone and 
messaging device produced, for 100% availability, a goal that I find 
agreeable.

However, I don't want to use T.140. Emulating reliability by requiring 
multiple transmissions of every character without regard for real 
network conditions is a horrible violation of the principles of RFC2914.

So, I raised the question: Could we use a reliable and 2914-compliant 
protocol like MSRP to meet the needs of real-time text? We are now 
discussing this possibility, using MSRP as the baseline.

Open questions:

1) Would the user experience be acceptable?

2) What is the bandwidth required, relative to T.140?

3) How much change would this imply for MSRP?

4) How will this affect the widepsread availability of real-time text? 
Cullen has proposed that if this is simple as a check-box in the GUI of 
every MSRP client, then EVERYBODY has eal-time text capability.

5) What are the pros and cons of the various approaches with respect to 
firewalls and NATs? Clearly TCP has some advantages, and MSRP has 
relays, but TURN and STUN give us some existing infrastructure for T.140.

6) is there a sufficient perception of value in the community to justify 
adding this sort of function to MSRP, or would yet another protocol be 
required?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jun 2004 11:03:38 -0500

> order to make conversational services a bit more usable for all.

Being a good citizen of the Internet is not simply a matter of using 
less  bandwidth. It requires the ability to react to degrading network 
conditions by deliberately reducing one's impact on the network as those 
conditions degrade.

T.140 sometimes reacts (if at all -- it might just degrade the user 
experience by losing data) the other way -- by sending MORE packets and 
increasing the effective load as the network decays. This is the sort of 
behavior that drives "congestion collapse" events in networks.

True, the latest 2793bis also talks about backing off the 
inter-character timer (while requiring continued redundant 
transmissions), but this doesn't produce much leverage for congestion 
control. It also doesn't specify when this back off should happen. It 
certainly doesn't mandate congestion-safe behavior. I quote:

    If the application needs to reduce its sending rate, it SHOULD NOT
    reduce the number of redundancy levels below the default amount
    specified in section 4. Instead, the following actions are
    RECOMMENDED in order of priority:

    - Increase the shortest time between transmissions described in
     section 5.1 from the recommended 300 ms to 500 ms that is the
     highest value allowable according to T.140.

    - Limit the maximum rate of characters transmitted.

    - Increase the shortest time between transmissions to a higher
     value, not higher than 5 seconds. This will cause unpleasant
     delays in transmission, beyond what is allowed according to
     T.140, but text will still be conveyed in the session with some
     usability.

We know from our experience in SIP that trying to invent congestion 
management mechanisms that are more application-optimal than TCP is a 
tricky business.

Other possible solutions include using DCCP instead of UDP as the 
underlying transport for real-time text.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Jun 2004 12:16:58 -0400

Couple of comments inline.

	Paul

Dean Willis wrote:
> 
> 
> Adam Roach wrote:
> 
>> Gunnar:
>>
>> I'm very confused. Why do you want to use MSRP for T.140 text? You 
>> don't *need* MSRP to have T.140 conversations. You just carry them 
>> like any other real-time streams -- isn't that the point of RFC 2793?
>>
> 

Good summary.

> 2) What is the bandwidth required, relative to T.140?

Based on the back-of-envelope calculations in the thread, I think the 
conclusion was that it would take about 3 times the bandwidth to do with 
MSRP as it would with T.140 over RTP.

(But of course, since TCP is a better citizen and is flow controlled, in 
times of congestion it might not hurt the network so much. But since it 
is sending 3 times the data, it will get congested more often, and the 
user experience will be bad in more cases.)

> every MSRP client, then EVERYBODY has eal-time text capability.

That effect could be achieved even with separate protocols. It is a 
matter of working out all the interop cases and specifying how it should 
be done.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Jun 2004 13:56:46 -0500

Re-adding my comments to this branch of the thread:

> 2) What is the bandwidth required, relative to T.140?

If you send one char per message, absurdly huge. If you use some of the 
streaming features of MSRP, this might could be somewhat mitigated. But 
this would be an extremely constrained and mutant usage of MSRP as it is 
currently described.

> 3) How much change would this imply for MSRP?

I am assuming the 1 char per message approach is not even on the table. 
If you use a stream approach, you will need loads of new rules about how 
to do this, and how to signal you want to do it.

> every MSRP client, then EVERYBODY has eal-time text capability.

I have no opinion on this. The jury is still out on the wide-spread 
acceptance of MSRP.

> adding this sort of function to MSRP, or would yet another protocol be 

Well, adding this to the MSRP base spec would be long and painful. I am 
in principle opposed to adding any significant new requirements to MSRP, 
as it would put at serious risk of never completing it.

I also don't think that real-time text is in scope, or in charter, for 
SIMPLE.

Now, if we, or someone else, decide(s) that it makes sense to extend 
MSRP to allow this, I am not strongly opposed, as long as it does not 
disrupt work on the base spec. (I am not by that statement indicating 
that I do thing it makes sense.)

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 29 Jun 2004 21:58:19 +0200

Thanks for good summaries and questions.
Comments inline,

>> network conditions is a horrible violation of the principles of RFC2914.

It is not T.140 you are suspicious to, it is to use the RTP packetisation text/t140 as
specified in rfc2793 ( and -bis ) that you have doubts about.

The repetitions are sent together with new characters, and therefore do not cause any
remarkable increase in load.

The unusual characteristics of this rtp packetization makes it not as horrible as you seem
to think.

It is not a true character-by-character transmission. All characters typed during a
buffering interval are transmitted together. The default buffering time is 300 ms. If no
data is available for transmission, no packet is sent.

User spend often more time thinking and reading than they spend typing. So, studying max
values does not give you a good view of the real ( low ) load.

The additional words about actions in case of congestion should be effective. RTCP info
can be the base for increasing buffering time.

>> 1) Would the user experience be acceptable?
With 300 ms between transmissions if there is data, I would expect MSRP to behave just as
well as RTP text/t140, assuming that it gets through NAT and firewalls.

We saw that the bandwidth seems to be 3 times higher for MSRP. If we compensate by
increasing buffering time we reach 1 second buffering time, and that will be regarded too
slow and chunky. 500 ms is the limit.

>this would be an extremely constrained and mutant usage of MSRP as it is
With maximum allowable 500 ms for MSRP it will be 4 kbit/s. With 300 ms buffering it will
be 2 kbit/s for text/t140. 4 kbit/s would not be popular in a mobile situation. Otherwise
it is probably OK. We are dealing with calls where it will be in many cases favourable to
use video and audio as well.
>to do this, and how to signal you want to do it.
Look at 500 ms buffering instead.
Would you dare to recommend it then?

>I have no opinion on this. The jury is still out on the wide-spread

I definitely hope that simple and MSRP gets widespread. The current fragmentation in the I
M world is a severely hampering factor for its message-wise use. Impossible to procure for
official use, impossible to use for public services. I wish you all luck with a
standardised protocol to replace the current situation!

But for its influence on the real time variant, I also want to listen to the word from the
jury...
>> relays, but TURN and STUN give us some existing infrastructure for T.140.

There are also true SIP aware NAT-routers and firewalls that handle SIP and RTP well. I do
not know how well they handle MSRP.
>as it would put at serious risk of never completing it.
Three small things need to be done:
a. Optional real time transmission in 500 ms buffers.
b. MIME declaration of the transmission in a new text/t140p format that is just the plain
UTF-8 coded T.140 transmission.
c. A request on the receiver to add received text for display in one window per
transmitting party.

>that I do thing it makes sense.)
Same here, we have to judge the possible outcome of question 4 above, and balance it
against the influence on already started activities to specify text/t140 as the way to do
text conversation, emergency etc.

Gunnar