Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Gunnar Hellstrom
> Sent: 25.June.2004 21:47
> To: Dean Willis
> Cc: 'Toip list'; [email-masked]
> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140
> was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04
> 
> 
> Dean,
> 
> You seem to claim that MSRP for real time text would behave 
> better in congestion than RTP
> with text/t140.
> 
> I do not think this can be a decision factor for selecting 
> one of these protocols before
> the other.
> 
> RTP for text is not at all causing the continous load as 
> voice and video. Transmission is
> done just when there is text to transmit, and then we have a 
> default transmission rate of
> 3 packets per second.
> 
> In the last edition of rfc2793bis we added a lot of 
> precautions for congestion.
> But we also added that in case of severe congestion, other 
> streams could be cut out, and
> the conversation only continue in text in order for the whole 
> conversational application
> to behave well in the network.
> 
> Here is the last edition -06: ( - 07 should be out any day now )
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-06.txt
> 
> 
> I do not see enough concerns about possibility to combine the 
> text session with
> simultaneous voice in the discussion. The thoughts about MSRP 
> seems to be too far from the
> real time media that I would not yet dare to rely on it as a 
> base for real time text
> during calls.
> 
> I think we would be better off, having a reference in MSRP 
> saying that when there are real
> time requirements, a text/t140 RTP stream SHALL be opened and 
> the text conversation
> performed there instead.

I don't understand why this is MSRP's problem at all. MSRP is built for the reason of instant message conversations, as the draft cleary states. If MSRP does not meet you needs, you are free to implement any other text media protocol you choose, but I do not believe that MSRP is the right place to indicate this.

So, stating in the MSRP draft what MSRP is designed for is enough.

Thanks,
Hisham

