Subject: [AVT] Review of draft-johansson-avt-rtcp-avpf-non-compound-00.txt

From: lazzaro <[email-masked]>
Date: Wed, 14 Feb 2007 14:41:46 -0800

Hi everyone,

	One of our co-chairs asked me to evaluate
draft-johansson-avt-rtcp-avpf-non-compound-00.txt
for WG item status.  This is my review.

	This I-D wishes to legitimize sending RTCP
AVPF packets that are not compound-packets --
these RTCP packets would not begin with an SR/RR
and would not include SDES w/ a CNAME.  At the
moment RTCP packets of this nature are forbidden
by RFC 3550.  Cellular push-to-talk, a fielded service,
breaks this RFC 3550 already (OMA-PoC as mentioned
in the I-D).

	This goals of the I-D seem reasonable to me,
so I'm in favor of making it a WG item.  Some
other comments follow:

o   The current I-D is limited in scope to AVPF.  If
we have reason to believe that users of the other
profiles will also want to legitimize non-compound RTCP
at some later date, I believe we should expand the scope
of this I-D to all profiles, in anticipation.  That sort of
anticipation is one way we can keep AVT's workload
manageable.

o  I'm under the impression that many fielded applications
multiplex RTP and RTCP on the same port; Colin has an
I-D in progress trying to legitimize that practice.  It
doesn't take much imagination to see how non-compound
RTCP packets would break fielded code that does the
demultiplex by looking for magic numbers in the PT field.

o  If we can either (1) write this I-D to conform to the
rules OMA-PoC uses for sending RTCP, or (2) get
buy-in from the OMA-PoC folks to issue a revision
that matches this I-D, it would be best.  Otherwise,
we are "closing the barn door after the horse has
run away".

o  The I-D needs an English grammar rewrite -- key
problems are singular/plural noun/verb matching,
a/an problems, to/too problems ... while normally
"just let the RFC editor handle it" is OK, I think there
are so many errors that a grammar pass should be
done sooner, so that we can concentrate on the
content.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Wed, 14 Feb 2007 20:01:59 -0500

Overall sounds good.

>demultiplex by looking for magic numbers in the PT field.

Are there such fielded applications?  Anyone know of any?  List? I haven't
seen or heard of any, but I'm not a good judge.  If there are, do they
signal this?  How?  (Note: a=rtcp with the same port number can cause
problems with SBCs that don't understand it; see Colins draft.)

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: lazzaro <[email-masked]>
Date: Wed, 14 Feb 2007 17:39:03 -0800

> problems with SBCs that don't understand it; see Colins draft.)

My level of certainty is summed up by my choice of
"I'm under the impression" in the quoted sentence :-).
Hopefully someone reading the list can chime in with
real information ...

---
John Lazzaro

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Thu, 15 Feb 2007 11:12:54 +0100

Hi

Thanks for the comments, my comments inline with text below

> -----Original Message-----
> From: lazzaro [mailto:[email-masked]] 
> Sent: den 14 februari 2007 23:42
> To: [email-masked]
> Cc: lazzaro; Joerg Ott; Colin Perkins; Roni Even; Tom-PT 
> Taylor; Ingemar Johansson S (LU/EAB); Magnus Westerlund (KI/EAB)
> Subject: Review of draft-johansson-avt-rtcp-avpf-non-compound-00.txt
> 
> Hi everyone,
> 
> 	This I-D wishes to legitimize sending RTCP AVPF packets 
> that are not compound-packets -- these RTCP packets would not 
> begin with an SR/RR and would not include SDES w/ a CNAME.  
> At the moment RTCP packets of this nature are forbidden by 
> RFC 3550.  Cellular push-to-talk, a fielded service, breaks 
> this RFC 3550 already (OMA-PoC as mentioned in the I-D).
> 
> 	This goals of the I-D seem reasonable to me, so I'm in 
> favor of making it a WG item.  Some other comments follow:
> 
> we have reason to believe that users of the other profiles 
> will also want to legitimize non-compound RTCP at some later 
> date, I believe we should expand the scope of this I-D to all 
> profiles, in anticipation.  That sort of anticipation is one 
> way we can keep AVT's workload manageable.
I have no particular comment to this except that it is some sense tied
to the 
immediate and early modes in AVPF as the non-compound RTCP feature is
(by me) primarily expected to be used with adaptation feedback.

