Re: What CSRs Do

[Willy Tarreau <[e-mail]>]

On Tue, Nov 19, 2019 at 04:51:14AM +0100, Frode Kileng wrote:
> 
> On 19/11/2019 04:34, Border, John wrote:
> > 
> >      I agree that it is too late to solve problems like troubleshooting
> > packet loss for v1.  Plus, we want a good solution (which takes time). 
> > But, we need to solve this problem or it will impact QUICv1
> > deployment...
> > 
> >      When a customer calls reporting that an application does not work,
> > the Customer Service Representative is trained to do whatever it takes
> > to fix the problem as quickly as possible.  Time on the phone equals
> > money.  And, unhappy customers equal churn.  There is a lot of anecdotal
> > learning involved with the troubleshooting process. If the CSRs learn
> > that disabling QUIC fixes the problem (because the application falls
> > back to TCP), eventually this will become the first thing that is tried
> > every time. Eventually, their supervisors will push for disabling it
> > across the board.  Once disabled, it is a lot of work to get it
> > reenabled.
> > 
> I do think this exemplifies that some network operators have operational
> practices they want to preserve and requests "packet loss" signal support in
> v1. Other operators use alternative operational practices.

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. Actually
this is already what incompetent operators do, hence the common need for
captures to know whether everything is OK at one point or not. Usually
this has to be done within the operator's infrastructure once others
around managed to prove that something is already missing on their side.

> Should the WG 
> make efforts to contribute to preserving current practices of some network
> operators?

It will depend how long some operators will want to troubleshoot the issues
before claiming the protocol doesn't work :-/  Worse, since the network stack
will be implemented in browsers and servers, they will simply point the
fingers at these components, proving that just changing them (hence the
protocol as well) solves the issue. My personal take on this has been
expressed many times, which is that network must be observable if you want
to fix it, otherwise it degrades by itself till a point of poor quality
that "works enough" for most users (e.g. public WiFi access points). Things
as simple as detecting packet reordering caused by multiple paths is trivial
at the TCP level, it's way harder when you cannot say what the packet is
about.

> Frode

Willy