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

[Magnus Westerlund <[e-mail]>]

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