Subject: [AVT] draft-ietf-avt-ecn-for-rtp-02 T1/ Combining pkts

From: Bob Briscoe <[email-masked]>
Date: Thu, 05 Aug 2010 23:36:37 +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                      <<<---THIS EMAIL
T2/ ECN-IP-RTCP
T3/ Anti-Cheating
T4/ Logging Not-ECT fall-back
T5/ Delivery %age ECT vs Not-ECT
T6/ Pkt Reordering around session start

T1/ Combining packets: Fragmentation and Reassembly
-------------------
"

317           *  If the translator modifies the media stream to 
combine or split
318              RTP packets, but does not otherwise transcode the media, it
319              must manage the ECN bits in a way analogous to that described
320              in Section 5.3 of [RFC3168]:

"
Don't agree. The fragmentation and reassembly rules in RFC3168 were 
designed around TCP. They aren't applicable to RTP. See the argument 
about RFC3168 at the time it was in last call:
<http://www.ietf.org/mail-archive/web/tsvwg/current/msg00196.html>
This email refers to S.11 on fragmentation of this review of 
draft-ietf-tsvwg-ecn-01 before it became RFC3168:
<http://www.bobbriscoe.net/projects/2020comms/ecn/protocol/ip/draft-ietf-tsvwg-ecn-ip-00.txt>

"

322              identically to the original; if several ECN marked packets are
323              combined into one, the outgoing packet must be either ECN-CE
324              marked or dropped if any of the incoming packets are ECN-CE
325              marked,
"
I suggest:
"...the outgoing packet SHOULD be ECN-CE marked with a probability 
proportional to the ratio of ECN-CE bytes to total bytes in the 
incoming packets being combined. However, for simplicity, the 
outgoing packet MAY be ECN-CE marked if any of the incoming packets 
are ECN-CE marked. This latter option will inflate the amount of 
congestion indicated, but it is at least safe.
"

325                      and should be ECT marked if any of the 
incoming packets
326              are ECT marked.

"
I think this clause should shift to before the preceding one that 
starts on line 323. It is a more logical order to first check whether 
all packets being combined are ECN-capable before combining CE markings.
(I take it that the logic here is that some RTP sources may not be 
ECN capable, but if ECT packets are being sent by other sources, it 
implies all potential receivers are ECN-capable.)

"

1757       When rounding counter values in the translated RTCP packet, the
1758       translator should try to ensure that they sum to the number of RTP
1759       packets in the pre-translation sequence number space (numOrig).  The
1760       translator should also try to ensure that no non-zero counter is
1761       rounded to a zero value, since that will lose information that a
1762       particular type of event has occurred.

"
An idea: Include a field in the RTP ECN feedback packet for the 
ratio, R. Then, rather than the translator translating all the 
numbers in the report, the host receiving the message can do the 
translations, but it also has the original information.

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design