[SCONE] Re: Fwd: New Version Notification for draft-duke-scone-scone-echo-03.txt

[Christian Huitema <[e-mail]>]

Doing my own review.

1) Everything Martin said about frequency of updates.

2) Do you really need to say anything about the indicator? I would drop 5.1.

3) The packet number is weird. SCONE packets can in theory be coalesced 
with handshake packets, and those have different packet numbers. If we 
use the packet number as a filter against repeats, the handshake 
feedback will preempt feedback received in early 1RTT packets.

4) Packet number and multipath. Both the packet number space and the 
path bandwidth are per path, not per connection. I would suggest adding 
a path ID field in the echo, to specifies for which path the echo is 
reported.

-- Christian Huitema

On 9/29/2026 1:42 PM, Martin Duke wrote:
> Trimming down again.
>
> On Tue, Sep 29, 2026 at 9:12 AM Martin Thomson <[e-mail]> wrote:
>
>>> I agree that the text here is vague. I will say that SCONE_ECHO SHOULD
>>> wait until the sender has an ack-eliciting packet to send.
>> If you do that, you probably need to add some sort of age marker to the
>> SCONE_ECHO frame so that the sender, who is reconstructing the throughput
>> advice, can account for delays in propagation.
>>
> Well the frame contains the originating QUIC packet number, which I suspect
> is good enough? I put that in there to detect misbehaving network elements,
> but this is another benefit of the fiedl.
>
>
>> Yeah, I think that there's a continuum of options here: either report
>> every bit of advice that is received (the present design), reporting edges
>> (still probably OK, but vulnerable to oscillations if the path doesn't
>> supply stable advice), reporting reconstructed advice (simple, but maybe
>> imperfect, see
>> https://github.com/mozilla/neqo/blob/main/neqo-transport/src/scone.rs for
>> a simple, but imperfect algorithm), or maybe insisting on perfect feedback.
>>
> Reporting edges seems like the sweet spot between limiting traffic and
> building too many assumptions into feedback, and adding receiver complexity.
>
>> I don't really understand what you mean on the second proposal "rather
>>> than having the sender run the algorithm." Is that a different proposal
>>> from just sending SCONE_ECHO on advice changes?
>> The current design requires that the series of SCONE_ECHO packets received
>> by the sender are turned into advice.  That's what I was referring to.
>>
> I'm having trouble grokking your distinct concepts of "packets received"
> and "advice". Maybe something is unclear in the draft is that the receiver
> just gets the raw data back to the sender and lets the sender figure out
> what to do with it. A sender that can do scone-echo and scone-protocol is
> almost certainly not applying the same processing to the two code paths.
>
>
>>> I suppose this would work, but the cost is sending an expendable packet
>>> to avoid sending a transport parameter? That seems like a poor trade,
>>> in addition to violating the general principle of "be conservative
>>> about what you send."
>> An expendable SCONE packet.  Something you wanted to do anyway.  Assuming
>> that you intend to act on advice, I suppose.
>>
> Presumably, in normal SCONE, the SCONE packet is typically bundled with
> useful application data, because you're reasonably sure the receiver won't
> drop it?
>
>
>> The concern I have is that scone_echo_send is a commitment to send the
>> frame when you get advice.
>>
>>>> I don't think that scone_echo_receive qualifies as needing the
>> indicator here.  The indicator is associated with the *receipt* of SCONE
>> packets, not the sending of them.
>>> The scone-protocol draft says "All new flows that are initiated by a
>>> client that supports SCONE MUST include bytes with values 0xc8 and 0x13
>>> as the last two bytes of the payload of the UDP datagrams that commence
>>> a new flow, if the QUIC version in use permits the inclusion of data
>>> after packets." However imperfect that signal is, I read it to mean it
>>> was a signal to the NE that the 4-tuple could carry SCONE, potentially
>>> client-to-server. But you wrote the spec, so I'm probably
>>> misinterpreting it. Perhaps it needs to be reworded?
>>>
>>> BTW I'm almost certain I didn't implement this correctly if everyone
>>> else shares your interpretation of scone-protocol.
>> Yeah, maybe that's a fault in the language there.  My interpretation there
>> is that you send the indicator if you set the transport parameter.  That
>> means that the indicator is present if the SCONE packets might flow in the
>> opposite direction only.
>>
> OK, I guess there's no harm in sending more often than necessary. If
> everyone agrees that's the interpretation, though, I suggest you reword
> scone-protocol and I'll update this as well.
>
> _______________________________________________
> SCONE mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]