[R-C] Effect of ConEx on RMCAT
Harald Alvestrand
harald at alvestrand.no
Thu May 24 14:37:56 CEST 2012
On 05/24/2012 01:02 PM, Zaheduzzaman Sarker wrote:
> 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.
Thanks for the heads-up!
I see that
https://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ shows
that one document is already in front of the IESG; is this a good
starting point to read up on it?
>
>
> 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.
What timescales are we talking about here - what's the time over which
ConEx is going to expect congestion information to be accurate?
>
> + 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.
The list's been relatively quiet for a while, so there's room ... the
result of discussion may be "too far out to worry about"; my 0.01 read
is that Conex expects that it has to be deployed in both ISPs and
endpoints before it does any good, while the goal for RMCAT is a
function that can be usefully deployed even if it's deployed at the
endpoints only.
Harald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120524/7c6cddc3/attachment.html>
More information about the Rtp-congestion
mailing list