Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> congestion control (was logging)

[Christian Huitema <[e-mail]>]

On 10/14/2019 8:10 AM, Gorry Fairhurst wrote:
>>> * researchers/equipment developers seeking to correlate/tune transport
>>> timing with network policies (e.g., interactions between congestion
>>> control and link scheduling);
>> This seems quite similar to the protocol developer problem.
> Except it's not really... in this case, the network device/segment
> being observed is moving traffic, and observers often don't have much
> clue about the client's platform, app setups, etc. Why would they?
> (They also don't have away to turn-on debug or logging at clients) -
> if I look at a queue, I see packets. If I know these packets are using
> a well-known protocol TCP, RTP, etc, I can look to see how the CC is
> being impacted by the way that I configure my device (I could tune
> things if I had incentive), if it's IPsec-encrypted traffic, I would
> generally not bother looking more. I think some people  contributed
> text to an earlier revision in this direction, please see if that
> seems to be heading in a useful direction. 


OK. I did raise the issue about end-to-end transports experimenting with
new and improved congestion control algorithms, and actually did a
presentation about that in Montreal in the TCPM WG. The feedback was
really a push back. My fears were not grounded they said, because if
this was a problem the network would have collapsed long ago, said in so
many word a queue of distinguished speakers at the microphone. What of
servers adopting IW=gigantic, or video streamers doing no congestion at
all. The network has defenses, etc.

That kind of feedback means that experimenting with congestion control
algorithm in encrypted transports is going to become the norm. And
indeed, I am seeing some of that in the Quic Interop taking place right
now. One of the tests compares downloading a 10MB file with Quic and
downloading the same file with HTTPS/HTTP2. Many implementations manage
much better times with Quic. The download times vary per server, but I
saw results like  3.5 sec with Quic versus 8.5 sec with HTTPS. Against
my own server, I get 3.6 seconds with Quic versus 7.5 with HTTPS. This
did not imply cheating, but merely attention to details in the
implementation of Hystart or Cubic, including filtering of delay
measurements and management of spurious retransmit.

But my point is not to bore you with details of implementations, but to
show that it is very hard for an observer in the middle of the network
to reason about how generic client implementations will react to a
specific network tuning  link management policy. All implementations
will not react in the same way. A given implementation may also react
differently over time: the developers will learn by experience about the
new management policy. They are likely to tune their implementation to
benefit from your tuning of the network.

If you really want to observe an implementation's reaction, the best way
is to perform a controlled test, in which you instrument the client or
the server and run them against your proposed tuning. You will probably
need to do that for a couple of client and servers -- say Chrome and
Firefox, Apache and NGINX. And you will get a snapshot of behavior.

But the real change is that you should consider game theory, and see
what kind of Nash equilibrium results from the combination of your
proposed changes and the implementations' responses. This requires a
change of mindset, and that should probably be explained in the draft.

-- Christian Huitema