Subject: Re: [AVT] How is SDP a=fmtp used for RFC 2198?

From: Colin Perkins <[email-masked]>
Date: Mon, 29 Mar 2004 13:59:20 +0100

I agree with Magnus' interpretation of the RED parameters, the complete
list should be specified. However, our intent when writing RFC 2198 was
never to include so many levels of redundancy: sending 4 copies of each
frame seems excessive. 

Colin

--> Magnus Westerlund <[email-masked]> writes:
> Hi Gunnar,
> 
> See comments inline. However feedback from actual users and the authors 
> of RED is kindly requested, to help resolve this problem.
> 
> 
> Gunnar Hellstrom wrote:
> 
> > Magnus,
> > Thanks for the comments on RFC2793bis-03,
> > 
> > Comment 16 reflects another interpretation of RFC2198 than I have done.
> > -----------------------------------------------------------------------
> > 
> >>16. Section 6.3:
> >>   "Below is an example of SDP similar to the above example, but also
> >>    utilizing RFC 2198 to provide redundancy for the text packets:
> >>
> >>        m=text 11000 RTP/AVP 98 100
> >>        a=rtpmap:98 t140/1000
> >>        a=rtpmap:100 red/1000
> >>        a=fmtp:100 98/98 "
> >>
> >>I think one should point out in this text that one signals only that
> >one>will use on layer of text redundancy. IF one would use three levels
> >of>redundancy then the fmtp line would read:
> >>    a=fmtp:100 98/98/98/98
> >>
> > 
> > ----------------------------------------------------------------------
> > ----------
> > I have not understood that from RFC2198.
> > 
> > This is what RFC2198 says about the FMTP line:
> > ----------------------------------------------------------------------
> > --- To receive a redundant stream, this is all that is required. 
> > However
> >    to send a redundant stream, the sender needs to know which codecs
> >    are recommended for the primary and secondary (and tertiary, etc)
> >    encodings.  
> 
> I am basing this on this part. As it gives clear indication that one 
> should indicate what generation of redundancy the codec is specified for.
> 
> This information is specific to the redundancy format,
> >    and is specified using an additional attribute "fmtp" which conveys
> >    format-specific information.  A session directory does not parse the
> >    values specified in an fmtp attribute but merely hands it to the
> >    media tool unchanged.  For redundancy, we define the format
> >    parameters to be a slash "/" separated list of RTP payload types.
> > 
> >    Thus a complete example is:
> > 
> >        m=audio 12345 RTP/AVP 121 0 5
> >        a=rtpmap:121 red/8000/1
> >        a=fmtp:121 0/5
> > 
> >    This specifies that the default format for senders is redundancy
> >    with PCM as the primary encoding and DVI as the secondary encoding.
> >    Encodings cannot be specified in the fmtp attribute unless they are
> >    also specified as valid encodings on the media ("m=") line.
> 
> Also this example clearly indicates that PT=0 (PCM) is used as primary, 
> and DVI as secondary encoding. That ranking could not have been done 
> unless the list implies an order from primary to higher degrees of 
> redundancy.
> 
> > -----------------------------------------------------------------
> > I cannot from this description read that there needs to be one figure
> > in fmtp for each generation of redundant data. I rather expect the fmtp
> > line to express possible codecs, with the first one being the primary,
> > and then enumerating the ones used for redundancy taken in any order.
> > 
> > The payload format is specified per block of text in the block header.
> > Therefore I do not see the need for SDP to specify exactly the planned
> > PT:s per redundant generation.
> > 
> > Thus
> > a=fmtp:100 98/98
> > 
> > Would be enough regardless how many generations of PT 98 data we intend
> > to handle.
> > 
> > OK?
> 
> I also think that it would be simpler to use the list to indicate all 
> codecs that MAY appear in the redundancy format. However as in my view 
> the text indicates that one should indicate what specific configuration 
> of redundancy codecs that should be used. This is also a matter of 
> backwards compatibility, for RED in general. Therefore I seek input on 
> how this has been interpreted and used so far.
> 
> Cheers
> 
> Magnus
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 
> 
> This communication is confidential and intended solely for the
> addressee(s). Any unauthorized review, use, disclosure or distribution is
> prohibited. If you believe this message has been sent to you in error,
> please notify the sender by replying to this transmission and delete the
> message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption,
> interruption, unauthorized amendment, tampering and viruses, and we only
> send and receive e-mails on the basis that we are not liable for any such
> corruption, interception, amendment, tampering or viruses or any
> consequences thereof.
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 31 Mar 2004 16:31:54 +0100

