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

["Bill Ver Steeg (versteb)" <[e-mail]>]

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. 

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.

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?

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]
----------------------------------------------------------------------