Subject: [AVT] Review: draft-ietf-avt-ecn-for-rtp-02 Wordsmithing

From: Bob Briscoe <[email-masked]>
Date: Thu, 05 Aug 2010 23:25:33 +0100

Magnus, Ingemar, Colin, Piers, Ken,

Below are my comments concerning word-smithing draft-ietf-avt-ecn-for-rtp-02.
Technical concerns will be in following emails.
Then I'll annotate editorial nits into the source of the draft itself.

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>

W1/ Overall maturity
W2/ More Modular Please
W3/ Order of sections
W4/ Non-specific motivating text
W5/ Differences from TCP family
W6/ What 'ECN support' means
W7/ Additional requirement
W8/ Why does RTP-ECN require rapid feedback?
W9/ Clearing the STUN V bit?
W10/ Any difference between speed of feedback for ECN vs loss?
W11/ Fourth reason for ECN probing
W12/ Late Join
W13/ Paranoia once ECN support established
W14/ Leap of faith is not so bad
W15/ Don't jump to pessimistic conclusions
W16/ Fragmentation & Reassembly
W17/ IANA SDP requirements
W18/ On-path attacks are limitless
W19/ ECN tunnel covert channel not relevant

W1/ Overall maturity
-------------------
This draft is a tour-de force. Thank you for pulling this all 
together - especially as it started as two separate drafts.

For stds track it still feels like it needs to be crisper and 
clearer. There's a lot of places where it needs to just say what you 
have to implement, rather than describing the problem that was solved 
when designing the protocol. And more attention will be needed over 
including capitalised normative text: MUSTs, SHOULDs etc. where at 
the moment it just says what an implementer might need to do.

W2/ More Modular Please
-------------------
I would rather see various functions described that can be included 
or excluded in a modular way. Then we can say whether each is a MAY, 
SHOULD or MUST. E.g.
- Session initiation check for ECN support along the path
- Continuing checks for ECN support once initialised
- ECT on RTCP packets (if you agree with my arguments in the next email)
- ECN Nonce (separate draft - see next email)
- ConEx (separate draft - see next email)

There is already a lot of duplicate text throughout this draft, so I 
suspect it needs an overhaul anyway. In the process it could be 
modularised - although it's quite a big beastie now - I wouldn't 
relish being the one to have to rationalise it.

W3/ Order of sections
-------------------
"
907           ECN initiation is considered to have failed at the instant when
908           any RTP session participant sends an RTCP packet that doesn't
909           contain an RTCP ECN feedback report or ECN summary 
report, but has
910           an RTCP RR with an extended RTP sequence number field that
911           indicates that it should have received multiple (>3) ECT marked
912           RTP packets.
"
"
1229       The ECN feedback packet allows the sender to compare the number of
1230       ECT marked packets of different type with the number it actually
1231       sent.  The number of ECT packets received plus the number of CE
1232       marked and lost packets should correspond to the number of sent ECT
1233       marked packets.
"
"
1286       Lets start to review the information the reports provide on a per
1287       source (SSRC) basis:
1289       CE Counter:  [...]
"
During these passages in S.4 (as S.4.2.1 onwards), I repeatedly felt 
I needed to have read section 5 first. These sections talk in great 
depth about fields in the RTCP reports that have not yet been 
introduced. At least refer forward to S.5, and preferably consider 
re-ordering the sections.
My remaining comments are in the order of their appearance in the draft.

W4/ Non-specific motivating text
-------------------
"

105        This congestion signal allows applications to react in a controlled
106        manner, rather than responding to uncontrolled packet loss, and so
107        improves the user experience while benefiting the network.

109                                In addition, the use of ECN support outlined
110        in this document helps minimize the disruption of the flow (and the
111        user experience) by rapidly conveying congested conditions without
112        packet loss."

I agree with the second part, but 'controlled manner' isn't clear. 
How about the following motivating text:

"ECN provides a way for networks to send congestion control signals 
to a media transport without having to impair the media. Unlike 
losses, the signals unambiguously indicate congestion to the 
transport as quickly as feedback delays allow, and without confusing 
congestion with losses that might have occurred for other reasons 
such as transmission errors, packet-size errors, routing errors, 
badly implemented middleboxes, policy violations and so forth."

W5/ Differences from TCP family-------------------
"
167                                              However, RTP is more commonly
168        run over UDP.  This combination does not currently support ECN, and
169        we observe that it has significant differences from the other
170        transport protocols for which ECN has been 
specified.  These include:
"
Suggest an extra bullet:

    Counting vs Detecting Congestion: TCP and the protocols derived 
from it are designed to respond the same whether they experience a 
burst of congestion indications within one RTT or just one. Whereas 
real-time applications are concerned with the amount of congestion 
experienced, whether it is distributed smoothly or in bursts. When 
feedback of ECN was added to TCP [RFC3168], the receiver was designed 
to flip the echo congestion experienced (ECE) flag to 1 for a whole 
RTT then flop it back to zero. Whereas ECN feedback in RTCP will need 
to report a count of how much congestion has been experienced within 
an RTCP reporting period, irrespective of round trip times.

W6/ What 'ECN support' means-------------------
"
206        do not invalidate the need for ECN support.  Indeed, in many ways,
207        ECN support is more important for RTP sessions, since the impact of
208        packet loss in real-time audio-visual media flows is highly visible
209        to users.
"

It's not spelled out clearly to the uninitiated that ECN can be used 
in a session without ECN support in all queues on all the paths 
between the endpoints. Whereas all hosts in a session need to support 
ECN before they can use it.

To this end, before talking about ECN support as in the above, it 
would be useful to have phrases defined to describe different sorts 
of ECN support. Suggestions:
- ECN-Capable Host
- ECN-Capable Transport (ECT = all ends are ECN-Capable Hosts)
- ECN-Capable Packets (packets marked ECT or CE)
- ECN-Oblivious Relay (router or middlebox that treats ECN-Capable 
Packets no differently from Not-ECT)- ECN-Capable Queue (supports ECN 
marking of ECN-Capable Packets)
- ECN-Blocking Middlebox (discards ECN-Capable Packets)
- ECN-Reverting Middlebox (changes ECN-Capable Packets to Not-ECT)

We could call this last two ECN-Muddleboxes and ECN-Meddleboxes :)

W7/ Additional requirement
-------------------
"
223        requirements that must be satisfied to at least some degree
"
I suggest we add:
    o REQ 7: An RTP sender MUST NOT send packets with ECT in the IP 
header unless it knows all potential receivers will understand any CE 
indications they might receive. Otherwise there is a danger that 
congestion indications will be ignored and lost, making the session 
unresponsive to congestion. If there were widespread failure to keep 
to this requirement, congestion collapse could result.

W8/ Why does RTP-ECN require rapid feedback?
-------------------
"
747        As described in Section 4.3.3, RTP sessions using ECN require rapid
748        RTCP ECN feedback, in order that the sender can react to ECN-CE
749        marked packets.  Thus, the use of the Extended RTP Profile for RTCP-
750        Based Feedback (RTP/AVPF) [RFC4585] MUST be signalled.
"
IMHO this ought to be a MAY or possibly a SHOULD (unless I don't 
understand RTCP without the AVPF). How quickly the session adapts to 
congestion and therefore how quickly it needs feedback is a 
characteristic of the media session. ECN feedback (or loss feedback) 
could be just as useful for sluggish adaptation if that's all the 
application is prepared to allow. We can hope there is more elastic 
traffic to deal with short term congestion episodes, but it is still 
useful for semi-elastic media to adapt on slower timescales if 
congestion remains persistent.

BTW, S.4.3.3 doesn't describe anything about needing /rapid/ 
feedback. It just talks about how congestion control might be done, 
allowing a range of choices - some faster, some slower.

If this requirement is changed, there are other places that repeat it, e.g.
"
858                           Reception of subsequent ECN-CE marked packets
859           SHOULD result in additional early or immediate ECN feedback
860           packets being sent.
"
W9/ Clearing the STUN V bit?
-------------------
"
975        packet the request was received in.  Upon forming the response the
976        server SHALL include the ECN Check attribute setting the V bit to
977        valid and include the read value of the ECN field into the 
ECF field.
"
Under what circumstances does the server clear the V bit in its response?
W10/ Any difference between speed of feedback for ECN vs loss?
-------------------
Or are we saying ECN feedback needs to be more rapid than feedback of 
losses? If so, why? Both can drive adaptive codec selection on 
similar timescales.
"
1053    4.3.2.  Reporting ECN Feedback via RTCP
"
Throughout this section I kept wondering whether it was saying that 
reporting CE was any different to report losses. If it isn't just say 
so. If it is, say why.

W11/ Fourth reason for ECN probing
-------------------
"

820        Generating ECN Probe Packets:
822                                                         [...]  The main
823           reason for only marking some packets is to maintain usable media
825                                           [...]  A secondary reason to send
828              [...]          The not-ECT packets also provide a base-line to

