RE: [avt] Use of redundancy in rfc2793bis text transmission - optimizing interoperability

["Gunnar Hellstrom" <[e-mail]>]

Magnus, Thanks,

Your suggested action no 3:
3. further increase buffering times beyond 500 ms.
Seems to be the one to prefer, and can also give a good effect.

As said many times already, the amount of increase of load from redundancy,
when we define two redundant generations to be the default, is so minimal
that decreasing to one would have no effect at all on congestion, and
decrease to zero, would be a disaster for the conversation.

In a conversation, if text starts to get through with much longer delays
than normally, the users start backing off, waiting for a response or sign
of life from the others. Since no text is transmitted when no text is
entered this automatically reduces load rapidly. So, in extreme situations
allowing the transmission interval go over the human factors limit of 500
ms would do the job for us.
On the other hand it starts to get dangerous if it happens in an emergency
situation.
I will create some suitable wording.


------------------------------------------
Thanks for the explanation of why TCP was brought into the discussion. My
misunderstanding of the reason caused me to summarize the reasons why we
selected RTP to be the default text transmission environment. We will need
that summary on other occasions.
-----------------------------------------

Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
[phone]
Mob: [phone]
www.omnitor.se
[e-mail]
--------------------------------------------


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of Magnus
> Westerlund
> Sent: Friday, April 16, 2004 1:17 PM
> To: Gunnar Hellstrom
> Cc: [e-mail]; [e-mail]
> Subject: Re: [avt] Use of redundancy in rfc2793bis text transmission -
> optimizing interoperability
>
>
> Hi Gunnar,
>
> I think the congestion consideration section is a required feature.
> However I think the text needs improvement. First I think it should
> reference the relevant sections of RFC 3550, 3551, and 2198.
>
> Secondly, I think that the recommendation part need to reworded. The use
> of "contribute to a large degree" is not acceptable. If the T140 stream
> is sending at a higher bit-rate than what TCP would achieve in a best
> effort network, it needs to take avoidance. The lowest transmission rate
> that a TCP stream sending full 1500 bytes packets can be backed off too,
> is one packet every 2 minutes. That represents a bit-rate of 100 bits
> per second. As one RTP packet without payload per second has higher
> bit-rate I still think there is need to have a consideration. However
> this boils down to that a text sender MUST perform congestion control on
> its stream in a best-effort network.
>
> Third, I think one should give clear recommendations to what do to make
> it possible to reduce the bit-rate for text streams. To my understanding
> the reductions should be made in the following order:
>
> 1. Increase buffering up to limit 500 ms.
> 2. Reduce amount of redundancy until loss rate are at service limit
> 3. further increase buffering times beyond 500 ms.
>
> I would not expect that one would need to do the third option unless the
>   congestion is extreme. However the text stream would need to reduce
> its rate further if it is unfair. Another reason for having this
> consideration is that I think a text user is much more persistent in
> their usage then what a voice call would be, due to the ease of adding
> redundancy.
>
> However I do agree that one will have incredible loss rates to get TCP
> to back off to the level a typing user would result in. If one looks at
> RFC 3714, one could notice that a 4.75 kbps (audio user data) 20 packet
> per second stream, RTT=100 ms is not fair when it experience packet
> losses of 40%. But there are a few assumption here which may not totally
> hold in this scenario. However I don't think there is a major difficulty
> of congestion controlling these text streams. One could use simple
> heuristics principals, like what is outline in 5.4 of RFC 3714. However
> if one is declaring such a heuristic in the specification, you will need
> to have some informative section showing how it is derived.
>
> Finally I would argue that some extra wording in the congestion control
> section is need in regards to pasting text into sessions. I think a
> simple sentence saying:
> "When performing congestion control, the real packet sizes MUST be taken
> into consideration. Although most sessions will only contain a few T.140
> symbols per block, there exist possibility for text pasting or automated
> systems to produce significantly larger packets and bit-rates."
>
> In conclusion:
> - Reference relevant sections in RFC 3550, 3551, 2198.
> - Clarify that congestion control is need in best effort network, even
> though text is small bandwidth.
> - Clarify the actions for reducing the bit-rate.
> - Put in a note about considerations for pasting and automated systems.
>
> The congestion control section needs to be carefully worded, because
> even a mostly correct, but not completely right sentence, results in
> comments.
>
> See further comments inline.
>
>
> Gunnar Hellstrom wrote:
>
> >
> > Another section of the proposed new edition of RFC2793 takes
> up congestion
> > control:
> >
> -----------------------------------------------------------------
> ----------
> > --------------
> > 8.4 Congestion Considerations
> >
> > Even if the network load from users of text conversation
> usually is very
> > low, consideration should be paid to the contribution to
> network congestion
> > caused by this application. In circumstances where the text stream is
> > considered to contribute to a large degree to an experienced congestion
> > situation, it is RECOMMENDED to momentarily increase the shortest time
> > between transmissions described in section 5.1 from the
> recommended 300 ms
> > to 500 ms.
> >
> -----------------------------------------------------------------
> ----------
> > -------------
> > OK?
> >
> No. as said above.
>
> >
> > You say:
> >
> >>Do you have some analysis to show that, with typical text
> >>conversation packet rates and network RTTs, transmission with 20%
> >>packet loss is TCP friendly (or otherwise)?
> >
> >
> > Does this mean that you want me to investigate if we should
> propose a TCP
> > based mechanism for text conversation?
>
> No, the thing is that the congestion control people is concerned that
> any new transport stream should not starve out TCP. Therefore there is a
> requirement on congestion control to not allow, for example RTP streams,
> to get significant more bandwidth than what TCP would get in the same
> situation. This is normally referred to as TCP friendly.
>
> In regards to the rest of the discussion, there are work undergoing for
>    defining RTP over TCP, and the necessary signalling in SDP and SIP.
> See draft-ietf-mmusic-comdedia and draft-ietf-avt-rtp-framing-contrans.
>
> Cheers
>
> Magnus
>
> > The current standard ( RFC2793 ) make use of RTP. We have
> discussed using
> > TCP many times, and always ended up with the conclusion that
> RTP must be
> > the default. You may add on other mechanisms, but for interoperability
> > reasons we need to have one common default method.
> > Some reasons to stick with RTP as the default method are:
> >
> > 1.-Only RTP is standardised as a medium transport in the
> published versions
> > of SIP and SDP.
> > So, it is not currently possible to declare TCP in a properly
> standardised
> > SIP phone environemnt, and that is one of our main goals.
> > I know that TCP media in SIP is discussed and even used, but it is
> > definitely not mentioned in any RFC.
> >
> > 2.-TCP in not suitable in a loosely coupled conference
> situation. If you
> > want to send real time subtitles together with a speech in
> video and voice,
> > RTP is required.
> >
> > 3.-When NAT routers include mechanisms for taking SIP calls through
> > properly, we can be sure that RTP streams are handled well.
> Since TCP media
> > is not yet a standard in SIP, we cannot be sure that TCP
> streams will be
> > handled properly. We want future IP telephony to include
> video, text and
> > vocie streams without obstacles, and therefore we want the text to be
> > treated as the other media and not blocked by NAT-routers when
> voice and
> > video gets through.
> >
> > 4.-Same discussion as 3, but for Firewalls.
> >
> > 5.-If TCP is used, and you have a problem, the TCP session
> gets broken and
> > must be re-established . In that process, there is a risk of character
> > duplication, that needs to be avoided or marked. An RFC2793-like
> > transmission on top of TCP seem to be required to meet user
> requirements.
> >
> > 6.-The few extra bytes we introduce for two levels of
> redundancy may turn
> > out to cause less bits to transmit than TCP. Neither is close
> to any use of
> > audio or video in bit load on the network.
> >
> > Conclusion: Standardise RTP, use it as the default, experiment
> if you want
> > with TCP and get it eventually standardised as a negotiable
> option if it
> > turns out to have benefits.
> >
> >
>
> --
>
> Magnus Westerlund
>
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
>
>



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt