Subject: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith initialisation?

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 21 Dec 2010 18:25:50 +0100

Dear Magnus,

allow me to continue a discussion we had about a month ago.

You were suggesting that the leap of faith initialisation method
requires AVPF because this allows XR ECN summary reports can then be
sent quicker and shorter reporting interval than the average 5secs can
be negotiated. Correct?

The draft contains the following related procedure in 6.2.3:

   If the sender marks all packets as ECT while transmitting on a path
   that contains an ECN-blocking middlebox, then receivers downstream of
   that middlebox will not receive any RTP data packets from the sender,
   and hence will not consider it to be an active RTP SSRC.  The sender
   can detect this and revert to sending packets without ECT marks,
   since RTCP SR/RR packets from such receivers will either not include
   a report for sender's SSRC, or will report that no packets have been
   received, but this takes at least one RTCP reporting interval.  It
   should be noted that a receiver might generate its first RTCP packet
   immediately on joining a unicast session, or very shortly after
   joining a RTP/AVPF session, before it has had chance to receive any
   data packets.  A sender that receives RTCP SR/RR packet indicating
   lack of reception by a receiver SHOULD therefore wait for a second
   RTCP report from that receiver to be sure that the lack of reception
   is due to ECT-marking.  Since this recovery process can take several
   tens of seconds, during which time the RTP session is unusable for
   media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation
   method be used in environments where ECN-blocking middleboxes are
   likely to be present.

So there is no particular trigger for the receiver to sent SR/RR reports
that would allow it to benefit from the more flexible timing rules of
AVPF.
One could think about using the AVPF early RTCP feedback if the sender
does not receive any packets for a while at call setup, but the duration
is quite open and it might also be part of normal operation that no
packets are received - consider early media that are usually only
transmitted in backward direction as an example.

You suggested to negotiate a higher RTCP transmission rate as a remedy.
In my understanding this would work both with AVP and AVPF using SDP
RTCP bandwidth modifiers.
But I am not convinced this is a good idea given the extra required
bandwidth. There is a clear wording already that the leap of faith
method is not  recommended in environments where ECN-blocking
middleboxes are likely to be present. It is really meant for operator
controlled environments where such problems will hardly occur. Is it
really worth spending more bandwidth to improve the handling of a very
unlikely event? If there is a real risk that ECN-marked packets are
blocked in a network, other initialisation methods are preferable
anyway.

As said, I also still doubt that you would have any benefit from AVPF
for that initialisation method. But even I only fail to understand the
advantages you had in mind (do you assume some particular receiver
behaviour described nowhere up to now?),  I doubt this would be worth
the extra complexity, only to improve  the handling of a very unlikely
error. Again, in an network where there is a real risk that ECN-marked
packets are blocked, other initialisation methods are preferable anyway.

As an unrelated question, are you working on an update of the draft?
It would be quite helpful to have it available for the upcoming SA4
meeting. I would also welcome if you could share the draft with me for a
quick review before distributing it further, at least if time allows.

Regards, Thomas