[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Re: Comments on draft-ietf-avt-tfrc-profile-05
Ladan Gharai wrote:
On Nov 7, 2005, at 12:36 AM, Magnus Westerlund wrote:
3. Section 4. RTP data header extension: Is the first 16 bits field
values shared with the AVP profile or is this a new scope?
The text on RTP header extensions is verbatim from RFC 3551 - and
no this draft does not define new header extensions.
See Colin's comment which is the issue.
4. Section 4. RTCP report interval: "This profile is restricted to
unicast flows, therefore at all times there is only one active
sender and one receiver." This formulation is a bit unclear. As
there may only be unicast traffic but that doesn't present there from
being multiple sources (SSRC).
Other than having a mixer involved, what scenarios exist where
unicast does not equate to a single SSRC?
Streaming using the AVT defined retransmission format using SSRC
multiplexing. There the server will have one SSRC for primary
transmission and a second one for all retransmissions.
5. Section 4. Encapsulation: Should this profile be defined for use
over UDP-Lite?
It is possible to do so, contingent on the draft also defining how
TFRC deals with corrupt packets received: 1) as a lost packet - or- 2)
as a received packet. Personally, I'd opt for 2.
This has been discussed quite heavily in both DCCP and TSVWG if I
remember correctly. I don't think the general community has full
agreement on the bottom line: Is corruption an indication of congestion.
For a number of links that is not true, and thus I support option 2.
8. This draft is still not declaring the possibility to use AVPF RTCP
feedback messages.
As it is possible to have multiple senders and receivers with
AVPCC, there is a basic conflict between AVPF and AVPCC - as AVPF will
suppress feedback packets to prevent implosion, and AVPCC relies on
receiving feedback packets for correct congestion control. Clearly
this depends on the scenarios where it is possible to have numerous
senders and receivers with AVPCC?
For example request for FIR av we are working on
draft-wenger-avt-avpf-ccm-01.txt is one that really makes sense over
unicast link. Also the already defined ones, like the Generic NACK which
can be used in unicast streaming cases to indicate that the receiver
hasn't got some packets to enable them to be retransmitted.
9. Something that maybe should be clarified is if any congestion
control actually occur of the return path. What will feedback message
packet losses mean for the forward link and will that induce any
reduction in the feedback traffic. In TCP losses of ACK will
implicitly mean a reduction of the forward traffic which in its turn
reduces the ACK path. However it is not obvious that TFRC will result
in this. Which makes me question if some criteria for the handling of
the feedback path is needed.
If feedback packets are lost (no feedback received for 4 rtts) the
TFRC sender will half its send rate, per RFC 3448.
But does that effect the receivers feedback to the TFRC sender? To my
knowledge TFRC will continue to transmit one feedback message every RTT.
Thus no reduction in load. Unless TFRC is operating in one feedback
packet per received packet.
The problem I see is that TFRC feedback traffic in itself is causing
congestion on the path from the TFRC receiver to the TFRC sender. Will
this congestion result in a lowered load on the feedback path. So far
the only answer that I see is that when the session loses sufficient
amount of feedback to half its forward rate multiple times then the
application may shutdown the TFRC connection. So congestion must be
quite severe on the feedback path for that to occur.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt