Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

["Piers O'Hanlon" <[e-mail]>]

Hi Bill,

On 4 November 2011 15:29, Bill Ver Steeg (versteb) <[e-mail]> wrote:
> Magnus-
>
> I am still thinking about the problems identified with receivers that have varying levels of capabilities reading the ECN related markings.
>
> In my mind, there are 3 categories of devices - "ECN compliant" (follows the specification), "ECN blind (can't read/write the ECN markings, but does not otherwise mangle the stream)", and "ECN incapable"(barfs on the stream).
>
> The analysis in the draft is spot-on for unicast flows.
>
> For RTP multicast streams, it is pretty clear how to handle ECN-compliant and ECN-incapable devices. There are a few flavors of ECN-blind, and I am still getting educated - so I may be missing some subtlety here, but...... It seems that allowing an ECN blind receiver to join an ECN-enabled multicast stream is fairly innocuous, and will not provide an advantage to that receiver over other receivers of the same flow. If the path allows the device to receive the probe packet, the discovery method works. The RTCP feedback will be received from all of the devices, and the data can be analyzed by the sender. Some of the feedback reports will have the ECN information, and some not.
>
I guess one of the issues is that if misbehaving middlebox is on the
path an ECN marked flow may not be able to traverse it fully or at
all. It is also dependent on what type congestion control is in use -
if receiver driven control is in use then those receivers that are
ECN-blind would potentially enjoy higher rate flow potentially at the
expense of ECN-compliant nodes.

> The alternative is to instantiate another flow that is not ECN marked. If we apply the same fairness test to these two flows, it is not clear that we have made an improvement. If we look at the BW consumption, it is clear that we have made congestion worse rather than better. In fact, we have doubled the BW. It seems to me that if we are trying to control congestion, a single flow is (almost always) better than two flows. This is particularly true of IPTV-style deployments.
>
Sure this is not optimal.

