[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] I-DAction: draft-hellstrom-simple-text-transmission-00.txt - the need
Paul and all,
Here is the research that convinced me that real-time text IM is a
mainstream desire.
http://www.cc.gatech.edu/~everyday-computing/projects/im/pubs/tensionsInIM-c
hi2002.pdf
The authors try to invent methods to avoid the traditional tensions
appearing in IM when it gets a bit intensive. Strangely enough, they do not
suggest time-sampled transmission, that solves most of the mentioned
tensions.
But we in this group now know that time-sampled transmission is the solution
for modern intensive IM.
Since MSRP is just about to be implemented, it is a good opportunity to
settle application rules to MSRP so that it can be used with time-sampled
transmission.
I think it would be sad to give up with MSRP and start defining another
protocol, like TOTE. That would just increase the confusion and complexity
and reduce the opportunity for MSRP messaging users to get their messaging
exchange more lively. I think we should search our solution among the 5
alternatives I presented in an earlier posting on this thread.
Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom at omnitor.se
Tel: +46708204288
www.omnitor.se
-----Original Message-----
From: Paul E. Jones [mailto:paulej at packetizer.com]
Sent: Friday, March 21, 2008 5:57 PM
To: 'Dean Willis'
Cc: '"'Gunnar Hellström'"'; 'Simple WG'; Erik.Zetterstrom at omnitor.se; 'Gregg
Vanderheiden'
Subject: RE: [Simple] I-DAction:
draft-hellstrom-simple-text-transmission-00.txt - the need
Dean, at al,
Re-inventing SCTP with what? RTT support or MSRP in general?
In any case, I do not think TOTE is the right solution. I've also seen a
proposal to send RFC 4103 in parallel to MSRP. I believe anything that is
outside of MSRP should be off the table for discussion, because anything
else would:
1) Create a special solution for deaf users
2) Create more work for everybody (phones, SBCs, softswitches, etc.)
3) Require special consideration for all manufacturers and network
operators who
must comply with regulatory requirements
I believe it is imperative that we bring to market a single IM solution for
SIP that works. Thus far, that's not happened and I was excited by the
prospect that MSRP might make that happen. I personally want a solution
that is as natural as possible and will not present significant complexity
to implement and deploy.
I believe it is important to question whether we need real-time text.
Personally, I do not think we do. However, many of the folks I've worked
with in the deaf community feel we do. Who am I to say what the deaf
community needs? In my view, if there is a significant portion of our
global population that feels they need RTT, then we should find a way to
make it work if there is a way to do it.
MSRP is designed in such a way that we can enable it to support RTT without
making great leaps. Using the chunking method already defined within MSRP
is fairly straight-forward. The only thing I see it doing is increasing the
bandwidth and number of packets that need to be processed. As Geir Arne
rightly point out, text packets are nothing compared to the processing of
50pps of audio and become a blip on the radar compared to video. Further,
there is nothing "illegal" about sending 1 character per packet today, so...
what would a system do? It must handle it.
I think it is important to decide whether we want to create an IM system
that will work in the same way for RTT and non-RTT. I would argue that it's
a heck of a lot easier to accommodate both with MSRP than to consider
separate solutions. I want to find a way that will reduce complexity,
reduce cost of development and deployment, and will enable us to meet
forthcoming regulatory requirements.
Paul
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com]
> Sent: Monday, March 17, 2008 2:29 PM
> To: Paul E. Jones
> Cc: "'Gunnar Hellström'"; 'Simple WG'; Erik.Zetterstrom at omnitor.se;
> 'Gregg Vanderheiden'
> Subject: Re: [Simple] I-DAction: draft-hellstrom-simple-text-
> transmission-00.txt - the need
>
>
> On Mar 16, 2008, at 3:48 PM, Paul E. Jones wrote:
>
> >
> > What do you mean by "the transport system"? I thought the argument
> > we were making was for using MSRP as the transport. Honestly, I
> > would think that if we present a strong-enough case for the first
> > question ("why RTT?"), then I suspect there would be little debate
> > over using MSRP. And, I still think those arguing against MSRP have
> > weaknesses in their systems. Our engineers certainly were open to
> > it.
>
> The problem as I understand it is fundamental to the way MSRP is
> currently specified.
>
> MSRP relays may (and probably will) bundle up small packets into large
> ones. That is, they'll strip the real-time right out of the text.
>
> Now, I personally feel MSRP is over-specified. It has all sorts of
> neat capabilities for muxing and controlling independent flows that
> I've heard it said we've reinvented SCTP. But it is what it is, and
> that's an awkward beast for carrying RTT.
>
> To meet the requirements of RTT, we need something that is lighter
> than MSRP, but still has the reliability and congestion control of TCP.
>
> I think this makes RTT an ideal candidate for something like the TOTE
> session protocol described in:
>
> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt
>
> I'm interested in getting a BOF going to look at multi-purpose session
> protocols suitable for end-to-end use in a session initiated by SIP or
> other rendezvous protocols. I think RTT provides a great use-case for
> such a protocol.
>
> --
> Dean
>
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple