Subject: [AVT] draft-ietf-avt-ecn-for-rtp-02 Other Tech Concerns

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

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
T3/ Anti-Cheating
T4/ Logging Not-ECT fall-back                   <<<---THIS EMAIL
T5/ Delivery %age ECT vs Not-ECT                <<<---THIS EMAIL
T6/ Pkt Reordering around session start <<<---THIS EMAIL

T4/ Not just fall-back to Not-ECT, but logging or alarms too.
-------------------
"
783        loss of all packets with ECT or ECN-CE markings.  If the 
path between
784        the sender and the receivers exhibits either of these behaviours one
785        needs to stop using ECN immediately to protect both the network and
786        the application.
"
"
1332       Detecting clearing of ECN field:
1337       Dropping of ECT packets:
"
As well as detecting ECN black holes and falling back to Not-ECT, the 
source ought to log the IP address pair exhibiting this problem. This 
could be used for later diagnostics, if someone ever tries to 
systematically clear up this middlemess (e.g. in a corporate 
environment, or anywhere that a network operator has access to these logs).
The logs might also be used as a database for selective leaps-of-faith.

If an appropriate management alarm can be raised, it should be too.

T5/ Comparing Delivery percentage of ECT vs Not-ECT
-------------------
"
1337       Dropping of ECT packets: To determine if the packet drop ratio is
1338       different between not-ECT and ECT marked transmission requires a mix
1339       of transmitted traffic.  The sender should compare if the delivery
1340       percentage (delivered / transmitted) between ECT and not-ECT is
1341       significantly different.  Care must be taken if the number 
of packets
1342       are low in either of the categories.
"
Eh? This surely won't work. Under normal circumstances (ie no 
ECN-Blocking Muddleboxes) Not-ECT packets will be dropped more due to 
congestion and ECT packets will hardly ever be dropped. So the sender 
cannot detect if ECT packets are getting some extra drop due to 
Muddleboxes, by comparing with Not-ECT which will have extra drop for 
another valid reason (congestion).

T6/ Pkt Reordering around session start-------------------
[Just for the record - I've already sent this point off list.]

I will use the term "RTCP ECN Reports" for both the RTCP AVPF NACK 
transport feedback format and the RTCP XR ECN summary report.
"
1281    4.4.2.  Interpretation of ECN Summary information

1306       The counters will be initiated to zero to provide value for the RTP
1307       stream sender from the very first report.  After the first 
report the
1308       changes between the latest received and the previous one is
1309       determined by simply taking the values of the latest minus the
1310       previous one, taking field wrapping into account.  This 
definition is
1311       also robust to packet losses, since if one report is missing, the
1312       reporting interval becomes longer, but is otherwise equally valid.
"
Both proposed RTCP ECN Reports insufficiently define the range of 
packets they cover. They both define the range by the highest 
sequence number and the number of packets covered by the report (the 
sum of the various couters in the report, all counted since the start 
of the receiver's session).

This approach makes report accuracy vulnerable to reordering around 
the start of the session. For instance, suppose teh receiver receives 
the following packets, and imagine the receiver starts its session at 
sequence #126. Then  sends its first report after seq #135:

...119,122,123,124,125,126,127,128,120,121,129,130,132,133,134,135,...

Highest seq no  = #135
Number of losses        = 1 (#131)
packets received        = 11 (which will be broken down into CE, ECT etc)
(Total pkts in report   = 12)

The sender will calculate that this report refers to the 12 packets 
starting at 135-12=#123 and ending at #135.

Then, the sender cannot accurately check whether the number of ECT & 
CE (or Not-ECT) packets reported by the receiver matches the number 
of ECT (or Not-ECT) it sent, because they are both talking about a 
different set of packets. For instance, if the sender sets #123 and 
#124 as ECT probes, these will be counted as ECT by the sender, but 
the receiver puts them outside the range it is reporting on.

This error will be repeated each time the receiver sends a report, 
because it is always cumulative from the start of the session, and 
the problem is an ill-defined session start.

There are three possible solutions:
a) Add text to mandate that the receiver considers the session start 
to be the lowest sequence number after it initialises its counters. 
In the example, the receiver would count the session start as #120 
not #126, even though it initialised its counters at #126. When it 
receives packet #120 it immediately rolls back the start seqno to 
#120 and considers 121-125 as 5 losses. Ultimately, because it later 
receives #121 it only reports #122-125 as 4 losses - even if these 
packets did actually arrive before the counter was initialised.

b) The receiver does not include any packets with seqnos below the 
seqno when it initialised its variables (unless there has been a wrap 
of course). In the example, the receever would not include packets 
#120 & #121 in its RTCP ECN Reports.

c) The RTCP ECN Report formats include an explicit start seqno. I 
don't think this is necessary, given either a) or b) are easy to do.

Am I correct, or have I overlooked something?

____________
FWIW, reordering near the end of the sequence is not a problem. The 
I-D already explains how the receiver can report holes in the 
sequence space as losses in one report, then subtract losses if these 
packets arrive after the report is sent.

Finally, please ignore the statement in my earlier email saying this 
problem also affects nonce counting. I hadn't got to the part of the 
I-D that describes the nonce mechanism when I sent that email.

I would nonetheless add that the nonce was only ever intended to work 
for an ordered protocol. So you have clearly had to go to great 
lengths to get it to work for RTP, by effectively adding a sub-module 
to RTCP that puts the packets in order so that it can report their 
nonces in order. Next email I will try to relieve you of all this 
nonce complexity - I think you should be able to refer to ConEx as a 
potential way to satisfy your anti-cheating requirement so you can 
take out all the nonce complexity. Otherwise, I reckon nonce support 
will approximately double the size of the code for ECN in RTP.

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 30 Aug 2010 15:07:07 +0200

Hi

My comments to T4 and T5.
T4/ Logging Not-ECT fall-back  
I guess this is a suggestion to add appropriate text about logging in the draft text. But it is not necessary to specify what this logging is as this can be made service specific (e.g QoE reporting in 3GPP). Is this correct.

T5/ Delivery %age ECT vs Not-ECT.
There are for sure two extremes here
 1) Delivered # ECT marked < # non-ECT
    This is the serious case as it indicates that a muddlebox discards ECT marked packets
 2) Delivered # ECT marked > # non-ECT  
    This may be perfectly OK 
So I guess the wording needs to be refined here. "The case that (delivered/transmitted) ECT marked is higher than (delivered/transmitted) non-ECT marked may be perfectly normal. The opposite is however an indication that ECT marked packets are dropped with a higher frequency than non-ECT marked packets". This probably needs a rewrite....

Regards
Ingemar 

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: den 6 augusti 2010 00:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: draft-ietf-avt-ecn-for-rtp-02 Other Tech Concerns
> 
> As well as detecting ECN black holes and falling back to 
> Not-ECT, the source ought to log the IP address pair 
> exhibiting this problem. This could be used for later 
> diagnostics, if someone ever tries to systematically clear up 
> this middlemess (e.g. in a corporate environment, or anywhere 
> that a network operator has access to these logs).
> ECN-Blocking Muddleboxes) Not-ECT packets will be dropped 
> more due to congestion and ECT packets will hardly ever be 
> dropped. So the sender cannot detect if ECT packets are 
> getting some extra drop due to Muddleboxes, by comparing with 
> Not-ECT which will have extra drop for another valid reason 
> (congestion).
> 
> I will use the term "RTCP ECN Reports" for both the RTCP AVPF 
> NACK transport feedback format and the RTCP XR ECN summary report.
> "
> Both proposed RTCP ECN Reports insufficiently define the 
> range of packets they cover. They both define the range by 
> the highest sequence number and the number of packets covered 
> by the report (the sum of the various couters in the report, 
> all counted since the start of the receiver's session).
> 
> This approach makes report accuracy vulnerable to reordering 
> around the start of the session. For instance, suppose teh 
> receiver receives the following packets, and imagine the 
> receiver starts its session at sequence #126. Then  sends its 
> first report after seq #135:
> 
> The sender will calculate that this report refers to the 12 
> packets starting at 135-12=#123 and ending at #135.
> 
> Then, the sender cannot accurately check whether the number 
> of ECT & CE (or Not-ECT) packets reported by the receiver 
> matches the number of ECT (or Not-ECT) it sent, because they 
> are both talking about a different set of packets. For 
> instance, if the sender sets #123 and
> #124 as ECT probes, these will be counted as ECT by the 
> sender, but the receiver puts them outside the range it is 
> reporting on.
> 
> This error will be repeated each time the receiver sends a 
> report, because it is always cumulative from the start of the 
> session, and the problem is an ill-defined session start.
> 
> a) Add text to mandate that the receiver considers the 
> session start to be the lowest sequence number after it 
> initialises its counters. 
> In the example, the receiver would count the session start as 
> #120 not #126, even though it initialised its counters at 
> #126. When it receives packet #120 it immediately rolls back 
> the start seqno to #120 and considers 121-125 as 5 losses. 
> Ultimately, because it later receives #121 it only reports 
> #122-125 as 4 losses - even if these packets did actually 
> arrive before the counter was initialised.
> 
> b) The receiver does not include any packets with seqnos 
> below the seqno when it initialised its variables (unless 
> there has been a wrap of course). In the example, the 
> receever would not include packets #120 & #121 in its RTCP 
> ECN Reports.
> 
> c) The RTCP ECN Report formats include an explicit start 
> seqno. I don't think this is necessary, given either a) or b) 
> are easy to do.
> 
> FWIW, reordering near the end of the sequence is not a 
> problem. The I-D already explains how the receiver can report 
> holes in the sequence space as losses in one report, then 
> subtract losses if these packets arrive after the report is sent.
> 
> Finally, please ignore the statement in my earlier email 
> saying this problem also affects nonce counting. I hadn't got 
> to the part of the I-D that describes the nonce mechanism 
> when I sent that email.
> 
> I would nonetheless add that the nonce was only ever intended 
> to work for an ordered protocol. So you have clearly had to 
> go to great lengths to get it to work for RTP, by effectively 
> adding a sub-module to RTCP that puts the packets in order so 
> that it can report their nonces in order. Next email I will 
> try to relieve you of all this nonce complexity - I think you 
> should be able to refer to ConEx as a potential way to 
> satisfy your anti-cheating requirement so you can take out 
> all the nonce complexity. Otherwise, I reckon nonce support