> 
> Then we can win-win in getting the mass deployment you expect 
> for IM and the real time
> behaviour that is needed in a more intensive text discussion.
> 
> Planning for emergency service text handling, for gatewaying 
> to text in other networks etc
> could continue as now and we would have a smooth transition 
> and big market for future text
> based services in all time aspects.
> ------
> 
> Did you see my question about what bandwidth an MSRP text 
> session with three payload bytes
> per packet every 300 ms would generate. That figure is 
> important for judging if the
> proposal to use MSRP is at all realistic. You who know MSRP 
> can probably tell this easily.
> 
> ------
> 
> 
> Gunnar
> 
> -------------------------------------------
> Gunnar Hellstrom
> Omnitor AB
> Renathvagen 2
> SE 121 37 Johanneshov
> SWEDEN
> +46 8 556 002 03
> Mob: +46 708 204 288
> www.omnitor.se
> [email-masked]
> --------------------------------------------
> 
> 
> >-----Original Message-----
> >From: Dean Willis [mailto:[email-masked]]
> >Sent: Friday, June 25, 2004 5:33 PM
> >To: Gunnar Hellstrom
> >Cc: 'Toip list'; [email-masked]
> >Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140
> >was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04
> >
> >
> >
> >Gunnar listed out a good set of requirements in RE: [Sipping] RE:
> >text/T140 and audio/t140 was:[avt]Comments/questions on
> >draft-ietf-avt-rfc2793bis-04
> >
> >I'd like to add one requirement that every Internet protocol should
> >meet, but many (especially early protocols) do not.
> >
> >I'll phrase this as one absolutely critical requirement, and 
> a couple of
> >examples of what this means. I'll admit that the examples 
> have a lot of
> >overlap with each other. Perhaps someone has said this 
> better -- if so,
> >somebody please send me a reference . . .
> >
> >Big Requirement: A user of the Internet must not interfere 
> unfairly with
> >other users of the Internet.
> >
> >What does this mean in design terms?
> >
> >1) A protocol or suite of protocols supporting an application MUST be
> >both sensitive and reactive to network behavior in real time.
> >
> >2) A protocol or suite of protocols supporting an 
> application MUST not
> >"flood" network links, stifle or starve other applications, or
> >aggressively try to compensate for network limitations by using more
> >bandwidth.
> >
> >3) A protocol or suite of protocols supporting an 
> application MUST react
> >to network performance issues in a "fail-safe" manner. If there are
> >problems with the network, this means either "backing off" until the
> >situation gets better, or reporting the conditions up the
> >decision-making tree to an agent with the power to terminate 
> or suspend
> >the application operation until things get better (or 
> possibly, that can
> >make things better by taking actions outside the scope of the
> >application protocol).
> >
> >4) A protocol or suite of protocols SHOULD be designed in such a way
> >that implementations of applications using that protocol or suite of
> >protocols meet the above requirements "by default", that is, without
> >special effort on the part of the application builder.
> >
> >5) The best protocols "play nice" by recording network 
> behavior in real
> >time and taking corrective action. This includes things like:
> >
> >a) measuring end-to-end latency, drop rates, jitter, etc. 
> and reducing
> >transmission rates under degraded network conditions, perhaps by
> >changing timing, encoding, buffering, packet size, or flo-control
> >mechanisms.
> >
> >b) Interacting with network nodes to gain additional data 
> about network
> >behavior and using this data to adapt behavior as in A. An 
> example here
> >might be TCP explicit congestion notification (ECN) or frame-relay
> >foward and backward explicit congestion notification (FECN and BECN).
> >
> >What does all this mean to us?
> >
> >Let's thnk about this in the terms of real-time-text and 
> RTP. I'll admit
> >that RTT/RTP can be made to work, even under bad network 
> conditions, but
> >is it a "good citizen" of the internet?
> >
> >Sure, RTCP gives us limited notification capability, and if used
> >carefully in an application could meet most of the fundamental
> >requirement. Problem is, nobody ever does it this way. When 
> was the last
> >time your GTT app popped up and said "I'm observing high loss on this
> >link. Please type slower or give up." This is a failure of #4, above.
> >Developers have to go out of their way to integrate RTCP 
> status with the
> >application and make the application adapt. Many implementors of RTP
> >never get around to doing the RTCP part, and applications 
> quite commonly
> >ignore RTCP even if the stack they're written on supports it.
> >
> >
> >#1 requires that our system sense and react to real network 
> conditions.
> >RTT/RTP as you have outlined it doesn't. Instead, RTT just 
> assumes the
> >network is lossy and congested, and sends things redundantly, obeying
> >its own timers rather than reacting to the ebb and flow of 
> the network
> >beneath it. As a consequence, RTT/RTP violates #2 and #3 as it "out
> >competes" other users by just blasting out redundant transmissions
> >whether they're needed or not.
> >
> >I believe that, if we were designing the protocol today, RTP as it
> >currently exists would not survive the review process. By requiring
> >applications to deal with these complex transport issues, it 
> makes the
> >probability of "well-mannered" implementations quite low. We probably
> >wouldn't use RTP for voice if we had something better-behaved, and we
> >shouldn't use RTP for text when we have the option of using something
> >that's better behaved.
> >
> >Sure, RTP can be made to run with DCCP, and it probably will be some
> >day. But unfortunately, that's probably a few years out before we see
> >any kind of "critical mass", and there'll be a whole new can of
> >firewall/NAT worms to untangle before we can really count on 
> it working
> >in the field.
> >
> >
> >So, what can we do now?
> >
> >Options include:
> >
> >1) Ignore these problems, because somebody else (perhaps the Bush
> >administration) can be counted on to clean them up for us.
> >
> >2) If we really need a synchronous real-time end-to-end 
> network, forget
> >about IP and use ATM for real-time text applications.
> >
> >3) Require RSVP and per-RTT/RTP flow reservations.
> >
> >4) See how close we can get to meeting our real-time needs with a
> >network-friendly protocol like MSRP.
> >
> >
> >Personally, I prefer option 4, which begs the questions:
> >
> >What exactly do we want for real-time text, what part of it cannot be
> >implemented on a network that is not always a real-time 
> network, and can
> >we get close enough to get something useful out of an MSRP-like
> >protocol? And is the SIMPLE working group willing to tackle 
> this mission?
> >
> >
> >
> >Here's a use case:
> >
> >I'm going to chat with Arnoud. I send him a MESSAGE asking 
> if he wants
> >to talk. Arnoud responds by INVITE-ing me to an MSRP session. We
> >exchange a few slow-text messages. As the conversation warms up, we
> >decide switch to real-time text by clicking the "send in real time"
> >buttons on our texters (which I presume just changes the buffering
> >behavior in MSRP). When we're done, we send BYEs. Throughout 
> the whole
> >conversation, the TCP stacks in our devices were making sure 
> we "played
> >nice" with the other network users. Every now and then, the 
> timing was a
> >bit off, but it was pretty close, and we didn't break 
> anybody's network
> >or interfere unfairly with other applications. That's a good 
> way to use
> >the Internet.
> >
> >
> >--
> >Dean
> >
> >
> >
> >
> >
> >
> 
> 
> 
> _______________________________________________
> 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: Dean Willis <[email-masked]>
Date: Mon, 28 Jun 2004 13:47:52 -0500

