[R-C] Effect of ConEx on RMCAT

[John Leslie]

Wesley Eddy <wes at 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 at jlc.net>