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

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

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

Ok, that does make sense. I am fine with that suggestion.

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

Well, the issue here is that if one is in a probing phase and only send
some fraction as ECT marked, and the rest without. If one combines them,
we need to indicate which direction these markings should go. The
current text proposes that if any are ECT, the outgoing packet is ECT.
That way ensuring that any ECT are sent at all. In worst case all
packets during the probing are ECT marked. Thus allowing a non-capable
receiver to only detect this based on RTCP. But at least it is being
detected during the probing phase rather than later which would be if
one had a rule saying that if any of the packets being combined is
Not-ECT then mark it as NOT-ECT would result in.

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

Hmm, that is possibly a good idea. I guess we need at least 8 bits for
such a ratio, maybe a couple more would be advantageous to get
sufficient resolution. And if I understand you correct you want the
ratio to be measured as:
R= (ECN-CE marked bytes since last report from this SSRC) / (Total bytes
received since last report from this SSRC)?

Cheers

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 14:58:40 +0100

> Ok, that does make sense. I am fine with that suggestion.

That makes sense, although it seems more aggressive than the rules in RFC 3168. What's the rationale for the change? I read draft-ietf-tsvwg-byte-pkt-congest-02, but that doesn't help my understanding.

> Not-ECT then mark it as NOT-ECT would result in.

I'd suggest: "If the outgoing combined packet is not ECN-CE marked, then it MUST be ECT marked if any of the incoming packets were ECT marked."

> R= (ECN-CE marked bytes since last report from this SSRC) / (Total bytes received since last report from this SSRC)?

What's the benefit? This introduces complexity to avoid what should only be a small rounding error. 

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