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

Magnus Westerlund <> Wed, 19 October 2011 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D3BB21F8AB8 for <>; Wed, 19 Oct 2011 07:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.553
X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dTJ6rtH1wZgP for <>; Wed, 19 Oct 2011 07:41:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 30C2521F8A71 for <>; Wed, 19 Oct 2011 07:41:38 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-f6-4e9ee1874705
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 09.87.20773.781EE9E4; Wed, 19 Oct 2011 16:41:11 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 19 Oct 2011 16:41:10 +0200
Message-ID: <>
Date: Wed, 19 Oct 2011 16:41:08 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Bill Ver Steeg (versteb)" <>
References: <016101cc7f6c$9795e380$c6c1aa80$> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Oct 2011 14:41:40 -0000


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

> 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

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.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: