Gorry,
Some comments/thoughts inline.
On 26 Mar 2007, at 12:09, Gorry Fairhurst wrote:
This email is to start a discussion on the use and requirements for
protocol
keep-alive packets in DCCP. This is a follow-up to discussing the
RTP/DCCP
draft.
A keep-alive packet is defined here as a packet that is sent when the
protocol has no data to send. Such packets provide no specific
protocol
function, except to indicate that the protocol end points still have
protocol state.
The notes below capture some of the ideas inspired by the DCCP WG
meeting in
Prague. Please add more ideas and thoughts...
1. Uses of Keep-Alive at the Network Layer:
a) To refresh network-layer soft state (e.g. NAT, Firewall
pinholes)
This is important, but covers both network and transport layers,
since NATs and firewalls tend to keep separate state tables for
different transport protocols.
2. Uses of Keep-Alive at the Transport Layer:
a) To verify network path (rtt change, loss indication)
- to modify congestion parameters.
b) To verify remote reachability (end host transport still there?)
- to terminate/reset connection.
I think these are all reasonable things for a DCCP-level keep alive
to manage, independent of the application.
c) To verify transport state (application died? no loss?)
- to retransmit or reset peer lost protocol state.
I'm not sure why this counts as a keep-alive, rather than an
acknowledgement and retransmission?
3. Uses of Keep-Alive at the Application Layer:
a) To verify receiver state (socket open, application died?)
- to terminate/reset connection.
These have to go end-to-end at the application level to be useful, so
I'm not sure we need say anything about them at the DCCP layer.
Indeed, I'm tempted to forbid applications from sending zero-length
datagrams, reserving them for a transport-level keep-alive (an
application level keep-alive needs to know the far-end application is
alive, not just the transport, so it needs application data in the
messages, rather than an empty packet).
b) To verify network path (path changed?)
- to modify flow-control/session parameters.
Reasonable, although I think this was a transport layer feature, with
an up-call to the application on change, rather than something for
applications to manage.
Do these lists have missing things, how clear is the suggested
separation in
functions between the two layers?
We need to be clear what features the transport provides to the
application, so application authors know when they can get away with
omitting application-level checks for things that are probed at the
transport layer in DCCP.
How often should we probe in this way?
For NAT traversal, RFC 4787 mandates that UDP bindings be kept open
for at least two minutes (except for well-known ports, which may have
a shorter idle lifetime [RFC 4787 section 4.3]), but notes that there
is significant variation in device behaviour. ICE [draft-ietf-mmusic-
ice-14.txt section 10] suggests a keep-alive interval of 15 seconds
by default, and that is the value I recommend in the RTP over DCCP
draft, since ICE looks likely to be widely deployed. You'd want a way
of varying the interval for environments where power consumption/
bandwidth is limited, and you know there's no need for a keep-alive,
of course.
The rate of sending transport level keep alive packets would depend
on the CCID, I presume, and we can give some guidance which balances
the amount of keep alive traffic, the ability to restart an idle
connection, and power consumption.
--
Colin Perkins
http://csperkins.org/
