Regarding using zero bytes data packets, the FR draft (http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-02. txt) mentions: "To that end, this document modifies RFC 4340's behavior with respect to zero-length application data area DCCP-Data and DCCP-DataAck packets. RFC 4340, Section 5.4, specifies that: A DCCP-Data or DCCP-DataAck packet may have a zero-length application data area, which indicates that the application sent a zero-length datagram. This differs from DCCP-Request and DCCP- Response packets, where an empty application data area indicates the absence of application data (not the presence of zero-length application data). The API SHOULD report any received zero-length datagrams to the receiving application. This document revises this statement 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 API MUST NOT report any received zero-length datagrams to the receiving application. The API SHOULD report an error when a sending application attempts to send a zero-length datagram." The obvious question that arises is why does the application send a zero-length datagram? And why should the DCCP sender send any DCCP-data packet when the application has nothing to send! So my belief is that DCCP-data packets have zero length application area has no meaning. If we believe that we should not use zero byte DCCP-data packets, then we could either: 1)Have a new option in DCCP-data packets (but we would have nothing in the application area, so we come back to square 1). Or 2)Have two new DCCP packets called DCCP-Alive and DCCP-AliveResp and the spec (RFC4340) allows you to have new DCCP packet formats - which looks more reasonable to me. Arjuna -----Original Message----- From: Phelan, Tom [mailto:tphelan@xxxxxxxxxxxx] Sent: 27 March 2007 11:48 To: Lars Eggert; ext Gorry Fairhurst Cc: dccp@xxxxxxxx Subject: RE: Why do we have or should have keep-alive packets? Hi All, I don't think we're really talking about whether there should be keep-alives or not, we're talking about using zero-length packets as keep-alives (or any other purpose, for that matter), and the complications that result if multiple levels use zero-length packets, each for their own purposes. We're in this discussion because Colin has recommended sending zero-length packets as RTP keep-alives and Arjuna is simultaneously considering zero-length packets for a CCID-specific use. If Colin was less familiar with DCCP and decided to use RTP NOP packets, as is normal RTP practice, there would be no conflict and we might not have recognized this issue. 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. 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
