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.
|
