Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED

From: Stefan Holmer <[email-masked]>
Date: Sun, 1 Jul 2012 14:17:47 +0200

On Sun, Jul 1, 2012 at 8:44 AM, Randell Jesup <[email-masked]>wrote:

> On 6/29/2012 3:30 AM, Stefan Holmer wrote:
>
>> Doesn't this in the end boil down to what tools we have for baseline
>> resilience? Retransmissions are fairly easy to implement and will in
>> most cases give a much better experience than for example relying on
>> periodic key frames or doing key frame requests. Also it isn't necessary
>> for the decoder to support decoding streams with lost packets.
>>
>
> "Better experience" incorporates a bunch of assumptions.
>
> Assuming we're talking video only:
>
> If you want it to be seamless, you have to be running a jitter buffer
> depth of at least 1 RTT plus time-to-decide-packet-may-be-**lost plus
> random-constant.  The second part of that can be tricky and network-state
> dependent.  On corporate networks, I'd see sudden 100ms changes in base
> delay over 1-3 packets; a short time-to-decide would flag each of those as
> missing.  This is ok (the re-xmit will get ignored as a dup), but adds
> packets at an apparent bad point for the network.
>
> That said, small RTTs certainly happen within LANs and corporations, and
> between neighbors in a single provider often.
>
> Note that often/normally with small RTTs you also get reasonably small
> jitter, and thus the adaptive jitter buffer might run very small numbers,
> so one might need to put a lower limit on the jitter buffer in these cases.
>
> The alternatives:
>
> 1) request re-xmit and freeze video queue when the jitter buffer runs dry.
>  If the packet comes in ASAP, freeze <= RTT+constant (modulo application
> scheduling delay at the sender side).  Then you can repair the broken
> frame, decode it, and then decode any following frames. Typically after a
> freeze you drop a frame or more; you might end up showing some of them
> depending on decode speed and how long the freeze lasted.  If the re-xmit
> (or the request) is lost, then delays can stretch much longer, since you
> need to wait RTT+bigger constant before requesting again.
>

Yes, this is what I would consider the simplest approach, which leads to a
system which can guarantee a complete stream thus not requiring the decoder
to be able to decode with errors, and at the same time having a good chance
of recovering within slightly longer than one RTT.

>
> In some conference apps even if the mixer just forwards video packets, the
> RTT is receiver<->mixer, not receiver<->mixer<->sender (this requires the
> mixer to buffer packets for possible retransmission).
>

Yes, this is definitely an upside.

>
> 2) request IDR (or refresh of corrupted slice).  Downside here is that you
> need to wait for the next frame encode at the sender side (so 0-33ms
> normally, or perhaps 0-100ms), and then the frame typically takes many
> packets to send (which also may be lost, and take time to receive
> especially on low-BW links), and IDR initial quality may be noticeably
> lower.  The receiver may freeze the video until the IDR is received or keep
> decoding with errors.  If there's a significant chance of the IDR losing a
> packet, a freeze could be substantial time.
>

If the losses are related to congestion, sending an IDR is usually a bad
idea. And as you are saying, if the losses are due to corruption, the
chance of having a loss in an IDR is much bigger than for a P-frame. I
don't think this approach is nearly as good as retransmissions, but it is a
possible baseline option.

>
> 3) request repair.  Note that #2 and #3 may be the same at the receiver
> side, with the sender deciding the best available repair.  In this case,
> the sender would instead of an IDR use a some other set of (smaller)
> packets to create an error-free up-to-date state at the receiver, such as
> encoding using a long-term-reference-frame, or using some other
> known-error-free frame in the receiver.  Note that repair is basically just
> a normal p-frame, albeit with somewhat lower quality and/or somewhat higher
> bandwidth used.  A big plus is that the end state is close to the same as
> re-transmit, but you don't have to speed through decoding any skipped
> frames.  Repair also allows the receiver to use alternate recovery
> mechanisms than simply freezing, including simply continuing to decode
> p-frames ignoring the lost frame.  This induces artifacts, but keeps motion
> loss to a minimum, especially in longer-RTT links.
>

Yes, I agree that this is also a good approach. It may be more expensive
than #1 if the long-term reference is old, but in general this would be a
good baseline as well.

It is possible to continue decoding p-frames, ignoring the loss, with
retransmissions as well. However it's a bit more complicated and you will
have to speed through some frames at the decoder when the rtx arrives,
although you can skip rendering them.

