[R-C] Effect of ConEx on RMCAT
Bill Ver Steeg (versteb)
versteb at cisco.com
Thu May 24 16:24:31 CEST 2012
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 at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no] On Behalf Of Zaheduzzaman Sarker
Sent: Thursday, May 24, 2012 7:03 AM
To: rtp-congestion at 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 at ericsson.com
www.ericsson.com
============================================
_______________________________________________
Rtp-congestion mailing list
Rtp-congestion at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtp-congestion
More information about the Rtp-congestion
mailing list