Subject: RE: on packet number echo

From: Marcus Ihlar <[email-masked]>
Date: Sun, 26 Mar 2017 19:37:18 +0000

Hi,

The issue I have with option 1 is that that many endpoints mainly receive data and only rarely transmit ack:able frames. Such endpoints will likely  have outdated RTT-estimates. This could lead to echoes being transmitted more than once per RTT (not a problem), but the opposite could be true as well given the levels of jitter we observe in e.g cellular networks.

//Marcus

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: den 15 mars 2017 00:57
To: Brian Trammell (IETF) <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: on packet number echo

Thanks for summarizing this Brian.

The first option means that an implementation could not send the echo, for example if a network was using it in a way that was harmful to users.  This provides an incentive for networks that do use it to either do nothing active with it or use it to improve user experience. (see Marcus Ihlar's thread for that)

I think the largest upside(or downside, depending upon your perspective) of the second option where the largest acked is included with every frame is that it means one MUST implement this correctly to implement QUIC, at least if they want to use the standard ack frame.

Personally, my largest concern with the second case is that of differential treatment of acks.  What if an ack packet contains other data, and a middlebox decides that only the most recent ack needs to be delivered(a common TCP approach), so the data bundled with the ack is inadvertently lost?

At this point, I lean towards the first option, because I understand the implications better, but I could be convinced otherwise.

Either way, I think both of these are potentially worthy of including and I think they're preferable to doing nothing.

On Tue, Mar 14, 2017 at 10:46 AM, Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>> wrote:

   Greetings, all,

   for those not watching github, there's a discussion on packet number echo; my summary post in PR#391 is reproduced below:

   to summarize... there seem to be three possibilities emerging here:

   ### Echo (at least) once per RTT. Leave ACK frames unchanged.

   (This is what's written up in this PR).

   Rationale: What happens in the frame layer stays in the frame layer. Packet number echo is a pure packet-layer change to the transport protocol. Since this is additional overhead, we should work to minimize it, hence once per RTT, the minimum frequency that works for passive latency measurement.

   Upsides: It's a tiny change to the protocol as presently described, for a low overhead cost per RTT (1-4 bytes, usually 2). The ACK frame remains self-describing, so the ack frame handling component in an implementation can remain separate from the packet handling component. Endpoints can choose to echo more frequently (e.g., when configured to do so for debugging purposes).

   Downsides: an echoing endpoint with a passively-cooperative peer can intentionally skew passive measurements, since the value in the packet header is not necessarily joined to the value in the ack frame. The utility and practicality of such a thing is debatable. It's not clear how good the resulting number/echo stream will be for one-point loss and reordering estimation.

   ### Echo max-acked on every packet with an ACK frame, and remove it from the ack frame.

   Rationale: This information already appears in the ACK layer, so there's no additional overhead.

   Upsides: Echo frequency is higher; this should make loss and reordering estimation work better at a single observation point.  No additional overhead.

   Downsides: Increased complexity of implementations, which have to pass packet number echo information up the stack. No endpoint control over how often packet numbers are echoed, since max-ack is required by the transport mechanisms.

   Mixedsides (depending on your proclivities): The presence of an ACK frame is now exposed to the path. ACK-frame-containing packets can (and given the history of TCP, probably will) be treated differently by the network in certain circumstances.

   ### Don't echo packet numbers at all

   (this is the no-build option)

   Cheers,

   Brian

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 27 Mar 2017 12:36:41 +0200

hi Marcus,

> On 26 Mar 2017, at 21:37, Marcus Ihlar <[email-masked]> wrote:
> 
> Hi,

Quoting Ian's note from Github on https://github.com/quicwg/base-drafts/pull/391 for the list:

> @britram I think it's ok to provide an RTT measurement less frequently when little data is flowing. The removal of STOP_WAITING and acking acks results in sending a retransmittable frame with an ack approximately once per RTT. So both directions should get an RTT estimate approximately once per RTT.

Though I get your point about an RTT-driven echo (regardless of the mechanism) being sensitive to large swings in RTT on short timescales. Presumably, implementations in these situations could use more aggressive RTT estimator smoothing regardless of echo, though...

Cheers,

Brian

> On Tue, Mar 14, 2017 at 10:46 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> Greetings, all,
>