Feedback-ID: ic129442d:Fastmail
MIME-Version: 1.0
Date: Wed, 22 Apr 2026 14:50:14 -0400
From: "Martin Thomson" <mt@lowentropy.net>
To: "Martin Duke" <martin.h.duke@gmail.com>, scone@ietf.org
Message-Id: <489881b6-ea4c-4f82-9361-ed70a3f60515@app.fastmail.com>
In-Reply-To: 
 <CAM4esxS0Lw+qSDhLydL69_v_tBKvgKbZ2u=CjrjBc9szxgSu3g@mail.gmail.com>
References: 
 <CAM4esxS0Lw+qSDhLydL69_v_tBKvgKbZ2u=CjrjBc9szxgSu3g@mail.gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-ID-Hash: LCEYYRT4M3LQAL6UYDNKD6F6LPEKSXMC
CC: Ian Swett <ianswett=40google.com@dmarc.ietf.org>,
 "pawelj@google.com" <pawelj@google.com>,
 "mjbshaw@google.com" <mjbshaw@google.com>
Precedence: list
Subject: =?utf-8?q?=5BScone=5D_Re=3A_New_draft=3A_scone-echo?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/scone/sjHCbFyMnjfYd7NvjMYOGevQHA8>

There are a few aspects to this design that I had trouble making sense of:

* Why does this need to send a frame for every SCONE packet received, rather than just when the signal changes? (My previous email.)

* Why does this need to include information about the packet number of the packet that was accepted alongside the SCONE signal?  Is this to manage ordering?  I seriously doubt the importance of managing ordering of signals given the time frames we're talking about if you stick to updates only, so while this seems harmless, it might be better to use a simple index instead if you care about ordering.

* Why are there two transport parameters?  The _receive version is the only one that makes a lot of sense to me.  There are two aspects to "support" in this context: sending the frame and receiving the frame.  A sender doesn't need to indicate that it can send, because QUIC's frame extension semantics don't govern the sending of new frames, only the receiving of them.

* In general, the transport parameter handling is weird.  You have three permissible configurations: scone_enabled only (where you can receive SCONE packets), _send only (where you receive SCONE packets and echo them). and _send plus _receive (where you echo SCONE packets and might receive echoes).  Why prohibit the use of scone_enabled when you have _send, but not have the same restriction on _receive for _send?  See above on negotiation.  I would prefer that this not couple extensions together at all; this is not something that needs to be optimized that way, certainly not in an inconsistent fashion as you propose.


On Tue, Apr 21, 2026, at 16:25, Martin Duke wrote:
> Hello SCONE,
>
> I've published a new internet-draft:
> https://datatracker.ietf.org/doc/draft-duke-scone-scone-echo/
>
> Basically, it's a QUIC extension to report bandwidth advice back to the 
> SCONE sender in a QUIC frame. We have some edge cases where the sender 
> can do useful things with this advice but the receiving application is 
> unable to cooperate. See the intro for a somewhat more thorough 
> discussion of that.
>
> The relevant chairs/AD agreed this should sit in SCONE and not QUICWG, 
> although it may need a recharter.
>
> Anyway, if this interests you, take a look and file issues in the 
> github <https://github.com/martinduke/scone-echo>.
>
> Thanks,
> Martin
> _______________________________________________
> Scone mailing list -- scone@ietf.org
> To unsubscribe send an email to scone-leave@ietf.org