>
> Note that #3 in particular should result in similar freeze length as #1,
> perhaps 1 frame longer, if it freezes.  If it plays with errors instead,
> the freeze is typically 1 frame (the lost one).
>
> (Others?)
>
> My normal preference is #3. But, as discussed above, in low-RTT networks
> it may be a good option and might give 0-frames of freeze.  But, you still
> have all the complexities about how to decide when and how to use re-xmit;
> I think the 1 frame freeze is a reasonable option and a reasonable fallback
> if the source doesn't re-transmit.
>
> Also, if retransmit is REQUIRED, and the media is gatewayed to other
> sources (non-webrtc), and they don't support retransmit (likely), then the
> gateway would need to buffer and act as a retransmit agent (complicating
> the gateway).  If it's RECOMMENDED, this is not a big deal and the gateway
> can stay simpler.

Sure, that's a downside, and that may be a good enough reason for
RECOMMENDED. The same goes for #3, right? Non-webrtc sources may not
support long-term references and therefore have to rely on IDRs.

Just saying that it would be nice to have a baseline which is something
better than requesting IDRs.

>
> --
> Randell Jesup
> [email-masked]
>
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: "Roni Even" <[email-masked]>
Date: Mon, 2 Jul 2012 09:01:10 +0200

Hi,

You are right about the decoder, but this requires the encoder to keep the
information since it may be required later. In the case of non real-time
data this is not a problem since the data is in prerecorded but here the
data is not usually kept after transmission.

The whole discussion here is about required or recommended. My point is that
it is recommended since it does not work without any assumption on the RTT
and the receiver behavior when using jitter buffer.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Holmer
Sent: 29 June, 2012 9:31 AM
To: Magnus Westerlund
Cc: [email-masked]
Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or
RECOMMENDED

Doesn't this in the end boil down to what tools we have for baseline
resilience? Retransmissions are fairly easy to implement and will in most
cases give a much better experience than for example relying on periodic key
frames or doing key frame requests. Also it isn't necessary for the decoder
to support decoding streams with lost packets. 

/Stefan

On Fri, Jun 29, 2012 at 8:43 AM, Magnus Westerlund
<[email-masked]> wrote:

On 2012-06-28 16:36, Cullen Jennings wrote:
>
> I think you need to separate this for audio and video and be far more
> specific about what type of retransmit ion you are talking about. In
> many cases the retransmit ion schemes for audio make the end suer
> experience worse.

I am not disagreeing unless the RTT is really low.

What I am asking the WG is if RTP retransmission is a RECOMMENDED or
REQUIRED feature in the toolbox that an WebRTC end-point supports. This
says nothing on when you select to use it and on which media. If we want
to include such recommendations we can do it. In fact the RTP usage
draft has a bit on text discussing the issue with RTT.

Cheers

Magnus
(As WG chair)

>
> On Jun 27, 2012, at 24:36 , Magnus Westerlund wrote:
>
>> WG,
>>
>> We had a discussion at the interim if RTP Retransmission is to be
>> considered REQUIRED or RECOMMENDED to implement. I would like to
>> see if we can first have some discussion on this topic before
>> moving on to see if we can get a consensus here on the mailing
>> list.
>>
>> Please provide your views on this topic.
>>
>> Cheers
>>
>> Magnus Westerlund (As Chair and document editor)
>>
>>
>> ----------------------------------------------------------------------
>>
>>
Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>>
>>
Ericsson AB                | Phone  +46 10 7148287
<tel:%2B46%2010%207148287> 
>> Färögatan 6                | Mobile +46 73 0949079
<tel:%2B46%2073%200949079>  SE-164 80
>> Stockholm, Sweden| mailto: [email-masked]
>> ----------------------------------------------------------------------
>>
>>
>>
>>
_______________________________________________
>> rtcweb mailing list [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
<tel:%2B46%2010%207148287> 
Färögatan 6                | Mobile +46 73 0949079
<tel:%2B46%2073%200949079> 
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Roni Even" <[email-masked]>
Date: Mon, 2 Jul 2012 09:02:08 +0200

The discussion is whether it is required (MUST) or recommended (SHOULD)
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Leslie
Sent: 29 June, 2012 4:25 PM
To: Magnus Westerlund
Cc: [email-masked]
Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or
RECOMMENDED

> I am not disagreeing unless the RTT is really low.

   Actually, there is a balancing act between RTT and jitter...

> REQUIRED feature in the toolbox that an WebRTC end-point supports. 
> This says nothing on when you select to use it and on which media. If 
> we want to include such recommendations we can do it. In fact the RTP 
> usage draft has a bit on text discussing the issue with RTT.

   I'd like to support Magnus here: I believe retransmission SHOULD be a
tool available to the recipient to request. There will be cases where this
is the most appropriate tool.

--
John Leslie <[email-masked]>
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Mon, 02 Jul 2012 03:24:07 -0400

On 7/1/2012 8:17 AM, Stefan Holmer wrote:
>
>
> On Sun, Jul 1, 2012 at 8:44 AM, Randell Jesup <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     If you want it to be seamless, you have to be running a jitter
>     buffer depth of at least 1 RTT plus
>     time-to-decide-packet-may-be-__lost plus random-constant.  The
>     second part of that can be tricky and network-state dependent.  On
>     corporate networks, I'd see sudden 100ms changes in base delay over
>     1-3 packets; a short time-to-decide would flag each of those as
>     missing.  This is ok (the re-xmit will get ignored as a dup), but
>     adds packets at an apparent bad point for the network.
>
>     That said, small RTTs certainly happen within LANs and corporations,
>     and between neighbors in a single provider often.
>
>     Note that often/normally with small RTTs you also get reasonably
>     small jitter, and thus the adaptive jitter buffer might run very
>     small numbers, so one might need to put a lower limit on the jitter
>     buffer in these cases.
>
>     The alternatives:
>
>     1) request re-xmit and freeze video queue when the jitter buffer
>     runs dry.  If the packet comes in ASAP, freeze <= RTT+constant
>     (modulo application scheduling delay at the sender side).  Then you
>     can repair the broken frame, decode it, and then decode any
>     following frames. Typically after a freeze you drop a frame or more;
>     you might end up showing some of them depending on decode speed and
>     how long the freeze lasted.  If the re-xmit (or the request) is
>     lost, then delays can stretch much longer, since you need to wait
>     RTT+bigger constant before requesting again.
>
>
> Yes, this is what I would consider the simplest approach, which leads to
> a system which can guarantee a complete stream thus not requiring the
> decoder to be able to decode with errors, and at the same time having a
> good chance of recovering within slightly longer than one RTT.

