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

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

Bill,

On 4 November 2011 17:44, Bill Ver Steeg (versteb) <[e-mail]> wrote:
> Piers-
>
> Thanks for the detailed note, particularly the details around Berkeley sockets. I am digesting the sockets information, and this response is regarding the ECN-blind portions of your note.
>
> My concern is primarily about ECN-blind receivers. The topic of ECN-blind (or ECN-incapable) middleboxes is important, but orthogonal. If the middlebox is ECN-blind, the stream will get through. If it is ECN-incapable, it will not get through and the stream will fall back to a non-ECN stream. I think this is OK as stated in the draft.
>
Yes. Though the detection system in the draft does need to use
ECN-capable nodes to asses the situation. I guess in a 'managed
network' then one may be able to assume that things 'just work',
though there's still the small possibility of misconfiguration of
nodes resulting in the presence of ECN-incapable nodes.

> So, on to the ECN-blind receiver case --- If an ECN-compliant receiver is sharing a given stream with an ECN-blind receiver, how can the ECN-blind receiver get a higher flow rate? If they are receiving different streams, one could make that case. But since they are receiving the same stream they are, by definition, receiving the same rate. In my mind, this is actually an argument for having them share the stream. The system gets feedback from all of the receivers. Some of the feedback has information about ECN and some does not.
>
I was thinking of the case where a congestion control algorithm counts
the number of ECN marks and the number of losses to calculate a total
loss rate. This would then potentially be utilised by the congestion
control algorithm to derive a suitable operating rate. With the
current prevalence of TCP like congestion control algorithms the rate
is proportional to one over the square root of the loss rate - so if
one omits to count the ECN marked packets the resulting rate would be
higher. So as you say in the case where everyone gets the same stream
there no problem, but if there's a layered transmission system or
variable subscription approach (multicast HTTP live streaming?) then
the ECN-blind receiver would end up requesting a higher rate stream
than an ECN-capable node.

Piers.

> bvs
>
>
> -----Original Message-----
> From: Piers O'Hanlon [mailto:[e-mail]]
> Sent: Friday, November 04, 2011 12:56 PM
> To: Bill Ver Steeg (versteb)
> Cc: Magnus Westerlund; [e-mail]
> Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04
>
> 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
>>
>