[xiph-rtp] Lots of proposals

[David Barrett]

Aaron Colwell wrote:
> Inline delivery is mainly for forward link only and multicast scenarios.
> The periodic transmission of the codebooks is added to the cost of delivering
> the stream and is a necessesary component for cases where you have no way to
> insure reliable transmission.

Yes, this makes sense.


> I go back and forth about whether it is appropriate to create our own
> "codebook ACK" or whether we should use existing IETF standards and drafts that
> have similar purposes. There are several options mainly RTCP XR 
> (RFC 3611), AVPF (AVT Internet Draft), and perhaps the retransmission draft.
> The conflict I have about using the existing stuff is that it seems to apply to
> the whole session. We really only want to reliably transmit part of the
> session. It's not clear to me whether this is justification enough to create
> our own reliability mechanism or not.

I agree, we only care about reliable codebook delivery, and certainly 
not every packet.

Also, I agree we *could* beat an existing round standard into our square 
peg, but it wouldn't be pretty.  A minimal, purpose-built RTCP profile 
that solves just this problem might be appropriate.  We needn't limit it 
to just Xiph codecs, but it will be used by *at least* those.


> I think this conflict is mainly the reason why I've leaned towards HTTP for
> codebook retrieval. It allows you to use a seperate reliable transport for the 
> only data that needs to be transmitted in a reliable fashion.

I agree in theory, but in practice I find it very problematic to use two 
separate communication channels (especially using two entirely different 
protocols, contacting entirely different sources) to accomplish a single 
action.  It confuses the code, compounds the failure rate, decelerates 
performance, burdens my central resources, etc, etc.

Granted, when you only have a hammer, everything looks like a nail.  But 
I would vastly prefer to send a *single packet* along a RTCP stream that 
is *already established* -- even if it means creating a new RTCP profile 
-- to any of the proposed alternatives.


It seems to me that we could do away with HTTP codebook delivery 
altogether, while gaining performance and reducing complexity. 
Furthermore, we could make chaining (true chaining, with an entirely new 
codebooks and not just framerate/quality tweaks) as simple as:

1) If you receive a packet with a 'chainID' you don't recognize, the 
codebook was probably lost, so send a 'retransmit codebook' request with 
the 'chainID' you need.

2) Whenever you receive a codebook, send a 'codebook acknowledged' 
message indicating its associated 'chainID'.

This makes an RTP session entirely standalone -- you needn't be aware of 
its SDP before decoding.  (SDP would still be used for negotiating the 
high-level encoding options, but it's really just advisory; you could 
get away with just broadcasting raw RTP and the client has all the 
information necessary to decode.)

On the server, if it knows it can receive RTCP from the client, it 
doesn't bother sending any audio/video until the codebook its using has 
been acknowledged.  (Likewise, the server knows to generate a video 
keyframe after codebook acknowledgment, further reducing the perceived 
end-to-end delay between clicking "broadcast" and the receiver seeing an 
image.)

And if the server can't receive RTCP from the client, it just uses an 
exponential backoff of codebook delivery inserted into the video stream 
(ie, it doesn't need to wait for advisory feedback it'll never get), or 
uses a separate multicast stream, or any other mechanism that has 
already been proposed.


Basically, I hear all this talk about HTTP being the "safe fallback 
option", but in my experience, and for my application, it simply isn't. 
  I believe inline transmission with ack/retransmit would be superior in 
almost all cases, eliminate the need for HTTP delivery altogether, and 
thereby vastly reduce the client complexity while simultaneously 
improving performance.

-david