Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 T2/ ECN-IP-RTCP

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Oct 2010 15:16:09 +0200

Hi Bob,

Thanks for these comments. I am sorry that I haven't responded earlier.
I have finally gotten to the point of providing my view on the comments.

So the benefit is that RTCP loss rates should be lower when congestion
is high on the path the RTCP message takes. As RTCP packets aren't
sequence nor reported on, there isn't a easy way of using them for
congestion control directly. I am not saying impossible, but it will
require significant amount of work and consume extra space in reports
for fields related to RTCP.

For the sender of the RTCP message to be able to influence the
congestion levels on the path from itself to other end-point(s) it needs
to have media flow over that path. If it has media flowing over that
path, it can reduce its transmission rate and hope that it reduced the
congestion level.

If the RTCP sender doesn't have media flowing form it to the report
consumer, which is true for unidirectional media, like streaming and for
RTCP for SSM, or receiver only behavior in ASM. In those case the RTCP
sending end-point can't affect the congestion level. In addition I think
it is wrong to increase the delivery chance for RTCP when the RTCP
sending end-point can't really reduce the rate of RTCP either, nor get
report on that packets where ECN marked.

>From my perspective the benefit is both questionable to utilize and
minor compared to the additional complexities. Especially after we have
improved your proposal, like getting the re-routing case working better.
Because I think the obvious response to having had ECT working and
suddenly detecting ECT failure is to turn of the ECT on RTCP when
reporting this.

If we in the end do want to enable this, we can write an extension or an
update of the spec, where we override the SHALL.

Cheers

Magnus

