<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 05/24/2012 01:02 PM, Zaheduzzaman Sarker wrote:
<blockquote cite="mid:4FBE154C.4080301@ericsson.com" type="cite">Hi,
<br>
<br>
One topic that so far have not been discussed in this mailing list
is the ConEx and it's effect on congestion avoidance.
<br>
<br>
ConEx Background: IETF ConEx WG is chartered here
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/wg/conex/charter/">https://datatracker.ietf.org/wg/conex/charter/</a>. 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.
<br>
</blockquote>
Thanks for the heads-up!<br>
<br>
I see that
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="https://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/">https://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/</a>
shows that one document is already in front of the IESG; is this a
good starting point to read up on it?<br>
<br>
<blockquote cite="mid:4FBE154C.4080301@ericsson.com" type="cite">
<br>
<br>
The effects:
<br>
<br>
+ RTP media is not ConEx enabled: Bitrate may be throttled
<br>
in the network possibly based on some time of day policy or
whatever.
<br>
<br>
+ 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.
<br>
</blockquote>
What timescales are we talking about here - what's the time over
which ConEx is going to expect congestion information to be
accurate?<br>
<blockquote cite="mid:4FBE154C.4080301@ericsson.com" type="cite">
<br>
+ RTP media is ConEx enabled and timely feedback of congestion
info to
<br>
sender: Packets will pass through unaffected by the ConEx policers
as long as congestion volume quota is not exceeded.
<br>
<br>
This means:
<br>
<br>
* 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.
<br>
<br>
* 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.
<br>
<br>
* RTP media need to be congestion volume aware.
<br>
<br>
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.
<br>
</blockquote>
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.<br>
<br>
Harald<br>
<br>
<br>
</body>
</html>