--> "Gunnar Hellstrom" <[email-masked]> writes:
> On number of redundant generations for text transmission.
> ---------------------------------------------------------
> There is a need for one original and three redundant copies as the
> RECOMMENDED default for text transmission. That will meet the service
> requirements of <1% character error rate in conditions when voice is
> barely usable ( from F.700 & F.703 ). That can be in a society crisis
> situation when the network gets congested, or in next outbreak of worms
> crawling the Internet.
> Audio can be used for voice, and video for sign language down to around
> 30% packet loss. It can be a good goal to maintain usable text
> transmission at that packet loss rate.
> 
> Try the calculator in http://packetizer.com/iptel/toip/cercalc.html
> and find that you need 3 levels of redundancy to get under 1% character
> error with 30% packet loss. The character error figure for text coded
> text is at the bottom of the page.
> 
> It is not expensive. The RECOMMENDATION is to send text packets with 300
> ms intervals, and only when there is something to transmit. The
> redundancy levels take little space compared to the packet and RTP
> header.

I'd expect the gain from sending 3 levels of redundancy to be minimal
compared to a single delayed redundant packet.

> 3 generations of redundant data may sound excessive, if you have a
> network where loss is usually under 1%. But, if there is a risk of 30% in
> a crisis situation, you should follow the recommendation.

As noted in the security considerations section of RFC 2198:

   Whilst the addition of low-bandwidth redundancy to an audio stream is
   an effective means by which that stream may be protected against
   packet loss, application designers should be aware that the addition
   of large amounts of redundancy will increase network congestion, and
   hence packet loss, leading to a worsening of the problem which the
   use of redundancy was intended to solve.  At its worst, this can lead
   to excessive network congestion and may constitute a denial of
   service attack.

I believe the same issue is applicable to text streams, and accordingly do
not agree that sending 3 levels of redundancy is appropriate.

> On SDP for RFC2198
> --------------------
> If nobody have used RFC2198 for more than one generation of redundancy
> before, we are maybe free to document an interpretation of the SDP a=fmtp
> parameter in the most reasonable way. I think that is that the
> slash-separated list enumerates payload types that may be used in the
> session. Then, during media transmission, the PT parameters in the
> RFC2198 header indicates what coding was selected by the transmitter for
> that occasion.

Agree.

> The "secondary", "tertiary" etc payload types, may rather indicate a
> level of preference rather than the position among the redundant
> generations.

No.

> In the Introduction of RFC2198, the definition of fixed sets of payload
> types communicated out of band is mentioned as a cumbersome approach,
> while the freedom to select payload type for secondary information and
> indicate it in the same packet is the preferred method used in RFC2198.
> 
> I would not expect the SDP parameters needed to use RFC2198 to work
> against the promoted idea of the flexible coding of RFC2198.
>
> Therefore, I think, that I can specify a=fmtp: 100 98/98   and mean that
> PT 98 is used as primary, and PT 98 is used for any number of generations
> of secondary coded redundant data. No tertiary choice of coding is
> specified, meaning no third choice of coding.

No, this is not correct. The syntax "a=fmtp:100 98/98" means that payload
type 98 is used for the primary and secondary, and that there is no third
level of redundancy. 

> Here is the excerpt of RFC2198 introduction that supports this view:
> -------------------------------------------------------------------------
>  A modified version of the above solution could be to decide prior to
>    the beginning of a conference on a set a 32 encoding combinations
>    that will be used for the duration of the conference.  All tools in
>    the conference can be initialized with this working set of encoding
>    combinations.  Communication of the working set could be made through
>    the use of an external, out of band, mechanism.  Setup is complicated
>    as great care needs to be taken in starting tools with identical
>    parameters.  This scheme is more efficient as only one byte is used
>    to identify combinations of encodings.
>    It is felt that the complication inherent in distributing the mapping
>    of payload types onto combinations of redundant data preclude the use
>    of this mechanism.
> 
>    A more flexible solution is to have a single payload type which
>    signifies a packet with redundancy. That packet then becomes a
>    container, encapsulating multiple payloads into a single RTP packet.
>    Such a scheme is flexible, since any amount of redundancy may be
>    encapsulated within a single packet.  There is, however, a small
>    overhead since each encapsulated payload must be preceded by a header
>    indicating the type of data enclosed.  This is the preferred
>    solution, since it is both flexible, extensible, and has a relatively
>    low overhead.  The remainder of this document describes this
>    solution.
> ---------------------------------------------------------------
> Clear, isn?t it?

The text you quote has nothing to do with the MIME signalling for RFC 2198,
and instead motivates the choice of a payload format with embedded payload
type numbers.

We have had a tool that supports multiple levels of redundancy since 1997,
although such is rarely used becase it offers little benefit.  If one does
use multiple levels of redundancy, it is signalled by specifying each level
of coding on the SDP line, for example:

	m=audio 49170 RTP/AVP 0 3 5 98
	a=rtpmap:98 red/8000
	a=fmtp:98 0/5/3

