Re: [quicwg/base-drafts] Clarify bytes_in_flight (#551)

[ianswett <[e-mail]>]

ianswett commented on this pull request.



> @@ -615,6 +615,8 @@ are described in this section.
 bytes_in_flight:
 : The sum of the size in bytes of all sent packets that contain at least
   one retransmittable frame, and have not been acked or declared lost.
+  The size does not include IP or UDP overhead.  Ack only frames do not
+  count towards byte_in_flight.

We don't need to copy what TCP does, but I thought it makes sense to document a reasonable option, and make that similar to TCP.  

I'll also note there's not much evidence we have to agree on the same bytes_in_flight accounting across implementations.  The most important thing is internal consistency.

The reason acks shouldn't count towards bytes in flight is one never wants to delay an ack due to lack of congestion window.  We could say they count, but you send them immediately anyway, but I think it's equally ugly.

Good point on PADDING, because they are not retransmittable, but we do count them towards bytes in flight in the GQUIC implementation, and I tend to think they should be counted.

So I'd say we have three options I can think of: 
1) Land an updated version of this in order to document a TCP like approach and discuss this further at the interim.
2) Do nothing, and hope we get to this at the interim.
3) Do nothing, because we're happy letting implementations do what they want, just like TCP implementations do.

-- 
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/551#discussion_r117878386