it unclear on the logarithmic
counts. Take, for instance SaDtTtT. If I'm reading this correctly, I think
that means 10-99 retransmissions from orig, followed by 10-99 from resp,
then more retransmissions from orig (enough to reach a total of 100-999),
and similarly more from resp.
Correct in principle. (1) These would be 1-9 followed by enough to
get to 10-99, since a single retransmission is already a 't' / 'T', and
(2) lower letters are responders rther than originators.
However, I could also interpret it as 10-99
from orig, 10-99 from resp, 10-99 from orig, 10-99 from resp.
Nope. The counter doesn't reset at any point, it's cumulative.
Another question I had was that most of these are TCP-specific. Would
checksum apply to UDP as well?
Right, it would apply to UDP too, just like is done presently for
the boolean indicator.
As you say, if what I care about is the overall
number compared to the number of packets, that feels more like a
Well, I think this is yes-and-no. For one, the overall percentage might
be quite small and still have a large impact on what's supposed to be a
high-speed transfer - particularly if it means that a connection entered
an extented timeout-and-back-off - so I don't know if there would be a
natural point of inspection for it. (It could also quite large but no big
deal because the connection is a runt.)
To me, it'd seem more natural to use something like "0t" means
"of the total number of packets from the originator, 0-9% were
retransmissions," "1t" means 10-19%, etc.
I'm inclined to wait on refinements like this. Let's first see whether
having log-counter-style histories leaves people wanting more before
qualitatively changing the nature of the history field, or adding new
Maybe we add the
new letters, but don't repeat them and also add new fields for exact
I'm not following this. If we add new letters that don't repeat *and* we
add new fields, why do we need the letters given that the fields are there?