On 27 Mar 2007, at 13:30, Phelan, Tom wrote:
OK, so at least two of us agree that DCCP SHOULD NOT generate DCCP-
Data
packets on its own (zero length or otherwise) :-).
Therefore it seems to me that applications MAY use zero-length packets
as they see fit. The question left is "is RTP an application?" To
me,
RTP has many more of the characteristics of a transport protocol
than an
application, but it is consistently used over some transport protocol,
so what is it?
So, the model I think that Colin has in mind for RTP over DCCP
(chime in
if I get it wrong, Colin) is that a real-time application gives
data to
RTP, RTP wraps that data in RTP packets and gives that to DCCP, who
wraps the RTP packets in DCCP packets. So from DCCP's point of view,
RTP is the application, and the (real) application has no way of
directly sending DCCP packets. That says that RTP MAY send zero-
length
packets.
I don't think the details are relevant to DCCP.
One question that I still have is who is responsible for recognizing
idle and sending something? Is it the RTP stack? Or should the app
send a NOP packet that the RTP stack translates to a zero-length
packet?
Trying to recognise and translate application-specific keep alive
messages into zero-length DCCP datagrams would be a mistake. Either
let the DCCP layer handle keep alive messages in a manner transparent
to the higher layers, or pass that responsibility to the higher layer
protocols which use DCCP, but don't try to second-guess.
--
Colin Perkins
http://csperkins.org/
