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

[Magnus Westerlund <[e-mail]>]

Hi Bob,

See inline for my comments on the three issues.

Bob Briscoe skrev 2010-08-06 00:50:
> 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.

Agreed, I have no issues including that in the spec.

> 
> 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).

Well, that depends on the relative frequency between the ECT and non-ECT
and the actual packet loss rates. But, yes I think you might have
spotted a short coming in our thinking. But I think this is not
completely wrong but is lacking the factor from CE marking, see below.

A very direct method of resolving this issue is to use explicit loss
vectors by using RTCP XR packet loss vectors. The ECN Nonce one doesn't
separate between ECN-CE and packet loss and although possible requires a
bit of going around to find the packet loss rate for ECT. What I can
understand the sender would need to keep its actual transmission
pattern. First count and eliminate the not-ect packets that are lost
from the NONCE vector. Then the remaining marked in the NONCE vector are
CE and packet loss of ECT packets. By removing the number of CE marked
ones from the same report interval based on the ECN report blocks you
would arrive at an approximate number of lost ECT packets. I say
approximate, because you still have the reordering issue that make the
sender uncertain on exactly which packets has been reported in the ECN
report between two RTCP packets.

But lets look at what level of statistics is needed to be able to draw
some conclusions. I agree that for certain operation points there will
be a clear difference between ECT and non-ECT traffic. But lets look at
some examples:

No congestion at all: NON-ECT drop rate should be 0. ECT on capable
transport drop rate 0, one path(s) that are incapable there will be a
drop rate >0.

Low levels of congestion: Non-ECT drop rate at a low level (0.5%). ECT
on capable transport drop rate 0, with CE marking at low level (0.5%),
ECT on incapable path will have a drop rate >0.5.

High level of congestion: NON-ECT drop rate at high level (10%). ECT on
capable transport will have some drop rate x, where 10 > x > 0, The CE
marking rate will be approx 10 - x. ECT on incapable path will see a
drop rate that is > 10.

Based on the above, I think you can determine when there drops on ECT
packets that are not related. This as you can take the CE marking rates
into account. NON-ECT droped packets - CE marked packets should
approximately equal the number of ECT marked drop packets. What I am
unclear on in this case is how big fudge factor you do need. But that
needs to be derived based on statics.

Comments on the above reasoning.


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

Yes, you are correct that it is important that a receiver do keep track
of which packet is the first to count from and thus either doing A or B.
I think we should add a clarification on this issue. As long as you do
either of A or B the sender wouldn't be fooled about the set.

I think from a probing point of view doing B would actually be better.
If one take this as an example the packet sender may could come to the
conclusion that the ECT probes are lost due to incapability rather than
re-ordering. The potential down side is that a probe that has been
received may fall outside of the window and need an additional round.

There are an alternative to B that I think will work, but most likely
are more complex to implement. That is that the sender will move its
start number back as long as possible from the initially received number
as long as there is no hole.

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