"
A fourth reason for only probing with a small number of packets is to 
reduce the risk that significant numbers of congestion markings might 
be lost if ECT is cleared to Not-ECT by an ECN-Reverting Meddlebox. 
Then any resulting lack of congestion response is likely to have 
little detrimental affect on others.

BTW, it would be clearer to list these four reasons as bullets.

W12a/ Late Join of a receiver-------------------
"
408        The solution for using ECN with RTP over UDP/IP consists of four
409        different pieces that together make the solution work:
411        1.  Negotiation of the capability to use ECN with RTP/UDP/IP
413        2.  Initiation and initial verification of ECN capable transport
415        3.  Ongoing use of ECN within an RTP session
417        4.  Failure detection, verification and fallback
"
Doesn't there need to be a 'late-join' piece between 3 & 4, in order 
to cater for the most general type of session?

"
441           each other.  If a new receiver joins an existing session it also
442           needs to verify ECN support.  If verification fails the sender
443           needs to stop using ECN.  As the sender will not know of the
444           receiver prior to it sending RTP or RTCP packets, the sender will
445           wait for the first RTCP packet from the new receiver to determine
446           if that contains ECN feedback or not.
"
This whole para needs a re-write as it's not clear who has to do what:
- "The sender will wait..." sounds ambiguously as if it sends nothing 
until the first packet from a new receiver.
- if the new receiver does not support ECN, it won't be able to 
"verify ECN support" itself.

Here's a suggested replacement para:

"If a new receiver joins an existing session it will reveal whether 
or not it supports ECN when it sends its first RTCP report to each 
source.  If the RTCP report includes ECN information, verification 
will have succeeeded and sources can continue to send ECT packets. If 
not, verification fails and each sender MUST stop using ECN.

Prior to a new receiver sending its first RTP or RTCP packets, no 
sender will know the receiver has joined. There will always be a risk 
that ECT packets from a sender might have been marked CE due to 
congestion, and that the new receiver will not understand CE markings 
and ignore them. However, this risk will only last until the receiver 
sends its first RTCP report to each source.
"

W12b/ Late Join of a source-------------------
I don't think these two cases are explicitly distinguished:
- Late join of an ECN-capable source: it starts out sending Not-ECT 
ECT packets while other sources can continue to send ECT RTP packets 
(at least until the new source shows it is also a non-ECN receiver by 
sending an RTCP report without mentioning ECN). It does the probing 
tests and can eventually send ECT packets like the others.
- Late join of a Not-ECN-capable source: it always sends Not-ECT 
packets. Other sources can continue to send ECT RTP packets (at least 
until the new source sends a non-ECN RTCP report, showing it is also 
a non-ECN receiver of the session).

W13/ Paranoia once ECN support established
-------------------
"
919        convey ECN feedback; Section 4.3 describes the ongoing monitoring
920        that must be performed to ensure the path continues to robustly
921        support ECN.
"
The word 'must' here is too strong, even in lower case. A 
leap-of-faith is entertained for starting a session. Once ECN-support 
has been established, I felt the most reasonable approach would be to 
allow a leap-of-faith that the session will continue to support ECN."
1273       We foresee the possibility of flapping ECN capability due to several
1274       reasons: video switching MCU or similar middleboxes that selects to
1275       deliver media from the sender only intermittently; load balancing
1276       devices may in worst case result in that some packets take a
1277       different network path then the others; mobility solutions that
1278       switches underlying network path in a transparent way for the sender
1279       or receiver; and membership changes in a multicast group.
"
Yes, these are all possible, but they might also re-route the traffic 
through a box that has a flappy route table, or excessive reordering, 
or any number of other problems. If one path is working, it is surely 
more likely that other paths are working too. I think this all gets 
rather contrived. We should not add so much complexity to an I-D 
unless we have actual evidence that good paths are likely to flap 
into bad paths. Otherwise we are tilting at windmills [Don Quixote].

If an RFC3168 TCP-ECN session gets re-routed through an ECN-Reverting 
Meddlebox or an ECN-Blocking Muddlebox it has no mechanism to 
discover that ECN support has been lost. It just carries on 
regardless. We just consider it 'one of those things' that happens. 
So why be so much more careful for RTP-ECN than TCP-ECN?

If a network contains broken middleboxes, things will break. If you 
pay peanuts, you get monkeys. We all experience strange squeaks and 
farts on the Internet and never know why. ECN is only one of many 
things that might be the problem.

In fact, RFCs should be fairly timeless. This I-D should be useful 
even if the Internet evolves so that ECN muddleboxes and meddleboxes 
can generally be assumed to have dwindled in number. I feel this I-D 
errs rather too much towards assuming most things are broken, rather 
than most things should work.

