[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Comments on draft-ietf-avt-tfrc-profile-01
Ladan, Magnus,
On 23 Jul 2004, at 21:23, Ladan Gharai wrote:
On Jul 20, 2004, at 4:58 AM, Magnus Westerlund wrote:
Here is some comments I have on the draft for the AVPCC profile.
1. I think we should consider to scrap all restrictions on RTCP in
regards to needed bandwidth for feedback, and instead ensure that it
is congestion controlled. If one congestion control RTCP then it is
the situation in both data and feedback channel that determine the
available bandwidth. If I remember TFRC correctly, it stipulates that
the feedback is sent either every RTT or for each received packet,
what ever is the longer time interval. With a congestion controlled
RTCP there would be no problem with the feedback traffic even if much
larger than 5% of the session bandwidth as long as it actually is
available in the feedback channel. Also 5% of the session bandwidth
is rather difficult to define when it is changing due to the
congestion control.
Congestion controlling the feedback path will result in not sending
feedback as prescribed by TFRC (once per RTT or per packet received
for packet-intervals>RTT), which can have adverse effects on the data
path.
Also, TFRC doesn't define how congestion control for the reverse path
would work. If possible I'd prefer to keep this profile as close to the
TFRC spec as possible, and leave complexities like that to DCCP.
Part of the problem with the RTCP feedback bandwidth is the size of
the RCTP compound packets, 56 bytes:
RTCP header (8) + RR (24) + extensions (12) + SDES (12)
My understanding of RFC 3550 is that each RTCP compound packet MUST
have a RR and a SDES packet, would it be possible to scrap this
restriction? (after all the RR and SDES packets are not required at
the rate of once per RTT?) doing so would reduce the size of the RTCP
packets to 20 bytes, a more reasonable size for feedback packets.
How would this affect the RTCP packet validation logic?
2. On what is each TFRC congestion control state calculated over?
With the current text, I get the impression that the TFRC calculation
is done for each SSRC, rather than all traffic from A->B. I think the
later is more appropriate.
Why? I'm not sure I understand your rationale for suggesting this.
However it creates some problem, as one has to take multiple sequence
number spaces into account. Here is also a excellent
in order to share state (TFRC calculations and the RTCP
feedback) the packets sizes of all the flows from A->B must be (at
least, roughly) the same, otherwise separate calculations and feedback
is required.
given the added restriction of packet size and the complication of
different sequence number spaces, its not clear how useful will
sharing state between flows from A->B be?
at any rate, there is nothing in the draft that prevents
implementation of AVPCC such that flows between A->B with the same
packet size share state (an implementation could share state between
such flows or not). Perhaps the draft should be more explicit about
if state sharing is recommended, and with under what conditions?
hook to include RTCP in these calculations. Independently what is the
most appropriate, the feedback needs to be clarified.
3. the RTP header addition. I think the data header addition should
only use 16 bits, not also another 16 padding as shown in the figure.
For the RTP header 32 bit alignment is not a strict requirement.
Unless you have some other information, like being explicit about the
RTT. Although the Quad counter allows a receiver to decide how to
calculate the loss rate, do it suffice to allow the receiver to
determine when to send feedback packets?
yes, using the quad RTT counter allows the receiver to make a
reasonable guess at the RTT.
I will adjust the RTP header as follows:
...
4. You write that if TFRC-PS becomes reality it should be supported.
How do you intend the different versions to be indicated and handled?
I know this is part of the draft that is TBD, but do you have any
ideas?
It seems sensible for both TFRC and TFRC-PS to be supported by
the same profile, however its not clear yet that the feedback
mechanisms in AVPCC will also be sufficient for TFRC-PS?
Okay, although there is the question of how the profile is indicated
since it's not currently possible to pass parameters to a profile when
signalled in SDP.
I also have a couple of other comments:
- Can all payload types be used with RTP/AVPCC? Does it share the static
payload type space with RTP/AVP? Should it?
- Is reusing the standard RTP security service appropriate? Might it be
better to mandate that the SRTP mechanisms are used making this
profile
a derivative of RTP/SAVP (rather than having RTP/AVPCC and
RTP/SAVPCC)?
- What is the rationale for using the quad RTT counter, rather than a
send
timestamp? A sending timestamp would be slightly more bandwidth
overhead,
but would be more accurate and would solve the issues with the jitter
calculation when packet transmission time doesn't match the frame's
capture time.
Cheers,
Colin
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt