Hi Arjuna, OK, so at least two of us agree that DCCP SHOULD NOT generate DCCP-Data packets on its own (zero length or otherwise) :-).
Therefore it seems to me that applications MAY use zero-length packets as they see fit. The question left is "is RTP an application?" To me, RTP has many more of the characteristics of a transport protocol than an application, but it is consistently used over some transport protocol, so what is it? So, the model I think that Colin has in mind for RTP over DCCP (chime in if I get it wrong, Colin) is that a real-time application gives data to RTP, RTP wraps that data in RTP packets and gives that to DCCP, who wraps the RTP packets in DCCP packets. So from DCCP's point of view, RTP is the application, and the (real) application has no way of directly sending DCCP packets. That says that RTP MAY send zero-length packets. One question that I still have is who is responsible for recognizing idle and sending something? Is it the RTP stack? Or should the app send a NOP packet that the RTP stack translates to a zero-length packet? Tom P. -----Original Message----- From: Arjuna Sathiaseelan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 7:23 AM To: Phelan, Tom; 'Lars Eggert'; 'ext Gorry Fairhurst' Cc: [email protected] Subject: RE: [dccp] Why do we have or should have keep-alive packets? Dear Tom, I agree with you on this issue, and I guess we SHOULD have a new packet type called DCCP-Alive packet, that could be used for DCCP level keep-alives, rather than using zero bytes DCCP-Data packets. Regards Arjuna -----Original Message----- From: Phelan, Tom [mailto:[EMAIL PROTECTED] Sent: 27 March 2007 11:48 To: Lars Eggert; ext Gorry Fairhurst Cc: [email protected] Subject: RE: [dccp] 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:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 5:38 AM To: ext Gorry Fairhurst Cc: [email protected] Subject: Re: [dccp] 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
