So I think we need to talk about how to/who should use zero-length
packets. It seems to me that the proposed CCID use is wrong. DCCP-Data
packets are for carrying user information -- even if that info is nil.
To use DCCP-Data packets for a DCCP-level purpose seems to pervert that.
CCIDs that need to send something should use one of the packets related
to CCID actions, such as DCCP-Ack, or if that isn't appropriate I
believe the spec allows CCIDs to invent new packet types.
I disagree with this, for a technical reason. Faster Restart needs to send
keepalives to get some idea of whether the congestion rate has radically
changed. (If it has changed then FR will turn off.) For that reason, the
keepalives MUST be Data packets (or DataAcks), for losses and marks on
non-data packets are not necessarily reported back to the receiver!!
If a loss of packet X should affect the measured loss rate, then packet X
should be a data packet. That's the way DCCP is.
Sync is not a data packet.
One alternate way to divide up the "keepalives" requirements is: Should loss
of a keepalive represent congestion? If so, then the keepalive should use a
data packet type.
Eddie
Not that the issue of the "goodness" of keep-alives is uninteresting, it
just isn't the real issue at hand :-).
Tom P.
-----Original Message-----
From: Lars Eggert [mailto:lars.eggert@xxxxxxxxx]
Sent: Tuesday, March 27, 2007 5:38 AM
To: ext Gorry Fairhurst
Cc: dccp@xxxxxxxx
Subject: Re: Why do we have or should have keep-alive packets?
On 2007-3-26, at 14:09, ext Gorry Fairhurst wrote:
Thoughts and comments are welcome!
I'd be good to keep the discussion in RFC1122, Section 4.2.3.6 on TCP
keep-alives in mind:
A "keep-alive" mechanism periodically probes the other
end of a connection when the connection is otherwise
idle, even when there is no data to be sent. The TCP
specification does not include a keep-alive mechanism
because it could: (1) cause perfectly good connections
to break during transient Internet failures; (2)
consume unnecessary bandwidth ("if no one is using the
connection, who cares if it is still good?"); and (3)
cost money for an Internet path that charges for
packets.
These days, I'd add: (4) keep-alives can drain battery power, because
they may prevent certain radio links from efficiently utilizing their
low-power modes.
A TCP keep-alive mechanism should only be invoked in
server applications that might otherwise hang
indefinitely and consume resources unnecessarily if a
client crashes or aborts a connection during a network
failure.
Note that I'm not vehemently opposed to the idea of adding keep-
alives to DCCP, but the pros and cons must be weighted carefully.
Lars
