Hello Eddie,
There was rather a flutrry of email, so pleased you are keeping up. See
in-line.
On Tue, 27 Mar 2007, Eddie Kohler wrote:
Hi guys,
This thread is amazingly huge (bikeshedding?) so I may respond a couple
times.
I think we made a mistake in DCCP when we said that the API SHOULD report
zero-length packets to the receiving application. (I think Greg Minshall
warned us this was a bad choice, too!)
I've questioned this also in a later mail...
The Faster Restart draft therefore modifies this behavior.
Sure, that was Arjuna's comment...
The most current version of the text is as follows:
"A DCCP-Data or DCCP-DataAck packet may have a zero-length application data
area. Such packets may be sent by congestion control algorithms to
maintain a minimum sending rate. As in DCCP-Request and DCCP-Response
packets, an empty application data area indicates the absence of
application data. The usual packet receiving API MUST NOT report any
received zero-length datagrams to the receiving application. For instance,
when a receiving application asks the API to return the next received
packet, the API should always return a packet with at least one byte of
application data. (However, a special-purpose API, such as an API designed
to report connection liveness, MAY report received zero-length datagrams.)">
I think this is the right idea. It effectively reserves zero-length
datagrams for the network and transport layers.
If agreed, that would need WG consensus, and a fix to the base-spec. At
the moment, I think we still need to understand the options.
Applications that want
keepalives should define some corresponding data format: a one-byte datagram
would suffice.
Not sure I agree, I'd rather the apps called-down to the transport using a
control function and asked them to do this.
Eddie
Phelan, Tom wrote:
Hi Gorry,
I think this is a nice taxonomy of keep-alive use cases. The question,
I think, is what are the problems that arise when zero-length packets
are used for (all) keep-alives? One of the problems appears to be
disambiguation.
For use 1 (NAT refresh), no one at the receiver cares about receiving
the packets. For use 2 (connection state) DCCP will take action with
the received packets. And for use 3 (application state) the application
needs to receive the packets. When a zero-length packet is received,
how do you tell what its purpose is?
Do we need to reserve zero-length packets for use by only one of these
functions?
Tom P.
-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] Sent: Monday, March
26, 2007 7:09 AM
To: gorry@xxxxxxxxxxxxxx; dccp@xxxxxxxx
Subject: Why do we have or should have keep-alive packets?
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)
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.
c) To verify transport state (application died? no loss?)
- to retransmit or reset peer lost protocol state.
3. Uses of Keep-Alive at the Application Layer:
a) To verify receiver state (socket open, application died?)
- to terminate/reset connection.
b) To verify network path (path changed?)
- to modify flow-control/session parameters.
Do these lists have missing things, how clear is the suggested
separation in
functions between the two layers?
How often should we probe in this way?
Thoughts and comments are welcome!
Gorry
