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.
* The last part is what should appear on the wire: IMHO, I think
someone now needs to look at the Specs and how a receiver handles
this in DCCP - to figure out what a receiver does when it gets a 0-
byte DCCP Data packet, and therfore what the side-effects are. If
these are in any way "odd" then we should be using a different
packet format for this purpose (rather than over-loading an
existing packet type).
Explicit is better than implicit, so I'd suggest using a different
DCCP packet type if we want to go this way.
Colin
