Re: [R-C] Effect of ConEx on RMCAT
Hi CC the ConEx list as I believe a cross-post is motivated. There has been a few experiments with ConEx, I know Mirja has done some experimentation before, also there was presentation at the last IETF http://tools.ietf.org/agenda/83/slides/slides-83-conex-5.pdf the re-feedback of the ECN marks was however not properly implemented if I remember it right but the results was anyway interesting. As mentioned in an earier email (from me), I don't believe that ConEx should be squeezed into the charter now. But what is important is that it should be recongnized that there are other mechanisms other than the endpoint rate adaptation algorithms that benefit from a timely feedback of congestion information from the receiver back to the sender. /Ingemar
----------------------------------------------------------------------
Message: 1 Date: Thu, 24 May 2012 09:24:31 -0500 From: "Bill Ver Steeg (versteb)" <versteb@cisco.com> To: "Zaheduzzaman Sarker" <zaheduzzaman.sarker@ericsson.com>, <rtp-congestion@alvestrand.no> Subject: Re: [R-C] Effect of ConEx on RMCAT Message-ID: <117602CF2B17DB4F9001427FA6D9053901D19BC6@XMB-RCD-312.cisco.com> Content-Type: text/plain; charset="iso-8859-1"
Does anybody have results from trials of ConEX? I have not seen any. In the absence of such feedback, I am reluctant to put it on the critical path. It seems like there may be something good in ConEX, but it does add significant complexity to the system
bvs
-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Zaheduzzaman Sarker Sent: Thursday, May 24, 2012 7:03 AM To: rtp-congestion@alvestrand.no Subject: [R-C] Effect of ConEx on RMCAT
Hi,
One topic that so far have not been discussed in this mailing list is the ConEx and it's effect on congestion avoidance.
ConEx Background: IETF ConEx WG is chartered here https://datatracker.ietf.org/wg/conex/charter/. According to that charter ConEX is working on congestion exposure mechanism for IPv6 networks. Basically, the receiver of a flow sends the congestion related information (packetloss, ECN-CE markings) back to the sender then the sender of the flow inserts IPv6 header extension to expose that information to the operators. This is done to aid the congestion management at the network. Typically as long as the flow does not exceed a certain congestion volume the network does not do any kind of traffic shaping on that flow.
The effects:
+ RTP media is not ConEx enabled: Bitrate may be throttled in the network possibly based on some time of day policy or whatever.
+ RTP media is ConEx enabled but no feedback or congestion information to the sender or congestion feedback is too slow : Audit functions will find a mismatch between stated and actual congestion and will start to drop packets.
+ RTP media is ConEx enabled and timely feedback of congestion info to sender: Packets will pass through unaffected by the ConEx policers as long as congestion volume quota is not exceeded.
This means:
* the operators can drop priority on non-ConEx flows hence a ConEx enabled flow is treated differently. This will have impact on the congestion avoidance techniques RMCAT will produce as same algorithm may not work efficiently enough for both ConEx enabled flow and non-ConEx enabled flow.
* a ConEx enabled flow will need to send congestion related information (perhaps more frequently than usual) i.e. packet loss and ECN marking information along with simple rate request.
* RTP media need to be congestion volume aware.
I see a clear impact on design choice on how to handle these. I think we should discuss the impact of ConEx here before the BOF in Vancouver.
-- Zahed
============================================ ANM ZAHEDUZZAMAN SARKER
Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Lule?, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================ _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
------------------------------
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
End of Rtp-congestion Digest, Vol 8, Issue 10 *********************************************
Yup, I had seen this study. The paper is interesting, but the testing regime is so small that one could hardly draw conclusive opinions for the data. Further study is required, and I suggest that the ConEX study should run in parallel to the RTP congestion control work. bvs -----Original Message----- From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] Sent: Monday, May 28, 2012 2:15 AM To: Bill Ver Steeg (versteb) Cc: rtp-congestion@alvestrand.no; Zaheduzzaman Sarker; Mirja Kuehlewind; conex@ietf.org Subject: RE: [R-C] Effect of ConEx on RMCAT Hi CC the ConEx list as I believe a cross-post is motivated. There has been a few experiments with ConEx, I know Mirja has done some experimentation before, also there was presentation at the last IETF http://tools.ietf.org/agenda/83/slides/slides-83-conex-5.pdf the re-feedback of the ECN marks was however not properly implemented if I remember it right but the results was anyway interesting. As mentioned in an earier email (from me), I don't believe that ConEx should be squeezed into the charter now. But what is important is that it should be recongnized that there are other mechanisms other than the endpoint rate adaptation algorithms that benefit from a timely feedback of congestion information from the receiver back to the sender. /Ingemar
----------------------------------------------------------------------
Message: 1 Date: Thu, 24 May 2012 09:24:31 -0500 From: "Bill Ver Steeg (versteb)" <versteb@cisco.com> To: "Zaheduzzaman Sarker" <zaheduzzaman.sarker@ericsson.com>, <rtp-congestion@alvestrand.no> Subject: Re: [R-C] Effect of ConEx on RMCAT Message-ID: <117602CF2B17DB4F9001427FA6D9053901D19BC6@XMB-RCD-312.cisco.com> Content-Type: text/plain; charset="iso-8859-1"
Does anybody have results from trials of ConEX? I have not seen any. In the absence of such feedback, I am reluctant to put it on the critical path. It seems like there may be something good in ConEX, but it does add significant complexity to the system
bvs
-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Zaheduzzaman Sarker Sent: Thursday, May 24, 2012 7:03 AM To: rtp-congestion@alvestrand.no Subject: [R-C] Effect of ConEx on RMCAT
Hi,
One topic that so far have not been discussed in this mailing list is the ConEx and it's effect on congestion avoidance.
ConEx Background: IETF ConEx WG is chartered here https://datatracker.ietf.org/wg/conex/charter/. According to that charter ConEX is working on congestion exposure mechanism for IPv6 networks. Basically, the receiver of a flow sends the congestion related information (packetloss, ECN-CE markings) back to the sender then the sender of the flow inserts IPv6 header extension to expose that information to the operators. This is done to aid the congestion management at the network. Typically as long as the flow does not exceed a certain congestion volume the network does not do any kind of traffic shaping on that flow.
The effects:
+ RTP media is not ConEx enabled: Bitrate may be throttled in the network possibly based on some time of day policy or whatever.
+ RTP media is ConEx enabled but no feedback or congestion information to the sender or congestion feedback is too slow : Audit functions will find a mismatch between stated and actual congestion and will start to drop packets.
+ RTP media is ConEx enabled and timely feedback of congestion info to sender: Packets will pass through unaffected by the ConEx policers as long as congestion volume quota is not exceeded.
This means:
* the operators can drop priority on non-ConEx flows hence a ConEx enabled flow is treated differently. This will have impact on the congestion avoidance techniques RMCAT will produce as same algorithm may not work efficiently enough for both ConEx enabled flow and non-ConEx enabled flow.
* a ConEx enabled flow will need to send congestion related information (perhaps more frequently than usual) i.e. packet loss and ECN marking information along with simple rate request.
* RTP media need to be congestion volume aware.
I see a clear impact on design choice on how to handle these. I think we should discuss the impact of ConEx here before the BOF in Vancouver.
-- Zahed
============================================ ANM ZAHEDUZZAMAN SARKER
Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Lule?, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================ _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
------------------------------
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
End of Rtp-congestion Digest, Vol 8, Issue 10 *********************************************
participants (2)
-
Bill Ver Steeg (versteb) -
Ingemar Johansson S