If the same coding is used for multiple levels of redundancy, it must be
specified multiple times.

Colin

---

From: Tim Melanchuk <[email-masked]>
Date: Fri, 02 Apr 2004 10:45:11 -0800

to clarify with respect to using rfc2198 redundancy with rfc2833
telephone events, the sdp for the example on page 10 of rfc2833,
which shows 3 events in one packet, would have had:

a=rtpmap:96 red/8000
a=rtpmap:97 telephone-event/8000
a=fmtp:96 97/97/97

as well, at most 3 telephone-events could occur in one packet.
is this interpretation correct?

thanks,
timm

---

From: Colin Perkins <[email-masked]>
Date: Mon, 5 Apr 2004 13:32:41 +0100

> is this interpretation correct?

Yes, according to Section 5 of RFC 2198:

    To receive a redundant stream, this is all that is required.  However
    to send a redundant stream, the sender needs to know which codecs are
    recommended for the primary and secondary (and tertiary, etc)
    encodings.  This information is specific to the redundancy format,
    and is specified using an additional attribute "fmtp" which conveys
    format-specific information.  A session directory does not parse the
    values specified in an fmtp attribute but merely hands it to the
    media tool unchanged.  For redundancy, we define the format
    parameters to be a slash "/" separated list of RTP payload types.

Colin

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 7 Apr 2004 23:44:31 +0200

Conclusions for RFC2793bis usage

1. We need a fmt=100, 98/98/98
In order to specify transmission of one primary and two level of
redundancy.

2. One primary and three levels of redundancy was regarded excessive, so we
reduce the default to one primary and two redundant transmissions. That
means low load and high reliability.
Terminal software will not be extremely smart. They do not know if the
other party is on a 3G IP multimedia connection, or a bad TV-cable Internet
connection where a lot of packets are lost. You must start with an
assumption that 20% packets may be lost.

3. Each generation of redundant info gives quite good reliability increase.

Look at this calculation:

For RFC2793bis text transport in text form, this is the theory:

Assume that the risk of loosing a packet is p
The risk of loosing also next text packet is also p

The bad case is only when both are lost. The likelihood for that is p*p .

You can check with 50% loss and sending two packets. There are totally four
outcomes.

lost -not lost
lost - lost
not lost - lost
not lost - not lost

Only one out of four is unsuccessful. that is 25%.

0.5 * 0.5 = 0.25 the probability calculation is valid.

If you add one more redundancy level, the likelihood of all three lost is
p*p*p

With real figures, 20% packet loss and three transmissions give 0.2 * 0.2 *
0.2 = 0.008 =0.8%total loss.

Regards

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: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, March 31, 2004 5:32 PM
> To: Gunnar Hellstrom
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [AVT] How is SDP a=fmtp used for RFC 2198?
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 08 Apr 2004 10:25:25 +0200

Hi Colin and Gunnar,

See comments inline

> compared to a single delayed redundant packet.

Yes, the gain for each redundancy level, becomes less and less. And I 
would think that a third level would only be needed when packet loss 
rates are extreme. At 10% independent packet loss rates, it would result 
in that a third level drops the after redundancy loss rate from 0.1% to 
0.01%. Also for T.140 the risk for burst loss becomes significantly 
reduced due to the long inter packet delay when using the recommended 
buffering. Also as it is a interactive protocol the loss can be repaired 
on human level, by "say what?" or the actual text redundancy. But it 
seems natural to monitor the packet loss, and if they become excessive, 
a client may increase the level of redundancy, while at the same time 
make efforts to reduce the total bit-rate sent (see below).

> not agree that sending 3 levels of redundancy is appropriate.

In regards to congestion control, I would think that the correct 
response rather than reducing the level of redundancy is to increase the 
buffering, resulting in fewer packets per second. As a T.140 payload 
even with three levels of redundancy is most likely smaller than the 
headers, the most effective congestion reduction method is to reduce the 
number of packets sent. I think that such a statement on how to perform 
congestion control might be appropriate.

Cheers

Magnus Westerlund

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 8 Apr 2004 11:23:38 +0200

Fine,

I think the advice to maintain redundancy level, but increase the interval
between transmissions of text in a congested situation is good.

1. We have 300 ms between transmissions as the default. ( that makes it
quite burst-safe and keeps total load from text at a low level. )

2. We also agreed to having one original and two redundant transmissions as
default.

T.140 requires the wait for transmission to be less than 500 ms. So, there
is a room to extend the interval between transmissions in congested
situations to 500 ms even without breaking the standard. The users will
experience a slightly more jerky but still acceptable text presentation.

We will introduce this reasoning in next revision of RFC2793bis to be
issued soon.

Gunnar