> multiplex RTP and RTCP on the same port; Colin has an I-D in 
> progress trying to legitimize that practice.  It doesn't take 
> much imagination to see how non-compound RTCP packets would 
> break fielded code that does the demultiplex by looking for 
> magic numbers in the PT field.
Could be true, one could however argue that the text in section 4 of 
http://tools.ietf.org/id/draft-ietf-avt-rtp-and-rtcp-mux-03.txt
should make this a lesser problem as.
 
> rules OMA-PoC uses for sending RTCP, or (2) get buy-in from 
> the OMA-PoC folks to issue a revision that matches this I-D, 
> it would be best.  Otherwise, we are "closing the barn door 
> after the horse has run away".
The writing in the OMA-PoC spec is quite simple. Below is a snippet from
section 6.5
=======================
The Talk Burst Control Protocol (TBCP) is based on the RTCP Application
Packets (RTCP: APP), as defined in [RFC3550], but TBCP messages do not
conform to the rules for compound RTCP packets or RTCP packet
transmission. Each TBCP message SHALL be one RTCP: APP packet. These
RTCP: APP packets SHALL not be sent in compound RTCP packets, but more
than one TBCP Talk Burst Control message MAY be sent in a single IP
packet. The structure of each TBCP message is defined below.
=======================

> o  The I-D needs an English grammar rewrite -- key problems 
> are singular/plural noun/verb matching, a/an problems, to/too 
> problems ... while normally "just let the RFC editor handle 
> it" is OK, I think there are so many errors that a grammar 
> pass should be done sooner, so that we can concentrate on the content.
Sounds fair. I could possibly issue an updated (grammar corrected) draft
before march 5 but it would of course feel better to do more than a
grammar update. 

Regards
Ingemar

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Tue, 20 Feb 2007 13:33:22 +0100

Hi

Comments inline with text below. 

> From: Joerg Ott [mailto:[email-masked]] 
> Sent: den 20 februari 2007 09:37
> To: Tom-PT Taylor
> Cc: Joerg Ott; John Lazzaro; Colin Perkins; Roni Even; 
> Ingemar Johansson S (LU/EAB); Magnus Westerlund (KI/EAB); IETF AVT WG
> Subject: Re: Review of 
> I have been asked to provide a review of 
> I won't repeat John's points in my review (some of which I share).
> 
> I also understand the motivation for the work (which we have 
> taken into close consideration when doing AVPF in the first 
> place, where we decided to keep the basic packet structure, 
> even though wireless environments were one of our concerns).  
> To this end, the motivation is still fairly abstract (packet 
> loss increasing with size, sure, but you still got link layer 
> units) concerning what it is to be signalled.
> 
> Most importantly, however, I am opposed to making this a WG 
> item, primarily on an architectural basis (other than that, 
> you can engineer anything and make it kind of work).
> 
> Given the considerations in section 4, I do not see how the 
> first sentence of section 5 immediately follows:
> "Based on the above analysis it seems feasible to allow 
> transmission in RTCP under some restrictions."
> 
> Technically:
> 
> We have plenty of RTP deployment out there and RTP has been 
> the constant in the change of signaling protocols, primary 
> usages, and the like.  We have seen uses for stream quality 
> monitoring and the like that are dependent on the general 
> availability of RTCP information.
The intention is not to exclude compound RTCP, rather the intention is
to ensure that eg. adaptation feedback is transmitted with a low
probability  if packet loss even under bad channel conditions and this
is to be achieved by means of non-compound RTCP

> I believe that it is an important and desirable property for 
> RTCP packets to be detectable and interpretable independent 
> of the signaling channel.  This is what section
> 4 of the draft describes.  Signaling which types of RTCP 
> packets will be used, will not reach such devices and will 
> not help old receivers as the authors point out.
The signaling is intended for endpoints, it is true the devices in the
network cannot be assumed to understand such signaling, therefore
section 5 states that implicit verification of the delivery  of
non-compound RTCP should be performed. If this verification fails
compound RTCP should be transmitted instead. Also I must admit that I am
a bit puzzled by the rule that an RTCP packet must look in a specific
way and contain a specified number of mandatory blocks, in my opinion it
should suffice that the payload type is valid, but I guess I need to be
enlightened. Also one must remember that non-compound RTCP is already
employed in OMA-PoC.
 
> Architecturally:
> 
> We are looking at an optimization problem here.  We are 
> trying to optimizing behavior across a single wireless link 
> (or two wireless links connected via some core).  While 
> saving bits on a wireless link is a desirable goal, it is 
> specific to this link layer technology -- and those come and 
> go.  It is not obvious why any other device in the Internet 
> should be bothered by this very problem to motivate a change 
> at the RTCP level.
> 
> Remember: it is already sufficiently hard to get people 
> implement RTCP to begin with.  We should not make it harder 
> by suddenly allowing multiple flavors of it (one specific use 
> of which defeats the general usefulness of RTCP).
> 
> So, if we have two devices communicating in a specific 
> wireless environment, where all kinds of optimizations are 
> already carried out between a base station and the mobile 
> equipment, why not treat this problem at this very place 
> where it belongs?  This feels like another specific 
> optimization useful on one particular link and should not 
> impact the rest of the Internet.
One could always argue in this direction. Problem is however that in
order to achieve a maximum throughput in terms of Mbits/Hz/s some
optimizations are needed and large RTCP packets impose a problem in that
aspect. If the systems are made less optimized this problem is lesser
but this comes at a cost of reduced coverage/capacity and eventually
less revenue for operator or higher cost for the user. I don't believe
that this is a 3GPP problem as the law of physics applies to all
wireless access technologies. Some access technologies might not
experience this problem are they may be hidden by e.g large
packetization overhead.
 
> Summary:
> 
> Assuming some more sound motivation (and pointing out 
> applications usages that are in line with the scope of AVPF), 
> I buy into the basic problem.  Yet, I believe AVT is the 
> wrong place to solve it as this is link-specific and hence 
> should be done elsewhere.
I understand the "above the wire, below the application" argument, still
I believe that we must see the link-layer problems to some extent.

Regards
Ingemar

---

From: Joerg Ott <[email-masked]>
Date: Tue, 20 Feb 2007 10:37:07 +0200

I won't repeat John's points in my review (some of which I
share).

I also understand the motivation for the work (which we
have taken into close consideration when doing AVPF in
the first place, where we decided to keep the basic packet
structure, even though wireless environments were one
of our concerns).  To this end, the motivation is still
fairly abstract (packet loss increasing with size, sure,
but you still got link layer units) concerning what it
is to be signalled.

Most importantly, however, I am opposed to making this a
WG item, primarily on an architectural basis (other than
that, you can engineer anything and make it kind of work).

Technically:

I believe that it is an important and desirable property
for RTCP packets to be detectable and interpretable
independent of the signaling channel.  This is what section
4 of the draft describes.  Signaling which types of RTCP
packets will be used, will not reach such devices and will
not help old receivers as the authors point out.

Architecturally:

We are looking at an optimization problem here.  We are trying
to optimizing behavior across a single wireless link (or two
wireless links connected via some core).  While saving bits
on a wireless link is a desirable goal, it is specific to this
link layer technology -- and those come and go.  It is not
obvious why any other device in the Internet should be bothered
by this very problem to motivate a change at the RTCP level.

Remember: it is already sufficiently hard to get people implement
RTCP to begin with.  We should not make it harder by suddenly
allowing multiple flavors of it (one specific use of which defeats
the general usefulness of RTCP).

So, if we have two devices communicating in a specific wireless
environment, where all kinds of optimizations are already carried
out between a base station and the mobile equipment, why not treat
this problem at this very place where it belongs?  This feels like
another specific optimization useful on one particular link and
should not impact the rest of the Internet.

Summary:

Assuming some more sound motivation (and pointing out applications
usages that are in line with the scope of AVPF), I buy into the
basic problem.  Yet, I believe AVT is the wrong place to solve it
as this is link-specific and hence should be done elsewhere.

Regards,
Joerg

---

From: Randell Jesup <[email-masked]>
Date: Wed, 21 Feb 2007 12:47:39 -0500

>From the point of a non-wireless RTP/RTCP user, I also see noticable
advantage to non-compound RTCP, at least in an AVPF framework.  If you're
only sending RTCP every 5 seconds, layering another sub-packet in isn't a
big deal; if you're sending them for real-time events under AVPF, you may
consume noticable extra bandwidth, enough to impact the available bits for
other data in the channel.  (And remember that even a 5% hit could be a
noticable reduction in quality, and RTCP may be allowed a higher
percentage - and if the SR's bump you up against the 5% limit, under AVPF
rules you may need to delay or throw away attempts to use RTCP for a while.)