[email-masked] wrote:

> 
> I don't understand why this is MSRP's problem at all. 
 > MRP is built for the reason of instant message conversations,
> as the draft cleary states. If MSRP does not meet you needs, 
> you are free to implement any other text media protocol you 
> choose, but I do not believe that MSRP is the right place 
> to indicate this.
> 

Ok, let's back up a step. I don't think anyone is suggesting that MSRP 
is currently expected to do real-time text.

We have a set of valid requirements for real-time text. What we're 
discussing is how best to meet those requirements.

I'm asking:

1) Could a congestion-safe protocol like MSRP be adapted to meet the 
requirements of real-time text?

2) If so, would this be better than using RTP? (and remember, "better" 
is a broad and subjective).

3) If so, would the people who are working on MSRP be interested in 
extending its requirement set to address the requirements of real time text?

I believe Hisham is indicating above that he feels that MSRP is either 
an innapropriate starting point, or that as one of the people working on 
MSRP he's not interested in adapting it to meet the requirements of 
real-time text. Do I have that right, Hisham?

--
Dean

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jun 2004 16:11:09 -0500

The fact that this conversation is spread over multiple threads and 
working groups makes it near impossible to track the entire history, so 
I apologize for coming in late, and if I am covering old ground.

Comments inline:

Dean Willis wrote:

>> as the draft cleary states. If MSRP does not meet you needs, you are 
>> free to implement any other text media protocol you choose, but I do 
>> not believe that MSRP is the right place to indicate this.
>>
> 

No. A congestion-safe protocol might, but one like MSRP most certainly 
cannot. MSRP is message oriented. If we get into situations where we 
send one character per message, we will have an absurd overhead rate.

MSRP is designed for a set of problems almost 180 degrees opposite of 
real-time text.

> extending its requirement set to address the requirements of real time 

No. That would involve completely starting over with MSRP, and reduce is 
usefulness for the problem it was intended to solve.

> real-time text. Do I have that right, Hisham?

Not to speak for Hisham, but as the editor of MSRP, I strongly believe 
it is an innappropriate starting point for real-time-text.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jun 2004 16:21:22 -0500

OK, I sent that before entirely thinking it through. The streaming 
capabilities in MSRP might make it possible to deliver what appears to 
be real-time-text without having a whole message per char. But this 
would require a boat-load of restrictions on how the protocol is used 
which I think are way out of scope for MSRP and SIMPLE.

If, after the MSRP base is done, someone wants to specify such an 
extension, I suppose that is their perogative.

Ben Campbell wrote:

>> an innapropriate starting point, or that as one of the people working 
>> on MSRP he's not interested in adapting it to meet the requirements of