[R-C] Effect of ConEx on RMCAT

[Ingemar Johansson S]

Hi

My take is that one can in WebRTC (or in for that matter any other service that will use RMCAT) do feedback in many different ways. We limit ourselves to Video for simpicity. 

One can do receiver based rate adaptation and only feedback rate requests, or.. One can feedback actual congestion signals from the network (packet loss and ECN using e.g RTCP XR) back to the sender, where rate adapatation is done. It does not preclude the use of delay based rate adapation for the cases where the transmission path is buffer bloated.
In the former case (rate requests back to sender) a ConEx enabled sender cannot insert any meaningful information into the IP headers. In the latter case (feedback of packet loss, ECN) it is possible, the question mark is then how often is feedback needed ?

Questions are: 
+ Should one bother with ConEx here ?. I would say that ConEx should be considered when feedback mechanisms are being discussed. Congestion management is a hot topic among operators and I would say that a mechanism that makes services expose the congestion that they cause/experience should improve the chances for them to be accepted without having the packets crippled in an unpredictable way, yes I know ConEx is experimental and may not fly but when one choose between feedback mechanisms one should consider the possibility that ConEx can fly.
+ Do I say that ConEx should be baked into RMCAT ? , probably too early for this but I say that if the appropriate feedback mechanisms are in place, then addition of ConEx is made easier later on.

Of course one can dismiss ConEx because it is too premature but the risk is then that it will be necessary to change the RMCAT specification later on to contain the necessary elements to interoperate well with ConEx.

IPv6 only:  Yes its true but the reasons behind this in the ConEx WG charter are more the results of a lenghtly BoF and WG formation discussion than technical. Re-ECN is a proof of concept which use the precious bit 48 in the IPv4 header. So yes, I believe ConEx can be extended to IPv4 as well (if it is worth the effort)

/Ingemar

> Message: 4
> Date: Thu, 24 May 2012 08:48:05 -0400
> From: John Leslie <john at jlc.net>
> To: Wesley Eddy <wes at mti-systems.com>
> Cc: Zaheduzzaman Sarker <zaheduzzaman.sarker at ericsson.com>,
> 	"rtp-congestion at alvestrand.no" <rtp-congestion at alvestrand.no>
> Subject: Re: [R-C] Effect of ConEx on RMCAT
> Message-ID: <20120524124805.GI2661 at verdi>
> Content-Type: text/plain; charset=us-ascii
> 
> 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>
> 
>