Subject: [MMUSIC] media-loopback congestion

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 14 Apr 2012 11:59:08 +0000

Magnus has raised a comment/concern as follows:

Currently section 6 says this:
   A loopback mirror that is compliant to this specification and
   accepts media with rtp-pkt-loopback loopback-type MUST loopback the
   incoming RTP packets using either the encapsulated RTP payload
   format or the direct loopback RTP payload format as defined in
   section 7 of this specification.

And section 9 about Congestion Control says this:
    All the participants in a loopback session SHOULD implement
    congestion control mechanisms as defined by the RTP profile under
    which the loopback mechanism is implemented. For audio video
    profiles, implementations SHOULD conform to the mechanism defined
    in Section 2 of RFC 3551.

Magnus' comment is this:
This section [9] is thoroughly inadequate. The reason is that you have a
forward path that is coupled to the reverse path. If the loopback is to
work correctly the mirror needs to be able to send back what the source
sent to it. Thus it is the loopback source that needs to adapt the media
bit-rate so that both forward and reverse path can handle the flows. If
doesn't the mirror will need to reduce the bit-rate it transmits and
that can only happen in two ways, dropping packets or transcoding them
to a lower rate fulfilling the congestion control requirement. Neither
will fulfill the purpose of the loopback as I see it. This issue needs
discussion, including some considerations in how to actually accomplish
it with the tools we have available.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 14 Apr 2012 12:09:42 +0000

One of Magnus concerns for below is that section 6's MUST statement does not have an escape clause allowing the mirror to not mirror a packet back if it perceives congestion.  I propose to put in the following at the end of the section 6 shown below:
..., when it can send packets back.  Since congestion might be detected by the mirror, for example, the loopback mirror might not necessarily loopback all incoming RTP packets.

Does this work for everyone for this section?

There still needs to be discussion on section 9.

-hadriel

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 16 Apr 2012 11:34:38 +0530

Hadriel,

|..., when it can send packets back.

This looks open for interpretation since there can be other reasons
apart from congestions where the mirror can't send packets back. My
suggestion is to state explicitly that congestion in the only exception:

   A loopback mirror that is compliant to this specification and
   accepts media with rtp-pkt-loopback loopback-type MUST loopback the
   incoming RTP packets using either the encapsulated RTP payload
   format or the direct loopback RTP payload format as defined in
   section 7 of this specification, except when the loopback mirror 
   perceives congestion. When the loopback mirror perceives congestion
   it might not necessarily loopback all incoming RTP packets.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
|Sent: Saturday, April 14, 2012 5:40 PM
|To: mmusic (E-mail); Magnus Westerlund
|Cc: [email-masked]
|Subject: Re: [MMUSIC] media-loopback congestion
|
|
|One of Magnus concerns for below is that section 6's MUST statement
does not have an escape clause
|allowing the mirror to not mirror a packet back if it perceives
congestion.  I propose to put in the
|following at the end of the section 6 shown below:
|..., when it can send packets back.  Since congestion might be detected
by the mirror, for example,
|the loopback mirror might not necessarily loopback all incoming RTP
packets.
|
|Does this work for everyone for this section?
|
|There still needs to be discussion on section 9.
|
|-hadriel
|
|
|On Apr 14, 2012, at 7:59 AM, Hadriel Kaplan wrote:
|
|> Magnus has raised a comment/concern as follows:
|>
|> Currently section 6 says this:
|>   A loopback mirror that is compliant to this specification and
|>   accepts media with rtp-pkt-loopback loopback-type MUST loopback the
|>   incoming RTP packets using either the encapsulated RTP payload
|>   format or the direct loopback RTP payload format as defined in
|>   section 7 of this specification.
|
|_______________________________________________
|mmusic mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Apr 2012 11:47:16 +0200

>    it might not necessarily loopback all incoming RTP packets.

To start with Hadriel's question if this is sufficient. I don't think
so. The reasons is that unless you have a media level loopback capable
of doing transcoding to a format with variable bit-rate the loopback
case is such that you don't want to modify the packets in the return
path. From the perspective of reaching the goals of loopback it would
actually be best to put all the responsibility of the congestion control
on the media source. And it needs to take both the forward and return
path into account when making congestion control decisions.

Actually this is in many ways simpler than having one way control. This
as the packet sender and receiver are the same. The source will know
what it sent and when and can make accurate full RTT measurements to
determine delay variations. It is also certain of all the packets it
sent. If the mirror is truly deterministic in its behavior then you can
accurately model for these conditions. In fact having the mirror detect
and stop sending when it sees congestion actually makes the source work
more difficult.

