On 3/27/07, Colin Perkins <csp@xxxxxxxxxxxxx> wrote:
On 27 Mar 2007, at 17:06, Gorry Fairhurst wrote: > So, > > From all the thread so far > > * I have some ideas of what RTP-like applications want. I'm not > sure there is a need to send/receive a 0-byte Data packet as a way > to make keep-alives happen. The applications I care about need a way to send periodic keep-alive messages to ensure NAT bindings stay open. They can do that by either: 1) sending (non-standard and poorly specified) RTP "no-op" packets, 2) sending zero length packets, or 3) asking the transport to send periodic keep-alive messages. I tend to think of this as a feature of the transport, so I'd prefer option 3, but any of the options can be made to work. > (To me, it seems RTP-NOP packets should not be re-encoded as 0-byte > Data packet). Agreed! > * I suggest the standard send/receive calls are not allowed to send > null packets (although RFC4340 does allow it, is this right?). Irrespective of the merits of application level keep alive messages, that's a change from UDP, which does allow sending and receiving datagrams with zero length payload. > * One option may be to call a socket function to ask DCCP to > generate packets at least every "x" seconds. *IF* that's all that > is needed that seems to me to be OK. If an APP (e.g. RTP) want to > explicitly send something - then it could actually send a packet > across the API. Rather than asking the DCCP stack to send every "x" seconds, we should probably ask it to send keep alive messages, and trust it to do the right thing.
That would be sending DCCP_PKT_SYNC, that could be used for regular PMTU discovery plus keep-alive purpose, no need for a DCCP_PKT_ALIVE new packet type, ok? - Arnaldo