> These thoughts are not rock-solid, and I would like to understand the problem space a bit better.
>
> So, can somebody enlighten me on the following
>
> 1- What Berkeley Sockets extension is used to read the ECN-related bits?
> 2- What hosts in the wild are running operating systems that do not support a variant of these extensions?
>
On Linux, BSD and OSX one can use IP_TOS socket option, with the
setsockopt() call, to set the relevant ECN bits (as the root user on
Linux). On Windows XP one can use the same technique though firstly
one has to enable TOS byte setting by enabling a particular Registry
key ( DisableUserTOSSetting=0 (see
http://support.microsoft.com/kb/248611)}, but this no longer works
beyond Windows XP as they disabled this functionality so raw sockets
are the only option (which I understand are also problematic on later
versions of Windows). One could also probably use the libpcap write
functionality.

To obtain the ECN bits from a packet on Linux, one needs to firstly
set the IP_RECVTOS socket option on the receiving socket, and use the
recvmsg() call to receive a packet, and then retrieve the TOS byte
from the associated csmg structure returned by the recvmsg() call.
Whilst on Windows the only way to retrieve the ECN bits is via a raw
socket, or custom NDIS driver. On OSX/BSD there are no suitable socket
options and one cannot use raw sockets as they do not function for
UDP/TCP sockets (they do work with ICMP), so one has to use
alternatives such the bpf interface, or a REDIRECT socket.

It seems odd that OS manufacturers have ended up providing this
asymmetry in functionality...

Piers

> bvs
>
>
> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Wednesday, October 19, 2011 10:41 AM
> To: Bill Ver Steeg (versteb)
> Cc: Roni Even; [e-mail]
> Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04
>
> Bill,
>
> Thanks for the review. I here respond to the major issues. If needed I
> will follow up on the minor issues, otherwise I will simply implement
> them in the next update.
>
> On 2011-10-12 14:57, Bill Ver Steeg (versteb) wrote:
>>
>> For the multicast case, we need to make it clear that feedback goes to
>> the feedback target, which may be a different device than the source.
>> This document consistently says "feedback goes to the source", which is
>> misleading. See the detailed comments below for the places in which I
>> found it to be most concerning. When viewed in the context of feedback
>> going to a discrete feedback target at the network egress edge (like
>> typical IPTV deployments), it makes sense for the feedback target to use
>> these reports as diagnostic in nature. Perhaps the network has changed
>> topology and caused a bottleneck link to appear, and the feedback is
>> triggering action in the network to fix the congestion in a systematic
>> manner. It is highly unlikely that RTCP feedback will be able to change
>> the rate of a flow in such a system. It is more likely that the system
>> would take other actions, but that is probably beyond the scope of this
>> document.
>
> I think we might not have been sufficient clear on the SSM case. But in
> fact for this to work, the Feedback Targets will need to relay the
> feedback, at least in aggregated form to the source (or at least the
> entity marking the packets as ECN which might be the Distributuion
> Source).
>
>>
>>
>>
>> If a host is unable to read the ECN bits, it can't join an ECN-enabled
>> flow? This seems to be quite onerous, and will likely slow down the
>> adoption of ECN for RTP - particularly in the IPTV multicast case. If an
>> operator needs to dual carry hundreds of video channels (one ECN marked
>> and one not ECN marked), he will simply not implement ECN. I need to
>> think about this a bit more and see if there is a way to make this work.
>> My first instinct was to add a field/bit pattern to the RTCP feedback
>> that says " I joined the ECN enabled flow, but can't actually read the
>> ECT/ECN markings". However, let's think about naïve receivers that do
>> not understand the ECN SDP. They will ignore that SDP line, and join the
>> flow. They will provide their normal feedback, without the ECT/ECN
>> portions. How is this different from a receiver that knows about ECN,
>> but is unable to actually read the ECN bits? Maybe we just treat it like
>> a legacy receiver that does not know about the ECN SDP....... So, we
>> need to think about three receiver populations - fully ECN capable (as
>> currently described in this document), ECN aware in the application but
>> unable to read ECN bits (either acts like a legacy receiver or sends a
>> special RTCP feedback message), ECN unaware (ignores the SDP). I have
>> thought about this in the context of the declarative SDP case using leap
>> of faith, but need to think more about the offer/answer case and the
>> STUN case. We need a way to have each type of receiver unambiguously
>> join the same multicast flow. This would allow an operator to
>> incrementally deploy ECN on multicast flows. If we do not fix this, the
>> operator will be gated on the very last device in his deployment.
>>
>
> Lets start with commenting on the naive receivers, if they join an ECN
> enabled RTP session they will cause the session to stop using ECN. That
> is why we say the same to a receiver that knows about ECN but can't read
> the session. If they join they will force the session into not-ECT
> operations.
>
> Yes, this is onerous. But we can't frankly figure out how we can allow
> any other behavior in any best-effort network. Having receivers get
> preferential treatment of their traffic compared to not-ECT marked in a
> best effort seems problematic if they aren't reporting back on it and
> telling the sender to adjust the bit-rate.
>
> We know from that start that ECN and large scale multicast would be
> problematic and that is not our main target. This as it will be
> difficult to combine source rate modifications with large groups.
>
> I think we authors are still of the opinion that we develop what is safe
> but possibly overly conservative and get that published. If people want
> to improve the ECN in multicast usage later they are free to do so. But
> tackling the issues that arise from letting non ECN capable receivers
> into a group that uses ECN is problematic. So my opinion is that we
> shouldn't change anything in this behavior.
>
>>
>> It would be nice to have the RTCWEB folks take a courtesy look, as they
>> are envisioning some very interesting use cases. I do not think that
>> this presents any specific challenges, but it would be good to have
>> those eyeballs. I see that at least a few of them have provided comments.........
>>
>
> Which RTCWEB folks do you want to have a look at this?
>
> My personal view that I would love to have overturned is that ECN in
> open Internet is so dysfunctional that it is barely worth trying. Thus
> adding ECN support to RTCWEB nodes in the initial phase is lots of work
> for the implementor with very little bang back.
>
>>
>> A few minor points and a bit more specificity on the major
>> points------------
>>
>>
>>
>> There is a delicate balancing act between providing timely congestion
>> notifications to the sender and sending feedback packets into a
>> congested network. It is not clear that the this balancing act is
>> discussed in enough detail in the document. An inexperienced implementer
>> may "do the wrong thing" and send packets to freely, thus making the
>> congestion worse. Perhaps a short paragraph in the introduction would
>> make this clear? Perhaps a paragraph at the end of Page 11? Also in
>> section 7.3.2, as congestion is not highly featured in RFC4585 or
>> RFC3550. Congestion is mentioned in 7.3.2, as is feedback implosion, but
>> there is no warning about how they can interact.
>
> I think we can add more warnings and check that we are clear on that one
> must follow the transmission rules for the session the end-point is
> operating. I would note that congestion is in fact likely asymmetric.
> Thus just because you receive CE marked packets doesn't mean that the
> RTCP FB packets will go over path that is loaded into congestion and of
> course the reverse.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>