> Sent: Thursday, April 08, 2004 10:48 AM
> To: Magnus Westerlund
> Cc: [email-masked]; Gunnar Hellstrom
> Hi,
> On 8 Apr 2004, at 09:25, Magnus Westerlund wrote:
> ...
> > Colin Perkins wrote:
> > rates are extreme. At 10% independent packet loss rates, it would
> > result in that a third level drops the after redundancy loss rate from
> > 0.1% to 0.01%. Also for T.140 the risk for burst loss becomes
> > significantly reduced due to the long inter packet delay when using
> > the recommended buffering. Also as it is a interactive protocol the
> > loss can be repaired on human level, by "say what?" or the actual text
> > redundancy.
>
> Also, if packet loss is bursty, the advantage of sending additional
> levels of redundancy is reduced compared to delaying the redundancy
> longer than the expected burst duration. Depends on the statistics of
> the packet loss, but the measurements I have taken indicate that loss
> often occurs in short bursts, rather than uniformly.
>
> > But it seems natural to monitor the packet loss, and if they become
> > excessive, a client may increase the level of redundancy, while at the
> > same time make efforts to reduce the total bit-rate sent (see below).
>
> Agreed, with the proviso that you can often get the same effect as
> increasing the level of redundancy by changing the delay before the
> redundant data.
>
> > response rather than reducing the level of redundancy is to increase
> > the buffering, resulting in fewer packets per second. As a T.140
> > payload even with three levels of redundancy is most likely smaller
> > than the headers, the most effective congestion reduction method is to
> > reduce the number of packets sent. I think that such a statement on
> > how to perform congestion control might be appropriate.
>
> If it's possible to send fewer packets per second, that is certainly
> better.
>
> Colin
>
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 08 Apr 2004 16:16:03 +0200

Hi Gunnar,

I thought of one more thing in relation to congestion control. I think 
the below is okay for real-time typing. However one should most likely 
make further comments that if one uses this payload format to transport 
larger blocks of text (automated systems), there is further 
considerations to be made in relation to using redundancy. Then it might 
be better to use either adaptive FEC or redundancy to combat packet loss 
due to the then higher overhead for each redundancy level. The main 
point is that the is important to perform congestion control, and the 
actual impact needs to be considered depending on application.

cheers

Magnus

-- 

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: 08 Apr 2004 15:31:52 -0400

>0.2 = 0.008 =0.8%total loss.

        This assumes totally independant loss.  The reality is that loss is
pretty strongly _not_ independant; i.e. the conditional probability of
losing packet N+1 after losing packet N is high, and typically way higher
than the base loss probability p (probability of losing packet N if packet
N-1 was received).  I.e. bursts are not an unusual type of loss.

        From numbers I've seen, the conditional probability for a second
packet to be lost (loss burst size >= 2) on the internet is around 15% or
more (with a p~= 1%).

        Of course these values are way lower than the 50% or 20% mentioned
above, but they're also heavily dependant on the physical links traversed.
(a 3GPP link may be much worse).

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 9 Apr 2004 07:16:28 +0200

You said:
> N-1 was received).

The text packetization avoids loading the network and avoids bursty packet
loss by recommending 300 ms between transmissions. So, you collect typed
characters during 300 ms and then form a packet and transmit. If nothing is
typed, nothing is transmitted.

The observations on bursty packet loss pattern you refer to are made on
audio transmission, where packets are sent with 20-30 ms intervals. That
gives a very different probability for influence by bursts of packet loss.
Figures for common lengths of bursts I have seen have indicated that bursts
over 50 ms are rare.

So, I feel quite safe with the calculation being reasonably accurate
without taking burstiness into account.

Regards

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Randell
> Jesup
> Sent: Thursday, April 08, 2004 9:32 PM
> To: Gunnar Hellstrom
> Cc: Colin Perkins; [email-masked];
> [email-masked]; [email-masked]

---

From: "Alan Clark" <[email-masked]>
Date: Fri, 9 Apr 2004 07:02:32 -0400

Bursts of consecutive loss are, as you suggest, relatively infrequent and
are usually due to link failures (see paper from Boutremans).  Sparse bursts
are however very common - typically up to 1-2 seconds of 20-30% loss density
(see www . voiptroubleshooter.com/voiptr_burstloss.htm).

Alan Clark
Telchemy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Gunnar
Hellstrom
Sent: Friday, April 09, 2004 1:16 AM
To: Randell Jesup
Cc: [email-masked]; [email-masked]; [email-masked];
Colin Perkins
Subject: RE: [AVT] -Bursty packet loss for text. - Was: How is SDP
a=fmtp used for RFC 2198?

Regards

---

From: Colin Perkins <[email-masked]>
Date: Thu, 8 Apr 2004 09:48:08 +0100

Hi,

Colin