Simple, yes.  There are aspects of this I don't like:

* Frozen for minimum of 1RTT+.  With 100ms RTT, you're probably at a 
minimum of 4 frames, perhaps 5, and if you lose another packet during 
those frames, it will move forward but not catch up sync, which can lead 
to jerky, out of sync video.  If you lose a re-xmit packet, you're 
talking minimum 2x the delay (and in reality a fair bit more because you 
have to decide when to ask for a re-re-xmit...).
* Decoding with errors: not generally a problem.  The issue is whether 
you prefer (or think the users prefer) a short (1 frame) freeze plus 
1RTT-1frame-ish period with motion but errors, or a 1+RTT min freeze, 
maybe/occasionally much more.  Our experience at WorldGate was that 
keeping motion active was preferable to freezing or worse loss of sync, 
even if there are errors.

That conclusion is debatable, and the answer may vary according to RTT, 
type of call, resolution, bandwidth, type of application, and isn't 
something the IETF should mandate here.

>     2) request IDR (or refresh of corrupted slice).  Downside here is
>     that you need to wait for the next frame encode at the sender side
>     (so 0-33ms normally, or perhaps 0-100ms), and then the frame
>     typically takes many packets to send (which also may be lost, and
>     take time to receive especially on low-BW links), and IDR initial
>     quality may be noticeably lower.  The receiver may freeze the video
>     until the IDR is received or keep decoding with errors.  If there's
>     a significant chance of the IDR losing a packet, a freeze could be
>     substantial time.
>
>
> don't think this approach is nearly as good as retransmissions, but it
> is a possible baseline option.

Agreed, though in practice if you're not getting hammered with high loss 
and you keep the quantization high on the IDR, it will usually get 
through.  Obviously as bitrates increase the number of packets in the 
IDR goes up, and risk of loss in the IDR goes up.  If correction is only 
for a slice, this risk may not be high.

>     3) request repair.  Note that #2 and #3 may be the same at the
>     receiver side, with the sender deciding the best available repair.
>       In this case, the sender would instead of an IDR use a some other
>     set of (smaller) packets to create an error-free up-to-date state at
>     the receiver, such as encoding using a long-term-reference-frame, or
>     using some other known-error-free frame in the receiver.  Note that
>     repair is basically just a normal p-frame, albeit with somewhat
>     lower quality and/or somewhat higher bandwidth used.  A big plus is
>     that the end state is close to the same as re-transmit, but you
>     don't have to speed through decoding any skipped frames.  Repair
>     also allows the receiver to use alternate recovery mechanisms than
>     simply freezing, including simply continuing to decode p-frames
>     ignoring the lost frame.  This induces artifacts, but keeps motion
> than #1 if the long-term reference is old, but in general this would be
> a good baseline as well.

There are mechanisms in VP8 that can be leveraged here.

> retransmissions as well. However it's a bit more complicated and you
> will have to speed through some frames at the decoder when the rtx
> arrives, although you can skip rendering them.

Yes, you'd have to clone the decoder state at the loss point in order to 
"rewind" and then correct.