W14/ Leap of faith is not so bad-------------------
"
979     4.2.3.  Leap of Faith ECT initiation method

981        This method for initiating ECN usage is a leap of faith that assumes
982        that ECN will work on the used path(s).  It is not generally
983        recommended as the impact on both the application and the 
network may
984        be substantial if the path is not ECN capable.  Applications may
985        experience high packet loss rates, this is both from dropped ECT
986        marked packets, and as a result of driving the network into higher
987        degrees of congestion by not being responsive to ECN marks.  The
988        network may experience higher degrees of congestion due to the
989        unresponsiveness of the sender due to lost ECN-CE marks from non-
990        compliant re-marking.
"
"
1012       This method is only recommended for controlled 
environments where the
1013       whole path(s) between sender and receiver(s) has been built and
1014       verified to be ECT.  It is NOT RECOMMENDED that the 
leap-of-faith ECT
1015       initiation method is used on unmanaged public Internet paths.
"
Chill. I don't think leap of faith will make the sky fall. I think it 
should be described without so much panic alarm. At the moment it 
says "Leap of Faith Worked Shock! The Internet worked like it says in 
the manual! Crack open a bottle of cider!"

Most current RTP sessions are unresponsive and the sky isn't falling.

Again, RFCs are meant to be fairly timeless. This amount of panic 
could look paranoid in the future.

W15/ Don't jump to pessimistic conclusions-------------------
"
1007                                            A sender that receives RTCP
1008       SR/RR packet indicating lack of reception by a receiver 
may therefore
1009       have to wait for a second RTCP report from that receiver to be sure
1010       that the lack of reception is due to ECT-marking.
"
s/may/SHOULD/ or even MUST?

W16/ Fragmentation & Reassembly
-------------------
"
1695                                           If multiple data packets are re-
1696       encoded into one, or vice versa, the RTP translator MUST assign new
1697       sequence numbers to the outgoing packets.  Losses in the 
incoming RTP
1698       packet stream may also induce corresponding gaps in the outgoing RTP
1699       sequence numbers.  An RTP translator MUST rewrite RTCP packets to
1700       make the corresponding changes to their sequence numbers, and to
1701       reflect the impact of the fragmentation or reassembly.
"
This all seems to be stuff that should be generic for translating any 
RTP streams, not just ECN. Is this already specified somewhere else? 
If not, it shouldn't only be specified in the ECN-RTP spec, which 
isn't where people would expect to find it.

"
1743       example, if the translation process combines two RTP packets into
1744       one, then numOrig will be twice numTrans, giving R=0.5, and the
1745       counters in the translated RTCP ECN feedback packet will be twice
1746       those in the original.
"
s/twice/half/
W17/ IANA SDP requirements
-------------------
"
1889       capable transport).  This attribute should be put in the 
SDP offer if
1890       the offering party wishes to receive an ECT flow.
"
s/receive/send/ I think?

W18/ On-path attacks are limitless-------------------
"
1919       External threats to the RTP and RTCP traffic:

1921       Denial of Service affecting RTCP:  For an attacker that can modify
1935       Information leakage:  The ECN feedback mechanism exposes the
"
There is no need to say so much about possible on-path attacks. It's 
obvious that an attacker that has control of an intermediate node can 
mount vast numbers of possible attacks by altering, deleting, or 
tapping information.

I would suggest this is said, rather than listing a small selection 
of possible attacks. Then state the text already there about defence 
using standard e2e security techniques such as integrity protection, 
message authentication, and encryption. [Ought to have some 
references to RFCs specifically on securing RTP streams, in 
particular in multicast scenarios, which is a hard problem.]

But then, to point out those ECN-specific attacks that an on-path 
attacker can still mount, even with e2e security, which are all 
mentioned in RFC3168 (because the ECN field has to be mutable, and so 
cannot be covered by e2e integrity protection).

Then finally add that there should be no additional vulnerabilities 
created when adding ECN to RTP, because app-layer payloads can all be 
protected by e2e security techniques.

W19/ ECN tunnel covert channel not relevant-------------------
"
2012       ECN as covert channel:
"
Suggest this para is deleted. It is no more relevant to RTP-ECN than 
to any other transport. And there's no mention of tunnelling anywhere 
else in the draft, because it's orthogonal to RTP-ECN. And anyway, 
even if this were relevant to RTP-ECN, the ecn-tunnel draft says the 
security area consider the ECN covert channel to be a non-problem.

Cheers, HTH

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design