So I see several approaches here.

1) Specify that the source is sole responsible for both paths.

2) Specify that the source is sole responsible and have the mirror
verify compliance by running a circuit breaker algorithm to verify that
at least the return path isn't seriously messing things up.

3) Specify that each side runs independent congestion control and then
discuss the impact on the return path when there is congestion in that
direction and not the forward one.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 17 Apr 2012 11:22:51 +0530

|From the perspective of reaching the goals of loopback it would
|actually be best to put all the responsibility of the congestion 
|control on the media source. And it needs to take both the forward
|and return path into account when making congestion control decisions.

I agree. The purpose of the packet loopback mode is to provide a simple mechanism to test how good the media path is and not to test how good the mirror can respond to network congestion, IMHO. If there is packet loss due to congestion, so it be -- the loopback source will know that. It might then want to repeat the test to see if this is a temporary issue. If subsequent tests produce packet loss, it might conclude that the media path isn't good for making an audio/video call using the coded it used.

Requiring the mirror to implement congestion control to conceal packet loss would be of little value for this case. Worse, if were a mechanism different from what the mirror endpoint might use when it actually renders and generates media -- it might give a false impression about the quality of the media path.

|2) Specify that the source is sole responsible and have the mirror
|verify compliance by running a circuit breaker algorithm to verify
|that at least the return path isn't seriously messing things up.

I agree the source should be made responsible for congestion control for both the paths. In addition, a mirror running circuit breaker could be useful if it does the same when it renders and generates media -- might help the user to determine using packet loopback at point media stops working. On the other hand, if the purpose of the test is to see how seriously the return path is messed up, then a circuit breaker at the mirror may not be needed. So, the draft could specify that the mirror MAY run a circuit breaker, I think.

On similar lines, having the mirror report congestion to the source might be useful as well.

Muthu

|-----Original Message-----
|From: Magnus Westerlund [mailto:[email-masked]]
|Sent: Monday, April 16, 2012 3:17 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Hadriel Kaplan; mmusic (E-mail); [email-masked]
|Subject: Re: [MMUSIC] media-loopback congestion
|
|On 2012-04-16 08:04, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> Hadriel,
|>
|> |..., when it can send packets back.
|>
|> This looks open for interpretation since there can be other reasons
|> apart from congestions where the mirror can't send packets back. My
|> suggestion is to state explicitly that congestion in the only exception:
|>
|>    A loopback mirror that is compliant to this specification and
|>    accepts media with rtp-pkt-loopback loopback-type MUST loopback the
|>    incoming RTP packets using either the encapsulated RTP payload
|>    format or the direct loopback RTP payload format as defined in
|>    section 7 of this specification, except when the loopback mirror
|>    perceives congestion. When the loopback mirror perceives congestion
|>    it might not necessarily loopback all incoming RTP packets.
|
|
|To start with Hadriel's question if this is sufficient. I don't think
|so. The reasons is that unless you have a media level loopback capable
|of doing transcoding to a format with variable bit-rate the loopback
|case is such that you don't want to modify the packets in the return
|path. From the perspective of reaching the goals of loopback it would
|actually be best to put all the responsibility of the congestion control
|on the media source. And it needs to take both the forward and return
|path into account when making congestion control decisions.
|
|Actually this is in many ways simpler than having one way control. This
|as the packet sender and receiver are the same. The source will know
|what it sent and when and can make accurate full RTT measurements to
|determine delay variations. It is also certain of all the packets it
|sent. If the mirror is truly deterministic in its behavior then you can
|accurately model for these conditions. In fact having the mirror detect
|and stop sending when it sees congestion actually makes the source work
|more difficult.
|
|So I see several approaches here.
|
|1) Specify that the source is sole responsible for both paths.
|
|2) Specify that the source is sole responsible and have the mirror
|verify compliance by running a circuit breaker algorithm to verify that
|at least the return path isn't seriously messing things up.
|
|3) Specify that each side runs independent congestion control and then
|discuss the impact on the return path when there is congestion in that
|direction and not the forward one.
|
|Cheers
|
|Magnus Westerlund
|
|----------------------------------------------------------------------
|Multimedia Technologies, Ericsson Research EAB/TVM
|----------------------------------------------------------------------
|Ericsson AB                | Phone  +46 10 7148287
|Färögatan 6                | Mobile +46 73 0949079
|SE-164 80 Stockholm, Sweden| mailto: [email-masked]
|----------------------------------------------------------------------