>
>
>     Note that #3 in particular should result in similar freeze length as
>     #1, perhaps 1 frame longer, if it freezes.  If it plays with errors
>     instead, the freeze is typically 1 frame (the lost one).
>
>     (Others?)
>
>     My normal preference is #3. But, as discussed above, in low-RTT
>     networks it may be a good option and might give 0-frames of freeze.
>       But, you still have all the complexities about how to decide when
>     and how to use re-xmit; I think the 1 frame freeze is a reasonable
>     option and a reasonable fallback if the source doesn't re-transmit.
>
>     sources (non-webrtc), and they don't support retransmit (likely),
>     then the gateway would need to buffer and act as a retransmit agent
>     (complicating the gateway).  If it's RECOMMENDED, this is not a big
>     deal and the gateway can stay simpler.
>
>

Yup, and most do today.  The point is you report the loss as best you 
can (PLI, etc) and let the sender fix it as best it can.

I do think this is a strong argument for RECOMMEND (or even something 
less strong).  We could of course REQUIRE support but warn that even if 
supported, and endpoint might not agree to retransmits.  It does make 
the position of a gateway to this clause ... interesting, but in 
practice it could reject re-xmits unless it knows the non-webrtc source 
supports them.  So this doesn't mandate RECOMMEND over REQUIRE, but it 
is justification for RECOMMEND.

> better than requesting IDRs.

Yes.  But I don't think this is in the purview of the spec, unless you 
want to tie it to congestion control issues.

-- 
Randell Jesup
[email-masked]

---

From: Stefan Holmer <[email-masked]>
Date: Mon, 2 Jul 2012 09:49:28 +0200

On Mon, Jul 2, 2012 at 9:24 AM, Randell Jesup <[email-masked]>wrote:

>> <mailto:[email-masked]**>> wrote:
>>
>>     time-to-decide-packet-may-be-_**_lost plus random-constant.  The
>>
> minimum of 4 frames, perhaps 5, and if you lose another packet during those
> frames, it will move forward but not catch up sync, which can lead to
> jerky, out of sync video.  If you lose a re-xmit packet, you're talking
> minimum 2x the delay (and in reality a fair bit more because you have to
> decide when to ask for a re-re-xmit...).
> * Decoding with errors: not generally a problem.  The issue is whether you
> prefer (or think the users prefer) a short (1 frame) freeze plus
> maybe/occasionally much more.  Our experience at WorldGate was that keeping
> motion active was preferable to freezing or worse loss of sync, even if
> there are errors.
>

Yes, it doesn't solve all problems.

> and you keep the quantization high on the IDR, it will usually get through.
>  Obviously as bitrates increase the number of packets in the IDR goes up,
> and risk of loss in the IDR goes up.  If correction is only for a slice,
> this risk may not be high.
>
>
Yes.

> Yup, and most do today.  The point is you report the loss as best you can
> (PLI, etc) and let the sender fix it as best it can.
>

Yes, that is nice with #3, and if we can assume most endpoints will support
#3 I agree that is the way to go, even though the baseline (hopefully used
for a very small %) will have to be IDRs.

>
> I do think this is a strong argument for RECOMMEND (or even something less
> strong).  We could of course REQUIRE support but warn that even if
> supported, and endpoint might not agree to retransmits.  It does make the
> position of a gateway to this clause ... interesting, but in practice it
> could reject re-xmits unless it knows the non-webrtc source supports them.
>  So this doesn't mandate RECOMMEND over REQUIRE, but it is justification
> for RECOMMEND.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 2 Jul 2012 09:38:05 +0200

29 jun 2012 kl. 17:11 skrev Cullen Jennings:

> 
> Right - so on the question of it retransmission is mandatory to implement for audio codec, I am on a definitely "No". The bulk of systems today do not do it and work fine. Vendors can easily choose to do if they want in an interoperable way with out it being MTI. Why we should add a bunch of stuff in to version 1 of this that we can live without is beyond me. This is how IPv6 got big and hard, by everyone taking their favorite technology and attaching it to v6. I don't even want it as RECOMMENDED for audio - I see it as OPTIONAL. 
Agree. We need a base level of interoperability.
> 
> I probably feel differently about video. 
Maybe. Current video have the frame update requests. ugly, but works in most cases. I see reasons for retransmission of video, but not to make it recommended or required.

/O
> 
> 
> On Jun 28, 2012, at 23:43 , Magnus Westerlund wrote:
> 
>>>> Färögatan 6                | Mobile +46 73 0949079 SE-164 80

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Justin Uberti <[email-masked]>
Date: Mon, 2 Jul 2012 13:18:13 -0700

As has been pointed out in this thread before, this discussion is not about
mandating the USE of retransmission in realtime scenarios.  It is simply
trying to decide whether retransmission should be required to be present in
the 'toolbox' of tools that WebRTC apps can expect to use, primarily where
the app developer and runtime developer are separate (e.g. in a browser).