Bob Briscoe skrev 2010-08-18 18:29:
> Piers,
> 
> At 20:17 17/08/2010, Piers O'Hanlon wrote:
>> Hi Bob,
>>
>> Thanks for the suggestion on ECN for RTCP - some comments in-line
>> where appropriate and the rest here.
>>
>> One observation is that your mechanism generally relies on
>> bi-directional flows to achieve the signalling
> 
> Looking at your inline comments, I think you've misinterpreted my
> attempt at careful wording. I said, "If B is a pure RTP receiver in a
> unidirectional session, it will never get RTCP reports containing
> counts of ECT and CE," which did not mean "it will never get RTCP
> reports". It meant "Any RTCP reports it gets will never contain
> counts of ECT or CE."
> 
> Nonetheless, I agree my proposed variation to the protocol would only
> ever turn on ECT for RTCP packets if there was some bidirectional RTP
> traffic. That's the best I could do without requiring RTCP reports to
> report on RTCP packets in the other direction. But that's better than nothing.
> 
>> but when there are
>> bidirectional RTP flows then the ECN status of the path would be
>> provided already by the respective RTCP reports in each direction.
> 
> Exactly. That's what I'm proposing to use in order to turn on ECT on
> RTCP packets, which the current draft forbids.
> 
>> It's hard to quantify the added benefit of knowing that the reverse
>> path is getting congested and whether that is worth an extra
>> 2xRTCP_reporting_period of loss....
> 
> You only get this amount of loss if there has been a re-route from a
> working ECN path to a non-compliant one. As stated elesewhere in my
> review, I think the draft is rather paranoid about this possibility.
> 1) Some people already question how much effort the IETF should put
> into making protocols robust to non-compliant muddleboxes
> 2) Once a compliant path has been found, would any reasonable person
> really expect us to worry about losses while timing out after being
> re-routed onto a another path that happens to be non-compliant? The
> conditional probability of being re-routed onto a non-compliant path
> having previously been on a compliant path must surely be low?
> 
>> I guess the probability of each
>> should hopefully be quite different but it is still a potentially
>> nasty hit to take if an ugly muddlebox falls in the way.
> 
> I agree all this is hard to quantify, but this double jeopardy is
> like the risk of a pimple growing on a spot.
> 
>> The other snag is with asymmetric paths, as the fact that the RTCP
>> path is congested may not be indicative of the forward [RTP] path.
> 
> The proposed protocol doesn't require or assume symmetric paths.
> 
> I agree the main /motivation/ I gave for ECT on RTCP is not losing
> RTCP reports /if there is/ correlation between congestion in both
> directions. But the protocol doesn't need this correlation in order
> to work. And there are other motivations anyway.
> 
>> On balance I agree with Ken that it probably isn't worth the extra
>> effort, though I can see the attraction.
> 
> There is little extra effort for the gain you get in typical cases
> (see response to Ken). We certainly should not so emphatically
> prohibit ECT on RTCP packets with the ""SHALL NOT" in the draft,
> given it can 'just work' in most deployment cases, with my proposed variation.
> 
> I think we have different assumptions about which obscure
> possibilities should be considered. For instance, I think a lot of
> the complexity dealing with re-routes onto non-compliant paths is overkill.
> 
> Personally I would leave these choices to implementers, which was the
> spirit behind my proposal to modularise the protocol spec more, so
> certain parts could be made optional.
> 
> 
> Bob
> 
> 
>> Thanks,
>>
>> Piers
>>
>> On 5 August 2010 23:39, Bob Briscoe <[email-masked]> wrote:
>>> Magnus, Ingemar, Colin, Piers, Ken,
>>>
>>> Below are my main technical concerns with draft-ietf-avt-ecn-for-rtp-02 as
>>> promised.
>>> I have used the line numbering here:
>>>
>> <http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-avt-ecn-for-rtp-02.txt>
>>>
>>> T1/ Combining pkts
>>> T2/ ECN-IP-RTCP                         <<<---THIS EMAIL
>>> T3/ Anti-Cheating
>>> T4/ Logging Not-ECT fall-back
>>> T5/ Delivery %age ECT vs Not-ECT
>>> T6/ Pkt Reordering around session start
>>>
>>>
>>> T2/ ECN in the IP header of RTCP reports.
>>> -------------------
>>> "
>>>
>>>
>>> 510        RTCP traffic MUST NOT be ECT marked for the following reason.
>>>
>>>
>>> "
>>> "
>>>
>>>
>>> 1047       The sender SHALL NOT include ECT marks on outgoing RTCP packets,
>>> and
>>> 1048       SHOULD NOT include ECT marks on any other outgoing control
>>> messages
>>> 1049       (e.g.  STUN [RFC5389] packets, DTLS [RFC4347] handshake packets,
>>> or
>>> 1050       ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are
>>> multiplexed
>>> 1051       on the same UDP port.
>>>
>>>
>>> "
>>> If congestion rises on the reverse path it /could/ be a sign that it is
>>> rising on the forward path. Ideally, we want it to be possible
>> for receivers
>>> to mark RTCP reports as ECT so they are not more likely to be
>> lost just when
>>> they are needed to report rising congestion levels. E.g. if the congestion
>>> level on the reverse path is say, 0.5%, then 1 in 200 RTCP reports will be
>>> lost.
>>>
>>> I promised to propose a way to have ECT on RTCP packets that
>> would be robust
>>> to middleboxes dropping ECT packets following a re-route. The
>> solution makes
>>> the following assumptions:
>>> A1) that an ECN-Blocking Muddlebox drops any ECT packet, irrespective of
>>> whether it is RTP or RTCP at the app-layer.
>>> A2) that an RTP source knows how often to expect RTCP reports from
>>> receivers, so it can count when RTCP reporting intervals have
>> passed without
>>> an RTCP report.
>>>
>>> Here's the proposal:* As per the I-D, the session starts without ECT on any
>>> packets.
>>> * First sender(s) introduce ECT on RTP packets through the probing methods
>>> already described in the I-D.
>>> * Consider the unicast case of a session betw A & B.
>>>  - Once A has received 3 successive RTCP reports containing counts of ECT
>>> and CE, it can send its own RTCP reports as ECT.
>>>  - If A subsequently notices that 3 RTCP reporting periods have passed
>>> without a report, or A receives no traffic at all for time [TBA], then A
>>> reverts to sending RTCP reports as Not-ECT.
>>>  - B follows the same two rules as A.
>>>  - If B is a pure RTP receiver in a unidirectional session, it will never
>>> get RTCP reports containing counts of ECT and CE, so it will
>> never switch to
>>> sending its own RTCP reports as ECT. This is because it has no way to test
>>> if ECT packets are getting through.
>>>
>> A 'pure RTP receiver', which doesn't send RTCP isn't compliant with
>> the base RTP spec (rfc3550) - an RTP receiver [only] should still send
>> periodic RTCP Receiver Reports.  Though there are quite a few Voip
>> phones do 'forget' to send RTCP.
>>
>>
>>>  - Then if a re-route sends B>A traffic through an ECN-Blocking Middlebox,
>>> no B>A packets will get through. But after 3 RTCP reporting periods A tells
>>> B in a Not-ECT RTCP report and B reverts to Not-ECT.
>>>  - If a re-route sends both B>A and A>B traffic through an ECN-Blocking
>>> Middlebox, the above behaviour will also recover the session.
>>>
>>> * Multicast multi-source case, A -> B,C,D,E; B -> A,C,D,E; etc.
>>> - Once A has decided it can safely turn on ECT in RTP packets it sends, it
>>> watches for any RTCP reports that report reception of a positive Not-ECT
>>> count but zero ECT or CE count on packets 'A' sent. Once it has received
>>> none of these RTCP reports for three RTCP reporting rounds, 'A' can switch
>>> on ECT for its own RTCP reports. 'A' determines 3 reporting rounds by
>>> picking a couple of receivers and waiting until it receives 3 reports from
>>> each.
>>>  - B,C,D,E follow the same rule.
>>>
>>>  - A cannot test whether its own ECT RTCP reports continue to arrive at
>>> their destinations, because the destinations do not know to expect traffic
>>> from A. So if they are getting no traffic from A because of an
>>> ECN-Blocking  Muddlebox, the transport will never know, although
>>> the application or human may miss the contribution from A and reset
>>> the transport to use Not-ECT on RTCP reports.
>>>
>> Again the receivers should be sending periodic Receiver Reports so A
>> should be able to know the situation.
>>
>>>  - With receiver-initiated multicast, A also cannot test for all sorts of
>>> other blockages that might suddenly appear on paths to some destinations.
>>> Therefore, once an ECN-capable session has been established, it would be
>>> reasonable to take a leap-of-faith that re-routes are likely to continue to
>>> find ECN-capable paths.   - And if the leap-of-faith is not warranted, the
>>> session breaks until the application resets it to Not-ECT - but that's not
>>> surprising if there are broken muddleboxes on some paths.
>>> * Multicast single-source case, A -> P,Q,R,S etc.
>>>  - All follow the same rule as the multi-source case, with the same
>>> limitations.
>>>  - As in the unicast and multi-source cases, if any hosts are pure RTP
>>> receivers (P,Q,R,S), they won't ever get an RTCP report about RTP packets
>>> they have sent, so they will never set ECT on RTCP reports.
>>>
>> There is the option for all parties exchange RTCP report when using
>> SSM by employing RFC5760.
>>
>>> Comparison between ECT-RTCP and Not-ECT-RTCP:
>>> * Session recovery time following a re-route through an ECN-Blocking
>>> Middlebox:
>>>  - ECT-RTCP:           3 RTCP reporting intervals
>>>  - Not-ECT-RTCP:       1 RTCP reporting interval
>>> * ECT-RTCP has more robust RTCP reporting during rising symmetric
>> congestion
>>> * Not-ECT-RTCP involves less implementation (unless using leap-of-faith,
>>> when they are both the same).
>>>
>>> BTW, the assumption that an ECN-Muddlebox will drop any ECT
>> packets, whether
>>> RTP or RTCP, can be relaxed if we add reporting of RTCP packets from A>B in
>>> reports from B>A. But it seems a reasonable assumption so reporting on RTCP
>>> reports should not be necessary.
>>>
>>> Cheers
>>>
>>>
>>> Bob
>>>
>>>
>>>
>>> ________________________________________________________________
>>> Bob Briscoe,                                BT Innovate & Design
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/avt
>>>
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

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: [email-masked]
----------------------------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Oct 2010 15:09:37 +0100

Hi,

I agree with Magnus, Piers and Ken: this extension doesn't seem worth the complexity at this time, and can easily be added later if we see a need.

I also note that RTCP traffic is not congestion controlled. Putting ECT marks on something that won't respond to ECN-CE marks seems undesirable.

Colin

-- 
Colin Perkins
http://csperkins.org/