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 ============================================
On 5/24/2012 7:02 AM, Zaheduzzaman Sarker wrote:
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.
I do *not* think it's necessary, and that it's a distraction for this RTP group. CONEX is just an "experiment" at the moment; not something being baked into the core of the Internet. It's not something everyone else has to suddenly take into account as part of the network. Maybe someday. CONEX is also for IPv6 ... -- Wes Eddy MTI Systems
Wesley Eddy <wes@mti-systems.com> wrote:
On 5/24/2012 7:02 AM, Zaheduzzaman Sarker wrote:
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.
Yes.
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.
Um... maybe...
+ RTP media is not ConEx enabled: Bitrate may be throttled in the network possibly based on some time of day policy or whatever.
That's a remote possibility.
+ 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.
That's a premature conjecture. If you include the ConEx (IPv6) destination option, it is a license for an audit function to do whatever it may see fit to do with such packets. There are proposals on the ConEx list for what that may be, but they're _only_ discussing what to experiment with in audit functions.
+ 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.
Even that is a premature conjecture.
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.
That's a premature conjecture.
* 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.
That's likely, if ConEx ever gets beyond Experimental status.
* RTP media need to be congestion volume aware.
That would be good, IMHO, but it's still premature.
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.
I'd be happy to discuss how we might apply ConEx to RTP flows, but I see no urgency for such a discussion.
I do *not* think it's necessary, and that it's a distraction for this RTP group.
I quite agree it's not necessary; but I don't entirely agree it's a distraction...
CONEX is just an "experiment" at the moment; not something being baked into the core of the Internet. It's not something everyone else has to suddenly take into account as part of the network. Maybe someday.
Yes, it's a "maybe someday" thing. BTW, I certainly intend no criticism of Zaheduzzaman: the ConEx list itself isn't clear about what policing policies might be tried. -- John Leslie <john@jlc.net>
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
Harald Alvestrand <harald@alvestrand.no> wrote:
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?
I think it's worth reading...
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,
That's not a correct read of draft-ietf-conex-concepts-uses, IMHO. There is utility in having the expected-congestion visible at nodes along the path. There is an expectation that at least one ISP along the path will act on it, but it's premature IMHO to say what that action may be.
while the goal for RMCAT is a function that can be usefully deployed even if it's deployed at the endpoints only.
Agreed! -- John Leslie <john@jlc.net>
On 05/24/2012 03:16 PM, John Leslie wrote:
Harald Alvestrand<harald@alvestrand.no> wrote:
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? I think it's worth reading...
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, That's not a correct read of draft-ietf-conex-concepts-uses, IMHO.
There is utility in having the expected-congestion visible at nodes along the path. There is an expectation that at least one ISP along the path will act on it, but it's premature IMHO to say what that action may be. That's what I said, wasn't it?
- has to be at origin, otherwise info won't get inserted - has to be at destination, otherwise info won't get reflected - has to be in the middle, otherwise nobody will act on the info It doesn't have to be at all the ISPs, but at least one ISP. I think.
while the goal for RMCAT is a function that can be usefully deployed even if it's deployed at the endpoints only. Agreed!
-- John Leslie<john@jlc.net>
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
participants (5)
-
Bill Ver Steeg (versteb) -
Harald Alvestrand -
John Leslie -
Wesley Eddy -
Zaheduzzaman Sarker