[Scone] Re: Talking about the spin bit?

[Mirja Kuehlewind <[e-mail]>]

One comment on the proposed text: while the text is correct and I agree that such a more general statement is more appropriate than the spin bit specific discussion, one could interpret the proposed text below as a call for all kind of network element to become SCONE aware. The text does not say that explicitly but it could easily be read that way. I think that would be the wrong message. Scone packets are usually sent rarely and if you observe the wire image passively, you anyway always need to account for the case where some packets might be missing in some way. So as long as the number of scone packets is small, I wouldn’t assume a need to become scone aware in most cases.

Maybe there is a way to rephrase slightly to make that more clear?


From: Zaheduzzaman Sarker <[e-mail]>
Date: Thursday, 30. April 2026 at 11:21
To: Lucas Pardue <[e-mail]>
Cc: "Brian Trammell (IETF)" <[e-mail]>, Ted Hardie <[e-mail]>, Martin Thomson <[e-mail]>, Marcus Ihlar <[e-mail]>, Christian Huitema <[e-mail]>, Lars Eggert <lars=[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [Scone] Re: Talking about the spin bit?

Given the tone of the proposed text in this email thread which is  --good to have, not really critical, we might actually want to add this to the applicability and manageability document. In that way we keep the text and don't change the scone protocol specification. I can see there a github PR on SCONE clarification for the appman document.

I liked the proposed text, by the way.

//Zahed

On Wed, Apr 29, 2026 at 11:47 AM Lucas Pardue <[e-mail]<mailto:[e-mail]>> wrote:
LGTM

On Wed, Apr 29, 2026, at 09:43, Brian Trammell (IETF) wrote:
+1 lgtm too...

On 29 Apr 2026, at 10:29, Ted Hardie <[e-mail]<mailto:[e-mail]>> wrote:

For what it's worth, this text makes sense to me and I think anyone using the spin bit (whoever they may be) would be sufficiently alerted to the issue by this text.

regards,

Ted Hardie

On Wed, Apr 29, 2026 at 7:28 AM Martin Thomson <[e-mail]<mailto:[e-mail]>> wrote:
Thanks all,

How about the following?

~~~
## QUIC Wire Image Impact

Sending SCONE packets alters the wire image of QUIC (see {{?WIRE=RFC8546}}).
If an on-path observer makes use of aspects of the wire image,
such as the latency spin bit (see {{Section 17.4 of QUIC}}),
but does not understand SCONE,
SCONE packets will affect their ability to access information.
~~~

This leans more into the brevity thing.  I've updated the PR.

(I'd like to publish an updated revision with this soon, which I believe addresses some of the outstanding comments we've received on the list.  Let me know if this doesn't work for you.)

On Fri, Apr 24, 2026, at 16:23, Marcus Ihlar wrote:
> Agree to 1, some brief generic mention is sufficient. And I think we
> should avoid guidance to endpoints that set the spin bit.
> Any additional considerations could be handled in the appman document,
> but I'm not sure that's needed either.
>
> -----Original Message-----
> From: Christian Huitema <[e-mail]<mailto:[e-mail]>>
> Sent: Friday, 24 April 2026 07:22
> To: Brian Trammell (IETF) <[e-mail]<mailto:[e-mail]>>; Lucas Pardue
> <[e-mail]<mailto:[e-mail]>>
> Cc: Lars Eggert <lars=[e-mail]<mailto:[e-mail]>>; Martin Thomson
> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Subject: [Scone] Re: Talking about the spin bit?
>
> As Martin said in his original email, I am ambivalent here, and I see a
> consensus forming:
>
> 1- Some neutral way of saying that SCONE does change the wire image, so
> observers may be surprised that they have to skip over the SCONE packet.
>
> 2- As for the spin bit, there does not seem to be a lot of usage. Those
> systems that care about reading the bit will have to be updated to skip
> the SCONE packet.
>
> -- Christian Huitema
>
> On 4/23/2026 10:04 PM, Brian Trammell (IETF) wrote:
>> (as individual)
>>
>>> On 24 Apr 2026, at 02:34, Lucas Pardue <[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>> The one thing that did come to mind was, could you make the text more
>>> generic to state something like "SCONE can affect the visibility of
>>> the QUIC wire image. Some parts of that image may be used by on path
>>> observers (e.g. the spin bit) ..."
>>
>> +1 to this suggestion.
>>
>> I’m also not sure how useful (or even correct) the “defer scone on a
>> spin bit edge” guidance is, so I’d omit it in any case.
>>
>> SCONE is a signaling approach meant for real-time interaction by
>> network elements, while the concept of operations for the spin bit is
>> entirely passive and equivalent to the functionality it replaces in
>> the TCP wire image: as with seq/ack and TS tracking, to make effective
>> use of it, you’re going to be doing enough per-flow state tracking and
>> post-processing of the raw signal that if you as a network elements
>> really care about where the spin bit appears in the packet, you’re
>> probably doing it wrong.
>>
>> IOW SCONE in my mind clearly has “fast recognition in the datagram”
>> priority over the spin bit, even for theoretical endpoints that
>> enthusiastically support both.
>>
>> Generic wire image impact guidance seems useful though.
>>
>> Cheers,
>>
>> Brian
>>
>>>
>>> On Fri, Apr 24, 2026, at 01:16, Lars Eggert wrote:
>>>> Hi,
>>>>
>>>> On Apr 23, 2026, at 13:37, Martin Thomson <[e-mail]<mailto:[e-mail]>> wrote:
>>>> > We're a little bit split on whether to say anything, so we have
>>>> option A (do nothing) and option B (the text below).  Which do you
>>>> prefer?  Why?
>>>>
>>>> No strong opinion either. The spin bit is practically irrelevant on
>>>> the Internet, given its deployment, so I don’t see a good reason to
>>>> write more test about it. Then again, the proposed paragraph is
>>>> pretty short, so :shrug:?
>>>>
>>>> Thanks,
>>>> Lars
>>>>
>>>>
>>>> _______________________________________________
>>>> Scone mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to
>>>> [e-mail]<mailto:[e-mail]>
>>>>
>>>>
>>>> *Attachments:*
>>>>
>>>>   * signature.asc
>>>>
>>>
>>> _______________________________________________
>>> Scone mailing list -- [e-mail]<mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>
>> _______________________________________________
>> Scone mailing list -- [e-mail]<mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>
> _______________________________________________
> Scone mailing list -- [e-mail]<mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

_______________________________________________
Scone mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Scone mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Scone mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>