Re: What CSRs Do

[Willy Tarreau <[e-mail]>]

On Tue, Nov 19, 2019 at 06:57:07AM +0100, Frode Kileng wrote:
> On 19/11/2019 05:29, Willy Tarreau wrote:
> > 
> > The only known alternative is to claim "we have no loss here" and point the
> > finger at the next step in the chain operated by someone else.
> 
> What additional value can "loss bit(s)" provide beyond confirming that the
> source is within your network domain or somewhere else, i.e. information
> that is available from other "loss sources". How would network operators use
> this loss bit(s) signal when providing such "excellent customer support"
> when the problem source is external?

I find your condescending tone inappropriate to discuss technical matters.

But since you asked, when I'm invited to troubleshooting sessions when
people experience issues ranging from "seems slow" to "sometimes hangs"
on TCP, I look at IP+ports, sequence numbers, ACK numbers, flags, window
sizes, timestamps and SACK fields, to figure what's happening. It just
happens that in QUIC all of them except IP+ports are encrypted, which
basically means my only solution will be to ask people "does it still
happen when you block UDP port 443?". And that's really sad. Network
issues are never white-or-black. Large buffers in VM environments cause
retransmits without losses, resulting in apparent loss on one side and
duplicate on the other one. Packets can get corrupted on their way from
one side to the other one, and guess what ? Some devices even manage to
reconstruct a valid checksum, but from inspection you cannot tell whether
the packet is OK or not. Some packets can be dropped past a certain size
(typical problem of PPPoE whose encapsulation takes 8 bytes), resulting
in only full packets not to be delivered. On the side experiencing the
miss, usually you immediately spot this thanks to the sequence number as
you notice a hole of 1460 bytes. Here you still see packets coming but
you don't know anything about them so you can just guess. Did you know
that you can even lose packets between two processes on the loopback
under sustained load ?

Debuggability is a key to any protocol's health. The vast majority of
the fixes that go into any network stack come from observations in the
field resulting in captures exhibiting a bad behavior. Here such captures
will never exist so there will be nothing to fix. This is still what I
really do not like at all in this way of designing a protocol.

Just my two cents,
Willy