Re: [quicwg/base-drafts] Packet number echo with variable-length numbering (#391)

[ianswett <[e-mail]>]

>From the list: "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."

In regards to reordering, the largest ack never decreases, even if packets are received out of order, so this should make decoding the value quite easy for middleboxes.  Any packets with an echo present should be ignored if their packet number is less than the last echo you saw(because that means reordering in the ack stream) and otherwise the largest acked is monotonically increasing.  

Before we do add this, I'd really like to hear from some network operators about how critical this is.  Ericsson clearly has a use case, but I wouldn't want to add this for a single company.  

My take is: If we give network operators the right information, they'll be able to operate their networks better, and that will benefit QUIC in the long run.  If we don't think this information is critical to operations, it just adds one more thing to ossify.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/391#issuecomment-287080263