[R-C] Effect of ConEx on RMCAT

[Harald Alvestrand]

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>