It looks like you still show the first slide.
", "time": "2025-09-17T15:08:37Z"}, {"author": "Qin Wu", "text": "thanks Marcus
", "time": "2025-09-17T15:10:22Z"}, {"author": "Marcus Ihlar", "text": "I think this document should only give high level examples and not get bogged down in details of 3GPP procedures etc.
", "time": "2025-09-17T15:30:17Z"}, {"author": "Sanjay Mishra", "text": "we are trying to balance to show how SCONE fits within the 3GPP spec
", "time": "2025-09-17T15:31:19Z"}, {"author": "Michael Richardson", "text": "I think it needs explain enough specifics about 3GPP so that someone who hasn't operated such a network can understand (in 5 years) why certain choices were made in SCONE. The reader is probably looking for how much overlap their use case has with the 3GPP case.
", "time": "2025-09-17T15:32:35Z"}, {"author": "Michael Richardson", "text": "MVNOs might not have access to the counters?
", "time": "2025-09-17T15:34:31Z"}, {"author": "Kazuho Oku", "text": "We discussed a fixed 1gbe network sending SCONE indicating that 1Gbps is available and SCONE can be used there.
\nIn such network elements, there is no need for enforcement.
+1 To having these discussions in the WG.
", "time": "2025-09-17T15:36:58Z"}, {"author": "Michael Richardson", "text": "issues/etc. can be transferred from one github to another, upon adoption.
", "time": "2025-09-17T15:36:59Z"}, {"author": "Zaheduzzaman Sarker", "text": "I heard the chairs wanted to host this draft in the WG github even before it gets adopted. If the draft is in acceptable shape. Is that still possible?
", "time": "2025-09-17T15:38:22Z"}, {"author": "Kazuho Oku", "text": "For the purpose of getting broad review for this document, +1 to Marcus for reducing specifics to 3GPP networks. I'm not sure how many of us at IETF are familiar with 3GPP.
", "time": "2025-09-17T15:40:37Z"}, {"author": "Zaheduzzaman Sarker", "text": "This draft has been shaped now to push the 3GPP specific things at the bottom :-). It could be helpful when discussing stuffs.. but later if not needed can be put to appendix or cut out totally
", "time": "2025-09-17T15:42:26Z"}, {"author": "Zaheduzzaman Sarker", "text": "+1 to talk about ECN/L4s + SCONE,
", "time": "2025-09-17T15:47:20Z"}, {"author": "Jon Varsanik", "text": "Did we document somewhere the reason for 67 second time period? I couldn't find a definite rationale written down anywhere.
", "time": "2025-09-17T16:09:34Z"}, {"author": "Alan Frindell", "text": "it's in the pr now
", "time": "2025-09-17T16:09:43Z"}, {"author": "Alan Frindell", "text": "The choice of 67 seconds, as a prime number,
\nalso ensures that problems in tuning applications
\nare not synchronized with other periodic effects
\nthat might be measured in whole seconds.
\nThis includes segment length or key frame intervals in video applications,
\nbut also includes timers for middleboxes; see {{Section 4.3 of ?RFC4787}}.
\nAny repeating phenomenon at a 67 second interval is therefore
\nunlikely to be due to other periodic effects.
Thanks!
", "time": "2025-09-17T16:10:43Z"}, {"author": "Gorry Fairhurst", "text": "/ensures/ guarantees? or ... mitigates / reduces?
", "time": "2025-09-17T16:12:05Z"}, {"author": "Kazuho Oku", "text": "merge and discuss the remainder separately
", "time": "2025-09-17T16:15:27Z"}, {"author": "Jon Varsanik", "text": "I agree with this - I think that having an \"unknown\" value helps address both concerns.
", "time": "2025-09-17T16:17:24Z"}, {"author": "Jon Varsanik", "text": "But the concern there is that it doesn't account for shifts in network paths.
", "time": "2025-09-17T16:18:16Z"}, {"author": "Brian Trammell", "text": "(time check, locking the queue)
", "time": "2025-09-17T16:21:50Z"}, {"author": "Kazuho Oku", "text": "yeah, to handle packet loss, you have to retransmit, and to retransmit, yo need to keep state
", "time": "2025-09-17T16:24:48Z"}, {"author": "Jon Varsanik", "text": "My understanding (form what I have heard) is that looking for the SCONE packets is expensive, and if SCONE packets are infrequent, then NE have to look for these packets for a large part of that 67 seconds. (But yes, we should get the information directly from the folks with the constraints)
", "time": "2025-09-17T16:25:16Z"}, {"author": "Jon Varsanik", "text": "looking for the SCONE header
", "time": "2025-09-17T16:25:46Z"}, {"author": "Ian Swett", "text": "Path change can mean different things. I can move from 4g to 5g, which ideally is transparent to the endpoints.
", "time": "2025-09-17T16:27:30Z"}, {"author": "Anoop Tomar", "text": "To avoid ambiguity, we should clarify the PR text to specify clearly that NW is required to update SCONE packet atleast once in every 67 sec and remove \"monitoring period\" from here as NE are allowed to set the monitoring period value to larger value than 67 second.
", "time": "2025-09-17T16:28:09Z"}, {"author": "Alan Frindell", "text": "sorry to break up the exciting live streaming of the merge
", "time": "2025-09-17T16:28:45Z"}, {"author": "Zaheduzzaman Sarker", "text": "if you are at the same MNO and you go from 5G to 4G then I expect you would get a scone rate change signal.
", "time": "2025-09-17T16:29:25Z"}, {"author": "Alan Frindell", "text": "This time slot is ideal scone eating time for US West Coast, but we should do something mt friendly next
", "time": "2025-09-17T16:29:48Z"}]