Several people have pointed out scenarios and applications where
retransmission (of video, not audio) works very well. Our experience
matches this too. Typically we can locate a media gateway very close to all
participants, meaning that a lost packet between GW and user can be
detected and retransmitted fast enough to not be noticeable by the user.
These applications, if they do not have access to retransmission, will be
forced to use cruder methods of error recovery that are more noticeable to
users, among other unpleasant effects.

Given that the implementation cost of retransmission is fairly negligible
(basically, a packet cache plus support for parsing NACK messages), and
that is really the only reason NOT to support this functionality in the
toolbox, I have a hard time understanding why we would not want to make
this a MUST implement for WebRTC.

Again, this is about making _support_ for retransmission a requirement, not
_use_.
--justin

On Mon, Jul 2, 2012 at 12:38 AM, Olle E. Johansson <[email-masked]> wrote:

> > Right - so on the question of it retransmission is mandatory to
> implement for audio codec, I am on a definitely "No". The bulk of systems
> today do not do it and work fine. Vendors can easily choose to do if they
> want in an interoperable way with out it being MTI. Why we should add a
> bunch of stuff in to version 1 of this that we can live without is beyond
> me. This is how IPv6 got big and hard, by everyone taking their favorite
> technology and attaching it to v6. I don't even want it as RECOMMENDED for
> audio - I see it as OPTIONAL.
> Maybe. Current video have the frame update requests. ugly, but works in
> most cases. I see reasons for retransmission of video, but not to make it
> recommended or required.
>
> /O
> >
> >

---

From: Randell Jesup <[email-masked]>
Date: Mon, 02 Jul 2012 17:51:25 -0400

On 7/2/2012 4:18 PM, Justin Uberti wrote:
> As has been pointed out in this thread before, this discussion is not
> about mandating the USE of retransmission in realtime scenarios.  It is
> simply trying to decide whether retransmission should be required to be
> present in the 'toolbox' of tools that WebRTC apps can expect to use,
> primarily where the app developer and runtime developer are separate
> (e.g. in a browser).

Do you expect to expose this choice to the application? (and all the 
data needed to make the choice...)  Or have it be automatic?

> matches this too. Typically we can locate a media gateway very close to
> all participants, meaning that a lost packet between GW and user can be
> These applications, if they do not have access to retransmission, will
> be forced to use cruder methods of error recovery that are more
> noticeable to users, among other unpleasant effects.

Ok.  This says that it's preferable to implement it, and if you have one 
of the situations that works well, use it.  This sounds like a SHOULD to 
me, since other implementations (say an audio-only WebRTC<->PSTN 
gateway) may have little or no use for retransmission, or might reject 
it always.

> Given that the implementation cost of retransmission is fairly
> negligible (basically, a packet cache plus support for parsing NACK
> messages), and that is really the only reason NOT to support this
> functionality in the toolbox, I have a hard time understanding why we
> would not want to make this a MUST implement for WebRTC.
>
> Again, this is about making _support_ for retransmission a requirement,
> not _use_.

If you don't mandate use, what does mandating "support" buy you?  An 
implementation (see above about PSTN gateways) might always decline to 
use retransmission, so what does MUST (REQUIRE) buy you?  I say SHOULD 
(RECOMMEND), with a statement that it's strongly recommended it be 
supported if video is supported, especially for non-single-purpose 
devices (i.e. browsers).

In either case, you need to think about who decides to use re-xmit or 
not, what influences that, and if the app has visibility into this. 
Someone could as an rtx-time=0 to the SDP.  Or not include one, but 
never actually retransmit a packet regardless of NACKs - it could just 
repair via IDR (or other means).

