[tcpPrague] "Warn me if queue is growing"

John Leslie <john@jlc.net> Mon, 08 August 2016 14:52 UTC

Date: Mon, 08 Aug 2016 10:52:13 -0400
From: John Leslie <john@jlc.net>
To: tcpPrague@ietf.org
Message-ID: <20160808145213.GE4396@verdi>
References: <a1a361009951426e803daf3e5bcf37ee@rew09926dag03b.domain1.systemhost.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <a1a361009951426e803daf3e5bcf37ee@rew09926dag03b.domain1.systemhost.net>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/RVPB5zMNBFbJ4inrszgsTyqK_hs>
Subject: [tcpPrague] "Warn me if queue is growing"
Precedence: list

philip.eardley@bt.com <philip.eardley@bt.com> wrote:
> 
> Here are the draft minutes for the L4S BoF. Many thanks for Steve Blake
> for the excellent notes.
> 
> BOF: Low Latency Low Loss Scalable throughout (L4S) Draft Agenda for Berlin
> ...
> 7. Discussion about the technology
> ...
> - Christian Huitema: There is a lot of discussion about the relation of
>   ECN feedback with two queues vs. multi-queue (e.g., FQ-Codel).  With
>   flow isolation, each flow can have its own feedback.  If you look at
>   what you are doing, you are specifying a new network feedback mechanism
>   (please warn me very quickly if the queueing is going up).

   Such a signal makes a lot of sense!

> I have reservations about embedding the square root coupling into the
> mechanism; TCP is not square root.  It's a hack.

   Indeed, it is a hack. Offhand, it looks like a promising hack...

> - Koen: with slow start, short flows don't get any feedback.  With
>   short RTT you can respond quickly...

> - CH: very small fraction of flows are long flows.

   Indeed, a lot of the problem comes from short flows which never learn
the queue is growing (unless the RTT growth is obvious enough not to be
drowned out by noise).

> - Koen: video quality performance depends on throughput and low latency.
>   VR video needs lower latency/higher throughput.

> - CH: be careful about hacks

   Always valid advice; but I fear Christian may be missing the point. :^(

   (He's hardly alone!)

   I don't see the question of the difference between the two "marking"
algorithms as central to this; so I'm not worried about the particular
relation between them at the start of our experiment.

   Instead, I worry how to match the benefit of faster response (as
distinct from faster delivery) to use of the short queue, and the
benefit of queueing to une of the longer queue.

   I suggest considering whether queueing should ever be a significant
delay unless queueing is specifically requested...

> - Bob: I agree it is worrying to put a formula into the architecture.
>   Having a shallow threshold on L4S side allows you to test the capacity
>   more quickly to get your short flows going faster.

   (Bob and I agree! Surprise!)

   (Is there hope of getting Bob and Christian to agree?)

   I think it would help to separate the ideas of quick delivery and
quick response...

   I'm not particular how we do it: I wouldn't mind if we invented a
"response" which didn't deliver the whole packet...

   IMHO, we _can't_ promise quick delivery when congestion is present.
The best we can do is promise not to delay the response.

   In an ideal world, we'd have a way to respond (to the sender) without
needing to deliver the packet. Alas, I see no solution while source
addresses are so easily forged.

   But we can, at least, be clear whether we're promising quicker delivery
or quicker response.

--
John Leslie <john@jlc.net>

[tcpPrague] "Warn me if queue is growing" John Leslie
[tcpPrague] draft minutes for the L4S BoF philip.eardley