Finally reached the end of the thread.
==> FR uses DCCP-Data because FR measures congestion on keepalives.
Congestion on things like Syncs are not measured in the same way, since Syncs
are "non-data packets". While DCCP does attempt to measure congestion on
Syncs it charges the congestion to the ack stream (more or less).
==> Sync is not appropriate for keepalives because Syncs require immediate
acknowledgement. Many keepalives don't.
==> I sympathize with, but do not approve of, new packet types for keepalives.
It is extravagant to use two packet types on keepalives (and why do we need
a special keepalive ack anyway?), especially when many types of keepalives are
better served in other ways (i.e., Sync, application-level).
Here are the options I'd support. In all these options zero-length
Data/DataAck packets are used for transport keepalives. In some of the
options, the application can also use them for application keepalives. In
option (3'), the receiver can differentiate transport and application
keepalives, although I'd argue strongly that the better way to do this is to
have an application-level keepalive message with nonempty data.
(1) The original FR rule (the receiver never gets notified of zero-length
datagrams, the sender cannot send them).
(2) A modified FR rule for receiving (the receiver does not get notified of
zero-length datagrams via the normal API, but it might using a special API).
The sender application can send zero-length datagrams, but the receiver
application won't normally get them.
(3) Another modified rule, as follows: The receiver doesn't get notified of
zero-length datagrams unless it asks specifically to receive them. The sender
application can send zero-length datagrams.
(3') A version of (3), plus an option that CCIDs set on zero-length datagrams
that WERE NOT generated by an application, allowing a receiver to tell whether
transport or application generated a zero-length datagram.
I don't understand Arjuna's problem with zero-length application data areas
("my belief is that DCCP-data packets have zero length application area has no
meaning"). As Colin points out you can send zero-length UDP datagrams today.
Eddie
Phelan, Tom wrote:
Hi Arjuna,
[snipped]
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.
[Tom P.] Well, we have an existence proof in the DCCP over RTP spec --
applications with nothing to send want to keep NAT/Firewall pinholes
open. There is no information in the packet that the receiver needs to
act upon, but middleboxes need to see the traffic. We can argue about
which level is the proper place to provide this function...
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.
[Tom P.] Option 2 sounds more architecturally consistent to me too.
Tom P.
