Ballot for draft-ietf-scone-protocol
Discuss
Yes
No Objection
Abstain
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Section 3.3 addresses one tunneling scenario -- SCONE riding inside a tunneled flow such as CONNECT-UDP, where advice can only be applied to the outermost flow: 301 > When network elements provide throughput advice to a QUIC flow that 302 > encapsulates tunneled flows (such as [CONNECT-UDP]) they can only 303 > provide the advice to the outermost flow. Endpoints can apply the 304 > throughput advice to packets in flows that are subsequently 305 > encapsulated, but following that advice can have privacy 306 > implications; see Section 10.2. It doesn't address the opposite scenario, which the WG has been actively discussing on-list, which remains unresolved: SCONE packets being the ones that get tunneled away, by a QUIC-aware proxy sitting on the path. draft-ietf-masque-quic-proxy-09 (the MASQUE WG's QUIC-Aware Proxying document, referred to as QAP below) is unambiguous that long header QUIC packets are tunneled, not forwarded. draft-ietf-masque-quic-proxy-09, Section 1 (Introduction): "QUIC long header packets between clients and targets MUST be proxied in tunnelled mode. QUIC short header packets between clients and targets MAY be proxied in forwarded mode, subject to negotiation between a client and a proxy." draft-ietf-masque-quic-proxy-09, Section 4.1 (Sending With Forwarded Mode), repeats this for forwarded mode specifically: "QUIC long header packets MUST NOT be forwarded. These packets can only be tunnelled within HTTP Datagram frames to avoid exposing unnecessary connection metadata." A SCONE packet, by contrast, is -- per Section 5 of this document (draft-ietf-scone-protocol) -- always a long header packet. Put the two together and every SCONE packet that crosses a QAP-compliant proxy will get encapsulated inside an HTTP Datagram -- invisible to any network element downstream of that proxy, which would defeat the exact mechanism this document depends on for a network to signal advice. Zaheduzzaman Sarker, who is credited in this document's Acknowledgments, raised this on the list on 2026-09-08: "QUIC aware Proxying (QAP) specification says - a long header QUIC packet MUST be tunneled. SCONE packets are special Long header QUIC packets and SCONE allows coalescing of Long header scone packets and short header packets." Christian Huitema and Martin Thomson each proposed ways to narrow QAP's tunneling rule for this case, but as of 2026-09-14 Sarker replied that Huitema's proposed amendment may not adequately resolve the fundamental visibility problem he identified, and Huitema's own follow-up says he isn't sure his suggestion addresses Sarker's concern, adding that "on path elements will not see the Scone header if it is sent as encrypted data in a capsule." The thread ends there, unresolved, ten days before this telechat. Whatever the eventual resolution turns out to be -- narrowing QAP's forwarding rule, some form of negotiation, or an explicit statement that SCONE does not function across QAP-compliant proxies -- the applicability discussion in this document should say so, particularly given that MASQUE is actively specifying exactly this kind of proxy in parallel. I'd like to understand from the authors, and possibly from Gorry, how this interaction is expected to be resolved.
I support Roman's questions about the Section 7.1 pseudocode: 735 > is_long = packet[0] & 0x80 == 0x80 736 > packet_version = ntohl(packet[1..5]) 737 > if is_long and (packet_version & 0x7fffffff) == SCONE_VERSION_BITS: 738 > packet_signal = ((packet[0] & 0x3f) << 1) | (packet_version >> 31) 739 > if target_signal < packet_signal: 740 > packet[0] = (packet[0] & 0xc0) | (target_signal >> 1) 741 > packet[1] = (packet[1] & 0x7f) | ((target_signal & 1) << 7) Beyond the operator-precedence and ntohl() questions Roman raised, SCONE_VERSION_BITS is used but never defined anywhere in the text -- a reader has to infer it's 0x6f7dc0fd from the surrounding prose. Since this pseudocode is illustrative rather than normative, the fix is cheap: either define the constant inline or drop the pseudocode in favor of the prose in Section 5.1, which is already unambiguous on its own. --- Both Roman and Andrew Yourtchenko (INTDIR) asked why Section 7.1 cites RFC 1141 rather than RFC 1624 for the incremental checksum update: 743 > Once the throughput advice is updated, the network element updates 744 > the UDP checksum for the datagram; see [RFC1141]. There's a concrete reason to prefer 1624 here: RFC 1141's incremental-update formula has a known bug at the ones'-complement zero boundary, which RFC 1624 fixes -- 1141's arithmetic can produce a computed checksum of 0x0000 in a case where the correct encoding is 0xffff. For UDP, a checksum field of zero has the reserved meaning "no checksum computed," so a network element that implements this section by following 1141 literally could end up producing that exact value while flipping the rate-signal bits, silently turning off checksum coverage on a datagram it just modified. I'd cite 1624 here instead of, or in addition to, 1141. --- Andrew Yourtchenko's INTDIR review flagged something I'd also ask about. Section 5.2 justifies the 67-second monitoring period partly on NAT-timer grounds: 535 > The choice of 67 seconds, as a prime number, also helps avoid 536 > synchronization with other periodic effects that are commonly 537 > measured in whole seconds. This includes segment length or key frame 538 > intervals in video applications, but also includes timers for Network 539 > Address Translation (NAT) devices; see Section 4.3 of [RFC4787]. Any 540 > repeating phenomenon at a 67 second interval is therefore unlikely to 541 > be due to other periodic effects. But the cadence this document actually recommends for sending and updating SCONE packets is much shorter than 67 seconds: 899 > Sending a SCONE packet every 20-30 seconds is likely sufficient to 900 > ensure that throughput advice is not lost, though endpoints might It's the 20-30 second traffic, not the 67-second monitoring period, that will actually land near typical NAT idle timeouts. An example showing why 67 seconds was still chosen with that in mind, as Andrew suggests, would help -- right now the NAT-avoidance argument in 5.2 reads as if the 67-second value is the interval that matters, when the packet cadence that actually interacts with NAT timers is set elsewhere. --- I agree with Andrew Yourtchenko's INTDIR point about the tension between 6.2 and 6.4. Section 6.2 is careful to say the two-byte indicator is weak evidence on its own: 668 > There is a non-negligible risk of collision with other protocols or 669 > even QUIC usage without SCONE indications. The indicator is just two 670 > bytes, which could be sent by chance on non-SCONE flows. This means 671 > that the indication alone is not sufficient to indicate that a flow 672 > is QUIC with the potential for SCONE support. but 6.4 describes classifying a flow from that same indicator without repeating the caveat: 697 > A network element could classify all 5-tuples where the first 698 > observed UDP datagram ends in the indicator bytes as potential SCONE. A network element implementer who reads 6.4 in isolation could reasonably treat the indicator as more reliable than 6.2 intends it to be. Restating the 6.2 caveat in 6.4, as Andrew suggests, would close that gap. ---------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 9.1, wrong cross-reference (also caught by Andrew Yourtchenko, INTDIR): 971 > The modification of packets provides endpoints proof that a network 972 > element is in a position to drop datagrams and could apply a rate 973 > limit policy. Section 8.1 states that endpoints only accept signals 974 > if the datagram contains a packet that it accepts to prevent an off- s/Section 8.1 states/Section 5.3 states/ --- Section 2, Figure 1 caption: 174 > that is update by a network element, is shown in Figure 1. s/is update by/is updated by/ --- Section 8.2: 925 > Information about throughout advice is intended for the sending s/throughout advice/throughput advice/
# Charles Eckel, ART AD, IESG ballot: draft-ietf-scone-protocol-08 CC @eckelcu * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-scone-protocol-08.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ Thanks to the authors and the rest of the working group for a well written document. 3GPP is adding support for SCONE in Release 20. It is great to have this moving to pubication well in advance of the Release 20 deadlines. ## Comments ### what is required for a packet to be successfully processed 548 Processing a SCONE packet involves reading the value from the Rate 549 Signal field. However, throughput advice MUST be ignored unless 550 another packet from the same datagram is successfully processed. My assumption is that merely receiving another packet is not sufficient. At what point is a packet that is received considered to have been successfully processed?
Thanks to Ionuț Mihalcea for their secdir reviews.
Thanks in advance to Andrew Yourtchenko for the INT-directorate review when it will be ready. https://datatracker.ietf.org/doc/draft-ietf-scone-protocol/reviewrequest/24961/
Thanks to the authors and the WG for their work on this document.
Please find below some comments on the document and take them as coming from
someone that has not been involved in or following this work. Feel free to
correct me if I am wrong.
The comments are inline in the idnits output of v08 of this document. The end
of the review is marked by the tag <EoRv08>
405 SCONE Packet {
406 Header Form (1) = 1,
407 Reserved (1),
408 Rate Signal High Bits (6),
409 Version (32) = 0x6f7dc0fd or 0xef7dc0fd,
410 Destination Connection ID Length (8),
411 Destination Connection ID (0..2040),
412 Source Connection ID Length (8),
413 Source Connection ID (0..2040),
414 }
<question> Figure 2 shows the SCONE packet ending after the Source Connection ID
field. RFC 8999 Section 5.1 says the remainder of a long header packet is
version-specific content. Does this mean that the SCONE packet does not have
anything beyond what is shown in the figure? I am not able to get this clearly
from the text; perhaps I am missing something. Can this be clarified?
433 This packet includes a Destination Connection ID field that is set to
434 the same value as other packets in the same datagram; see
435 Section 12.2 of [QUIC].
<major> Section 5 states the Destination Connection ID rule descriptively
while Section 5.3 makes violating it a discard condition, and the neighbouring
Source Connection ID rule in the same section does carry a keyword. Suggest
matching them:
CURRENT
This packet includes a Destination Connection ID field that is set to
the same value as other packets in the same datagram; see Section 12.2
of [QUIC].
SUGGEST
The Destination Connection ID field MUST be set to the same value as
the Destination Connection ID of the other packets in the same
datagram; see Section 12.2 of [QUIC].
459 When sent by a QUIC endpoint, the Rate Signal is set to 127.
460 Receiving a value of 127 indicates that throughput advice is unknown,
461 either because network elements on the path are not providing advice
462 or they do not support SCONE. All other values (0 through 126)
463 represent the ceiling of rates advised by the network element(s) on
<minor> Section 5.1 tells a receiver what the value 127 means, and Section 5.3
then has the packet carrying it discarded, so the inference in 5.1 cannot be
acted on. It seems somewhat contradictory to me. Perhaps suggest saying that a
SCONE packet carrying 127 conveys no advice, and leaves any advice already
held, and its expiry timer, untouched?
564 When discarding a SCONE packet due to inconsistent Connection IDs,
565 endpoints MAY also discard the QUIC packets that were coalesced into
566 the same datagram.
<question> Section 5.3 allows a receiver that discards a SCONE packet for
inconsistent Connection IDs to discard the coalesced QUIC packets as well.
Could you explain why? I am bringing this up as it look an inconsistency at
the SCONE layer is affecting (dropping) application data.
572 If a connection uses multiple Differentiated Services Code Point
573 (DSCP) markings [RFC2474], the throughput advice that is received on
574 datagrams with one marking might not apply to datagrams that have
575 different markings.
<minor> This is the only reference to [RFC2474] and does not seem like a
normative but an informative reference to me.
585 An endpoint that receives throughput advice might receive multiple
586 different values. If advice is applied by applications, applications
587 MUST apply the lowest throughput advice received during any
588 monitoring period; see Section 5.2.
<major> Section 5.4 places a normative requirement on applications, which the
document elsewhere leaves free to ignore advice entirely, and anchors it to
"any monitoring period" where Section 5.2 gives a duration but no boundary and
each party keeps its own window. Perhaps it can be tweaked as a rule on the
endpoint, which can be then conformed to?
CURRENT
An endpoint that receives throughput advice might receive multiple
different values. If advice is applied by applications, applications
MUST apply the lowest throughput advice received during any monitoring
period; see Section 5.2.
SUGGEST
An endpoint that receives throughput advice might receive multiple
different values. An endpoint MUST report to the application the
lowest throughput advice it holds that has not expired; see Section
5.4 for expiry.
746 Once the throughput advice is updated, the network element updates
747 the UDP checksum for the datagram; see [RFC1141].
<major> Does this not make RFC 1141 a normative reference?
1163 This document registers the following entries to the "QUIC Versions"
1164 registry maintained at https://www.iana.org/assignments/quic
1165 (https://www.iana.org/assignments/quic), following the guidance from
1166 Section 22.2 of [QUIC].
<minor> All three codepoints are already in the IANA QUIC registries as
provisional registrations, made against -04 on 2026-04-16. What is being asked
of IANA is therefore to make three existing registrations permanent and update
their reference to this RFC, rather than to register three new entries.
Suggest saying that, since the two registries' permanent and provisional
policies differ.
1189 Value: 0x219e
1190 Parameter Name: scone_supported
1191 Status: Permanent
1192 Specification: This document
1193 Date: This date
1194 Change Controller: IETF (iesg@ietf.org)
1195 Contact: QUIC Working Group (quic@ietf.org)
1196 Notes: (none)
<nit> The "Date: This date" reads odd. This would be set by IANA and it does
not need to be specified just as it was not included in the template for the
QUIC versions registration in section 11.1 ?
<EoRv08>
# IESG review of draft-ietf-scone-protocol-08 CC @MikeBishop ## Comments ### Section 5.4, paragraph 2 I fail to see how there can be a MUST in following an advisory signal. MUST expose the information to the application is fine, but applications choose what to do with the signal from there. ### Section 6.1, paragraph 1 This statement confused me initially. I think where you're actually going is that while QUICv1/v2 define a Length field for long-header packets, RFC8999 doesn't specify one and therefore some future versions of QUIC might not permit that. I would suggest being less coy about the scenario you're talking about. It's not clear that "the protocol" here means the QUIC version in use rather than the application protocol, and this statement being the application protocol would raise some additional questions. ### Section 7.1, paragraph 7 The IntDir review raised some serious issues around checksums. I see that text to address this was proposed in PR#172, and has reviews from a number of involved folks including your responsible AD. I don't think this can ship without addressing those issues; this would have been a DISCUSS had this not been immediately before the telechat. ### Section 9.1, paragraph 4 Aren't you really trying to say the opposite, that you cannot guarantee it *was* generated by someone on-path, or more generally, that the endpoint can't reliably differentiate the two? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 2, paragraph 3 ``` - that is update by a network element, is shown in Figure 1. + that is updated by a network element, is shown in Figure 1. + + ``` #### Section 6, paragraph 3 ``` - non-zero length scone_supported transport parameter MUST be treated - ^ + non-zero-length scone_supported transport parameter MUST be treated + ^ ``` #### Section 8.2, paragraph 1 ``` - Information about throughout advice is intended for the sending - ^ + Information about throughput advice is intended for the sending + ^ ``` #### Section 9.1, paragraph 4 ``` - similar to those of on path elements. An off-path attacker can - ^ + similar to those of on-path elements. An off-path attacker can + ^ ``` ### Grammar/style #### Section 1, paragraph 2 ``` delays and loss -- operate on a time scale of a round trip time, throughput ^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 5.1, paragraph 8 ``` ]. Any repeating phenomenon at a 67 second interval is therefore unlikely to ^^^^^^^^^ ``` When a number forms part of an adjectival compound, use a hyphen. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Thank you to Thomas Fossati for the GENART review. ** Section 7.1. Clarity of the pseudo-code -- Line1: “is_long = packet[0] & 0x80 == 0x80” Not knowing the operator precedence, should this be “is_long = (packet[0] & 0x80) == 0x80”? -- Line2: “packet_version = ntohl(packet[1..5])” Does packet[1..5] assume the bytes 1..5 inclusive making it a 5-bytes array? Doesn’t ntohl() typically take a 32-bit integer? Should ntohl() be defined? -- Line3: “if is_long and (packet_version & 0x7fffffff) == SCONE_VERSION_BITS:” Same as Line1, should this be “(is_long and (packet_version & 0x7fffffff))”? Where is SCONE_VERSION_BITS defined? ** Section 7.1 Once the throughput advice is updated, the network element updates the UDP checksum for the datagram; see [RFC1141]. Why is RFC1624 not used instead of RFC1141?
Hi Martin, Christian, Kazuho, Matt, and Marcus, Thank you for the effort put into this specification. Overall, the document does a great job in calling out what it does, what it does not aim to, some limitations, etc. I even found the guidance in the deployment section of this specification more informative than draft-ietf-scone-applicability-manageability for some specific points. There is, however, some divergence between the posture in the base spec and APPMAN I-D on key aspects, e.g., Base Spec A signal that is sent for a specific flow could apply to a collection of flows, rather than a single flow. The scope of the flows that are included is not carried in the signal. APPMAN Because throughput advice applies strictly to this specific flow, SCONE Network Elements need to unambiguously associate their policy limits with the correct QUIC flows. ... but that is beyond the scope of this review. I’m supportive of collaborative networking, where both hosts and networks can share some signals that are helpful for specific optimizations. I would definitely be balloting YES if this specification was Experimental. However, given that (1) similar transport-specific signals were tried in the past and failed (mobile throughput guidance, as example), (2) the claimed benefits are to be yet assessed, (3) the added complexity to the application which need to support both some kind heuristics to detect the capacity (see, for example, [1]), and (4) that a data plane modification is required in the network side including to inspect/track flows and modify packets while leverage out of band mechanism available out there, I’m ABSTAINing. The other reasons for my Abstain are: # Impact on Trust Model and Accountability Concerns Any random element on the path can inject the signal. Reacting to such random signals may impact the quality of experience and that question the accountability. # Deployment vs. Immediate Effect The document says: The advised throughput will likely only be achievable when the application is the only entity consuming bandwidth in the scope that the advice applies to. Which means that an operator that deploy the mechanism won’t get the benefit(s) (whatsoever that means) if the remote server does not engage. # Lack of signal scope & Inefficiency The interpretation of the signal is left to the app endpoint that receives it. If interpreted as flow-specific, competing flows on the same endpoints will exceed the overall capacity and thus this lead to the same situation as if the signal was not shared at the first place. # No protocol transport parity Such parity can be, of course, ensured by echoing this extension for TCP and UDP (no-quic) but that is suboptimal for networks and also endpoints while a transport-agnostic signal would be more efficient. # Flow-based ACLs can be bypassed by migrating to a new tuple There are several limitations of enforcing a per-flow ACL. The usual policy is per-subscriber policy, not per flow. # Unpractical advices For example: A network could choose to either disable or loosen policy enforcement for flows where SCONE is active, but re- enable or tighten enforcement if monitoring indicates that throughput advice is not being respected. This can’t be implemented as networks need to protect themselves against a variety of overload events, anyway. Cheers, Med [1] https://datatracker.ietf.org/meeting/119/materials/slides-119-moq-bandwidth-measurement-for-quic-00