So here's a real problem related to retransmission: since the request is 
not specific and negotiated (it's normally a generic NACK), the receiver 
who sent the NACK has no idea if it will get a retransmission, an IDR 
(or IDR slice), another form of repair (pframe/slice against 
known-decoded frame - rpsi/etc), or nothing at all (NACK lost).  So, it 
doesn't know if it should freeze the video or play with errors.  It has 
to decide if it *thinks* the sender will use retransmission, or if it 
doesn't, does the receiver want to freeze video until an IDR or other 
repair is done, which might be a while.

We also need to think about when a receiver should use SLI or RPSI.  PLI 
can also be used and should be if the other options don't negotiate (so 
it's important to offer it).  Certainly it's more work to keep track of 
the contents of each packet (slices, etc), especially in things like 
H.264 NALU aggregation packets, than it is to just respond to an SLI.

That said, my previous systems just used NACK and let the sender decide 
the correct repair, but I wasn't leveraging slices and wasn't using 
retransmission, so there was only minor complexity (looking at possible 
reference frames).

-- 
Randell Jesup
[email-masked]

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 3 Jul 2012 09:30:42 +0200

2 jul 2012 kl. 22:18 skrev Justin Uberti:

> As has been pointed out in this thread before, this discussion is not about mandating the USE of retransmission in realtime scenarios.  It is simply trying to decide whether retransmission should be required to be present in the 'toolbox' of tools that WebRTC apps can expect to use, primarily where the app developer and runtime developer are separate (e.g. in a browser).

I fully understand this. What worries me is that my experience from SIPits and working with SIP for many years is that there is a large gap between IETF documents and what the implementations out there support. I would like some base level of interoperability in the RTP layer between webrtc and the SIP installed base. If the RTP toolset for Webrtc is far away from any standard SIP phone, you will be forcing everyone to use application layer gateways. I think that would be a bad scenario.

I still think it has to be optional to implement.

/O

> 
> Several people have pointed out scenarios and applications where retransmission (of video, not audio) works very well. Our experience matches this too. Typically we can locate a media gateway very close to all participants, meaning that a lost packet between GW and user can be detected and retransmitted fast enough to not be noticeable by the user. These applications, if they do not have access to retransmission, will be forced to use cruder methods of error recovery that are more noticeable to users, among other unpleasant effects.
> 
> Given that the implementation cost of retransmission is fairly negligible (basically, a packet cache plus support for parsing NACK messages), and that is really the only reason NOT to support this functionality in the toolbox, I have a hard time understanding why we would not want to make this a MUST implement for WebRTC.
> 
> Again, this is about making _support_ for retransmission a requirement, not _use_.
> --justin
> 
> 

---

---

From: Stefan Hakansson LK <[email-masked]>
Date: Wed, 4 Jul 2012 16:23:03 +0200

> repair is done, which might be a while.

Isn't retransmission negotiated using "rtx", "atp" and so on?

One way of removing the uncertainty would be to require that all 
browsers support RTP retransmission: This way, any RTP endpoint sending 
a NACK to a browser would know that that packet would be retransmitted 
(given that congestion does not prohibit, or NACK packet is lost etc.).

If we have this in place, I'm confident that implementors will quickly 
develop strategies on how and when to _use_ retransmission in the best 
way. There has already been input made on its usefulness.

Maybe the problem with legacy not always supporting retransmission is 
not that big. First of all, legacy is to a large extent audio only (e.g. 
PSTN), and no one is arguing for retransmission there. Secondly, I fail 
to see that this situation would be improved in any way if browsers are 
only recommended (and not required) to support RTP retransmission.

So I think we should require rtcweb capable browsers to support RTP 
retransmission.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Jul 2012 11:11:29 -0400

On Tue, Jul 3, 2012 at 3:30 AM, Olle E. Johansson <[email-masked]> wrote:

> primarily where the app developer and runtime developer are separate (e.g.
> in a browser).
>
> I fully understand this. What worries me is that my experience from SIPits
> and working with SIP for many years is that there is a large gap between
> IETF documents and what the implementations out there support. I would like
> some base level of interoperability in the RTP layer between webrtc and the
> SIP installed base. If the RTP toolset for Webrtc is far away from any
> standard SIP phone, you will be forcing everyone to use application layer
> gateways. I think that would be a bad scenario.
>
I think this train left the station long time ago. WebRTC is not going to
interoperate with anything of significance currently deployed in SIP world.
Between DTLS-SRTP, ICE, AVPF and now RTP retransmissions you will need an
application layer gateway. I guess the overall hope is that SIP
implementations will catch up implementing features required to work with
WebRTC in the future and gateways would be acceptable for current
implementations.
_____________
Roman Shpount

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 4 Jul 2012 17:52:09 +0200

4 jul 2012 kl. 17:11 skrev Roman Shpount:

> I think this train left the station long time ago. WebRTC is not going to interoperate with anything of significance currently deployed in SIP world. Between DTLS-SRTP, ICE, AVPF and now RTP retransmissions you will need an application layer gateway. I guess the overall hope is that SIP implementations will catch up implementing features required to work with WebRTC in the future and gateways would be acceptable for current implementations.

Doesn't that mean that the IETF work on SIP over websockets will not lead anywhere?

/O

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Jul 2012 15:39:49 -0400

On Wed, Jul 4, 2012 at 11:52 AM, Olle E. Johansson <[email-masked]> wrote:

> > I think this train left the station long time ago. WebRTC is not going
> to interoperate with anything of significance currently deployed in SIP
> world. Between DTLS-SRTP, ICE, AVPF and now RTP retransmissions you will
> need an application layer gateway. I guess the overall hope is that SIP
Unless we have a SIP end point that supports DTLS-SRTP  and ICE,
understands AVPF profile, and knows how to negotiate RTP retransmissions
and other RTP extensions, then I would say SIP over websockets will not
help in communications between SIP and WebRTC. There are a few SIP
endpoints that claim to support some of those specifications, but anything
massively deployed in real life, like IP phones, PBXs, SBCs, PSTN gateways,
and soft-phones,  almost universally do not support or use any of those
standards.

SIP over websockets might be useful on its own though, for instance as a
replacement for SIP-outbound, which fails to address even basic operational
requirements for SIP clients behind NAT. Hopefully though, WebRTC will
replace SIP on the client, and will remove the need for SIP behind NAT
support altogether, making SIP over websockets completely irrelevant.
_____________
Roman Shpount

---

From: Lishitao <[email-masked]>
Date: Thu, 5 Jul 2012 02:40:39 +0000

I got some questions about this RTP Retransmission staff, is there a capability negotiation mechanism provided in RTP Retransmission, like negotiate the capability in the first offer/answer transition. (I don’t find that in the documents, or if I miss somewhere)

I also find  in RFC 4588, it mentioned that there are two ways for Retransmission, one is Session-Multiplexing, another is SSRC-Multiplexing, does those two mechanism both need to be supported for implementation?

Regards

shitao

________________________________

华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com
________________________________
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
发件人: [email-masked] [mailto:[email-masked]] 代表 Roman Shpount
发送时间: 2012年7月5日 3:40
收件人: Olle E. Johansson
抄送: [email-masked]
主题: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED

On Wed, Jul 4, 2012 at 11:52 AM, Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

Unless we have a SIP end point that supports DTLS-SRTP  and ICE, understands AVPF profile, and knows how to negotiate RTP retransmissions and other RTP extensions, then I would say SIP over websockets will not help in communications between SIP and WebRTC. There are a few SIP endpoints that claim to support some of those specifications, but anything massively deployed in real life, like IP phones, PBXs, SBCs, PSTN gateways, and soft-phones,  almost universally do not support or use any of those standards.

SIP over websockets might be useful on its own though, for instance as a replacement for SIP-outbound, which fails to address even basic operational requirements for SIP clients behind NAT. Hopefully though, WebRTC will replace SIP on the client, and will remove the need for SIP behind NAT support altogether, making SIP over websockets completely irrelevant.
_____________
Roman Shpount

---

From: Randell Jesup <[email-masked]>
Date: Thu, 05 Jul 2012 01:10:55 -0400

> Isn't retransmission negotiated using "rtx", "atp" and so on?

Support for it is.  However, negotiating support for it doesn't solve 
the problem of not knowing how the sender will respond to a NACK (or 
SLI/RPSI/etc).  Generally, the sender has to make the decision, but the 
receiver has to guess.

> browsers support RTP retransmission: This way, any RTP endpoint 
> sending a NACK to a browser would know that that packet would be 
> retransmitted (given that congestion does not prohibit, or NACK packet 
> is lost etc.).

Um, no.  Just because both sides support retransmission does not mean 
that a NACK will generate a retransmission.  Retransmission only makes 
sense in some instances, and there's no guarantee that retransmission 
will be possible (for example, the requested packet might have timed out 
and been thrown away).

> way. There has already been input made on its usefulness.

Sure, and they will anyways.  RECOMMENDED or REQUIRED, it really doesn't 
matter to the implementation.  For that matter, even if REQUIRED there's 
nothing that says it has to be offered or accepted.  Even if that were 
mandated, the implementation could accept but with a 0-length rtx-time.  
So it's really unclear what REQUIRED buys you that RECOMMENDED doesn't.

> not that big. First of all, legacy is to a large extent audio only 
> (e.g. PSTN), and no one is arguing for retransmission there. Secondly, 
> I fail to see that this situation would be improved in any way if 
> browsers are only recommended (and not required) to support RTP 
> retransmission.
>

-- 
Randell Jesup
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Jul 2012 08:48:02 -0700

On 4 July 2012 12:39, Roman Shpount <[email-masked]> wrote:
> Unless we have a SIP end point that supports DTLS-SRTP  and ICE, understands
> AVPF profile, and knows how to negotiate RTP retransmissions and other RTP
> extensions, [...]

I think that this is a little pessimistic.  SRTP with SDES is still a
viable option, for this reason.  The SIP endpoint can implement
ICE-lite and still interoperate.  AVPF senders can interoperate with
AVP receivers unless you have some strange business going on at the
AVP end.  And RTP retransmission is easy to claim support for without
actually supporting (either the NACKs or the retransmissions got lost,
I don't know which, sorry).

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 5 Jul 2012 18:07:40 +0200

> I don't know which, sorry).

The discussion started with REQUIREments on developers. 

"The development
   of the WebRTC framework provides an opportunity for us to review the
   available RTP features and extensions, and to define a common
   baseline feature set for all WebRTC implementations of RTP.  This
   builds on the past 15 years development of RTP to mandate the use of
   extensions that have shown widespread utility, while still remaining
   compatible with the wide installed base of RTP implementations where
   possible."

http://www.ietf.org/id/draft-ietf-rtcweb-rtp-usage-03.txt

I really think we should be very careful to REQUIRE implementations to implement
functions that break this goal.

/O

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Jul 2012 09:13:08 -0700

> functions that break this goal.

Don't get me wrong.  I completely agree with this.  I see
retransmission as unnecessary for exactly the same reasons.  I just
wanted to point out that giving up on interoperability is probably
going too far.

---

From: Stefan Hakansson LK <[email-masked]>
Date: Fri, 6 Jul 2012 09:08:59 +0200

> will be possible (for example, the requested packet might have timed out

All I was trying to say was that mandating support for retransmission 
would remove one uncertainty. But I agree that there are situations when 
there still would be no retransmission (and the receiver would not know 
why).

But I guess you're also saying that mandating it would not be helpful 
since the sender decides, and could in principle have support for 
retransmission, but being set up/implemented/tuned in such a way that it 
(almost) never retransmits. I didn't think about that; and I don't know 
how big that risk is.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 19 Jul 2012 12:07:23 +0200

Branching off a discussion because we seem to have two people saying 
contradictory things about something that may actually have a clear answer:

When sending an UDP packet over a random port pair across an LTE 
network, is it transferred in acknowledged mode (with L2-level 
retransmissions) or in unacknowledged mode (without retransmissions)?

The possible answers seem to be (if I understand the statements correctly):

- Acknowledged (Cameron)
- Unacknowledged (Fabio)
- "It depends"

Unlike some other arguments in the parent thread, this one seems to be 
amenable to source citations.

On 06/27/2012 11:11 PM, Fabio Pietrosanti (naif) wrote:
> On 6/27/12 10:54 PM, Cameron Byrne wrote:
>>> You are saying that in EDGE, UMTS, HSDPA when an IP stack send an UDP
>>> packet, it will handled from L2 like in the old age of GSM CSD and be
>>> automatically retransmitted?
>>>
>> Yes. LTE too.
> I read (by googling cause i don't have LTE access) that also LTE uses
> for IPTV and all other IP streaming applications the UM_RLC
> (unacknowledged mode).
>
> So also LTE should not do retransmission, unless being set in AM_RLC
> (acknowledged mode).
>
> Fabio

---

From: Göran Eriksson AP <[email-masked]>
Date: Thu, 19 Jul 2012 13:41:08 +0200

________________________________________
Från: [email-masked] [[email-masked]] f&#246;r Harald Alvestrand [[email-masked]]
Skickat: den 19 juli 2012 12:07
Till: [email-masked]
Ämne: [rtcweb] LTE using AM_RLC or UM_RLC mode for UDP?

- Acknowledged (Cameron)
- Unacknowledged (Fabio)
- "It depends"

    As far as I know, both AM and UM can be used in a "radio bearer" in LTE. Whether to use AM/UM when realizing/configuring
    a "radio bearer"  depends partly on the requirements on delay, packet loss, etc for the "radio bearer".

   AM introduces delay but how much differs of course from 2G, 3G, LTE (4G). For this reason UM has been preferred.
   With LTE however- since the retransmission- things may be different and AM *may* be useful even for RTC radio bearers.

   I guess it also depends on the characteristics of the specific radio network in question.

  In the end, I am not sure exactly how it is of relevance for this WG but that may in itself be worth while discussing and both
  Cullens DSCP draft and Markus Mobile draft is a first step.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 19 Jul 2012 05:10:36 -0700

Works in mobile network

> - Unacknowledged (Fabio)
> - "It depends"
>
>     As far as I know, both AM and UM can be used in a "radio bearer" in
LTE. Whether to use AM/UM when realizing/configuring
>     a "radio bearer"  depends partly on the requirements on delay, packet
loss, etc for the "radio bearer".

It is a radio bearer parameter controlled by the qos profile on a per
bearer basis. It has nothing to do with dscp, udp, or the application you
are using.... It has do more with the user profile and apn in use.... More
like layer 1 setup than layer markings or layer 7 apps

>    AM introduces delay but how much differs of course from 2G, 3G, LTE
(4G). For this reason UM has been preferred.
>    With LTE however- since the retransmission- things may be different
and AM *may* be useful even for RTC radio bearers.

All theoretically correct so far, i am not sure how much UM exists in the
real world

>    I guess it also depends on the characteristics of the specific radio
network in question.

Actually, it depends on implementation. UM is generally not implemented
afaik. A MAJOR radio manufacturer confirmed they have no support for UM in
practical LTE deployments, only AM.  At the network i work at, there is no
plan for UM support in any scenario, which is pretty much the default
setting and radio vendor recommentation. I tried to push UM on them after
our discussion on list, but no luck.

CB
>   In the end, I am not sure exactly how it is of relevance for this WG
but that may in itself be worth while discussing and both