Re: [dcp] Comments and Question Re: DCP drafts

[Eddie Kohler <kohler@icir.org>]

Hi Patrick, thanks very much for your comments!

> observation - acks of acks are a pretty non-intuitive concept if
> you're starting with TCP as your knowledge base ...

Totally fair observation. I've rewritten the most relevant section of the
DCCP draft; it's included below. Let us know if that helps.

> observation 3 - This is really an API comment, and I know dealing with
> API issues is tricky and/or inappropriate - ...

Another fair observation, and not inappropriate at all. We are concerned
about balancing the needs for kernel buffering, to achieve reasonable
utilization, and responsive feedback, so old useless data doesn't get sent.
We're considering a mechanism like the sockopt() you suggest, as well as
other mechanisms, including maybe a callback design.

> question - for experimentation purposes is this envisioned as being
> built on top of udp, IP, or ???? - has a convention been established
> for port numbers or protocol numbers?

We're envisioning it as on top of IP, parallel with UDP, although of course
layering over UDP is possible for experiments. As far as numbers go, Jon
Crowcroft kindly 'lent' the IP protocol number 33 to us for
experimentation.

Eddie


7.1.  Acks of Acks and Unidirectional Connections

    DCCP was designed to work well for both bidirectional and
    unidirectional flows of data, and for connections that transition
    between these states.  However, acknowledgements required for a
    unidirectional connection are very different from those required for
    a bidirectional connection. In particular, unidirectional
    connections need to worry about acks of acks.

    The ack-of-acks problem arises because some acknowledgement
    mechanisms are reliable. For example, an HC-Receiver using CCID 2,
    TCP-like Congestion Control, sends Ack Vectors containing completely
    reliable acknowledgement information. The HC-Sender should
    occasionally inform the HC-Receiver that it has received an ack. If
    it did not, the HC-Receiver might resend complete Ack Vector
    information, going back to the start of the connection, with every
    DCCP-Ack packet! However, note that acks-of-acks need not be
    reliable themselves: when an ack-of-acks is lost, the HC-Receiver
    will simply maintain old acknowledgement-related state for a little
    longer. Therefore, there is no need for acks of acks of acks.

    When communication is bidirectional, any required acks of acks are
    automatically contained in normal acknowledgements for data packets.
    On a unidirectional connection, however, the receiver DCCP sends no
    data, so the sender would not normally send acknowledgements.
    Therefore, the CCID in force on that half-connection must explicitly
    say whether, when, and how the HC-Sender should generate acks of
    acks.

    For example, consider a bidirectional connection where both half-
    connections use the same CCID (either 2 or 3), and where DCCP B goes
    *quiescent*. This means that the connection becomes unidirectional:
    DCCP B stops sending data, and sends only sends DCCP-Ack packets to
    DCCP A. For CCID 2, TCP-like Congestion Control, DCCP B uses Ack
    Vector to reliably communicate which packets it has received. As
    described above, DCCP A must occasionally acknowledge a pure
    acknowledgement from DCCP B, so that DCCP B can free old Ack Vector
    state. For instance, DCCP A might send a DCCP-DataAck packet every
    now and then, instead of DCCP-Data. In contrast, for CCID 3, TFRC
    Congestion Control, DCCP B's acknowledgements need not be reliable,
    since they contain cumulative loss rates; TFRC works even if every
    DCCP-Ack is lost. Therefore, DCCP A need never acknowledge an
    acknowledgement.

    When communication is unidirectional, a single CCID---in the
    example, the A-to-B CCID---controls both DCCPs' acknowledgements, in
    terms of their content, their frequency, and so forth. For
    bidirectional connections, the A-to-B CCID governs DCCP B's
    acknowledgements (including its acks of DCCP A's acks), while the B-
    to-A CCID governs DCCP A's acknowledgements.

    DCCP A switches its ack pattern from bidirectional to unidirectional
    when it notices that DCCP B has gone quiescent. It switches from
    unidirectional to bidirectional when it must acknowledge even a
    single DCCP-Data or DCCP-DataAck packet from DCCP B. (This includes
    the case where a single DCCP-Data or DCCP-DataAck packet was lost in
    transit, which is detectable using the # NDP field in the DCCP
    packet header.)

    Each CCID defines how to detect quiescence on that CCID, and how
    that CCID handles acks-of-acks on unidirectional connections. The B-
    to-A CCID defines when DCCP B has gone quiescent. Usually, this
    happens when a period (for CCID 2, roughly two round-trip times) has
    passed without B sending any data packets.  The A-to-B CCID defines
    how DCCP A handles acks-of-acks once DCCP B has gone quiescent.

_______________________________________________
dcp mailing list
dcp@ietf.org
https://www1.ietf.org/mailman/listinfo/dcp