Colin Perkins wrote:
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.
Yes.
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?
I was envisaging this as protocol "clean-up". In many cases Receivers
only send their state when asked to. Normally the Sender expects state
to be returned when it sent something, but there are cases where the
receiver can have new state (e.g. a change in receiver window), that
could get lost, and this to resolve this kind of deadlock. You call this
"polling" - but either way, if the sender something it would be resolved
in the control message that was returned.
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.
>
Except to note that in some CCIDs a single such packet may "destroy"
your CC state, by the DCCP connection now assuming the App wishes to
send only one packet every (say) 15 seconds, rather than its previous
rate of X pps. I don't think we need signalling to tell DCCP this, I
just would like to aware of this when designing future CCIDs.
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.
OK, I could see this as more closely related to 3a, in which case I
would suggest changing this to "verify end-point connectivity".
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.
>
We do indeed.
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.
Does this assume firewalls/NATs and other middleboces view DCCP as more
like UDP, than TCP? I seem to recall our policies for TCP had longer
time-outs. I just want to be sure we are giving the correct advice to
the "future" implementors of these devices.
The rate of sending transport level keep alive packets would depend on
the CCID, I presume,
Could do.
Could also be a socket-opt (???) if the apps need to say?
and we can give some guidance which balances the
amount of keep alive traffic, the ability to restart an idle
connection, and power consumption.
Which seems to suggest it depends on policy, etc?
Gorry
