Re: ACK Frame Issues

[Jana Iyengar <[e-mail]>]

Related to point (2), I've filed #774
<https://github.com/quicwg/base-drafts/issues/774>.

On Wed, Sep 6, 2017 at 2:47 PM, Christian Huitema <[e-mail]>
wrote:

>
>
> On 9/6/2017 2:25 PM, Martin Duke wrote:
>
> ...
>
> (1) *The spec sorely needs more normative text.*
>
> ...
>
> (b) There are four ways to treat acks in flight on which the spec is
> silent:
>     (i) Do not repeat them in subsequent acks
>     (ii) Repeat them only if they do not require additional ack blocks
>     (iii) Repeat them only if they require *neither *additional ack
> blocks nor longer block lengths.
>     (iv) Always repeat them until acked
> Offline, Jana suggested that (iv) is what Google does, but you'd never
> guess that. I settled on (ii), for what it's worth.
>
>
> Picoquic also does (vi). It provides redundancy, so if an ACK is lost the
> next ACK will still acknowledge the received packets.
>
> ...
>
> (e) The spec is unclear if timestamps are sorted in order of arrival or
> reverse order of arrival. At least it's unclear to me! BTW having to sort
> new arrivals in both packet number and arrival order is unpleasant.
>
>
> Picoquic does not attempt to sort arrivals, but maintain a SACK structure
> similar to the "SACK dashboard" specified in TCP.
>
>
> I don't think the spec should prohibit any of this behavior. However, some
> normative text might indicate to implementors that they don't really need
> to worry about some of this stuff.
>
> (2) *The relationship between timestamps and ack blocks needs a rethink*
>
> People are all over the map on this. On the implementer slack channel, a
> lot of people are totally ignoring timestamps and don't think they're
> useful. Jana seems to view as a purely advisory channel. On the other hand,
> as issue #698 points out, a received timestamp means the packet has
> arrived, and sending an ack block for it in the same frame seems redundant.
>
>
> Yes. That syntax is wrong, because it creates a potential conflict.
>
>
> Finally, timestamps are a report with a completely different syntax.
> *Especially* if they are advisory, I believe there is a strong case for
> just putting it in its own frame and eliminating some of the weird
> dependencies (see (c) above) between largest_acked and the timestamp fields.
>
>
> No. There would still be a conflict. For example, in Picoquic, receiving
> at ACK erases the data related to the acknowledged packet -- including the
> timestamps. If the proposed "timestamp frame" arrived after the ACK frame,
> its information would be ignored because the packet was already marked
> received and the data erased.
>
>
> Personally, I would recommend the following:
> (1) Move timestamps into a separate frame.
> (2) A host that receives a timestamp frame MUST interpret a timestamp for
> a packet as an acknowledgement for that packet. Packet recievers MAY omit
> ack blocks for packets for which a timestamp is in flight.
> (3) (possibly) make timestamps something negotiable (in each direction) at
> the start of a connection. For example, a host may only want timestamps
> from its peer if it is using delay-based congestion control.
>
>
> My preference would be to have exactly one time stamp per ACK,
> corresponding to the time at which the "largest acknowledged" packet was
> received, and expressed as microseconds since the beginning of the
> connection. 24 bits is probably OK, as long as the RTT is lower than 16
> sec. 32 bit would be fine for anything but inter-planetary communications.
>
> -- Christian Huitema
>
> --
> Christian Huitema
>
>