Session Date/Time: 30 Apr 2026 14:00
This is a verbatim transcript of the SCONE interim meeting on May 2, 2026.
Brian Trammell: Check, check on audio and video. Can everyone hear me?
Sanjay Mishra: Yeah, I can hear you.
Brian Trammell: Excellent. I'm looking at the participant list. I'm thinking that we might want to wait a minute or two for people to come in before we actually start hitting the GitHub queue. Let me actually see if I can drive that, hold on. Yeah, so the admin trivia is going to be—that's actually a pretty good point. Do we want to go ahead and hit Note Well? This is an IETF working group meeting. The Note Well applies. If you have—I see all of the participants here, I recognize all the names, I know you've all seen this. However, if you would like to refresh your understanding of the Note Well, please read the slide. It's in the meeting materials. Scan the QR code. Next.
Working group status: we've got five issues and two PRs on the draft-ietf-scone-protocol. I think we're not going to be discussing those today unless the editors of those have anything in any other business that they'd like to discuss. Today we are here to drive to some form of conclusion on AppMan (draft-ietf-scone-applicability-manageability). What I'd like to get at the end of this meeting is all of the PRs are either merged or we have a clear path to merging those PRs. All of the issues that do not yet have PRs have assignees who are assigned up to provide PRs for those issues, such that we can get a revision of this draft submitted and sent up for Operations Directorate early review by, I want to say the 15th of May, so two weeks from now. I know that's an aggressive timeline.
Then, at the end of the meeting here, I will flash up—actually, we should put the link in the slides for those who have not yet done the doodle for the next June interim meeting. We want to go ahead and get that planned as soon as we can. Our intention is to have the OpsDir review done and to have all the stuff on the AppMan document pulled into a follow-up revision of the AppMan document that we can do working group last call on and send up to the IESG by Vienna. So this should not be a surprise to anyone. This is kind of, I think, where we landed at the end of Shenzhen. In Vienna, we're going to have a talk about, "Hey, are we done? And do we want to pat ourselves on the back, or do we have additional things that we would like to talk about?" Because if you go to the next slide, one of the things that we will be talking a little bit about today is Martin Duke's draft on—on—SCONE feedback.
I'm still only seeing like eight people here. Maybe we should send a message to the mailing list to let people know that we are indeed meeting today. With all of that to the agenda—oh, goals, yeah, actually I already said all of this. Goals for today's meeting, yep, that's already done. The agenda has one error in it. We have an off-by-one error in the timing in UTC. We will have one hour and not two hours for going through SCONE App/Rel/Manageability. So for 16:05, 16:XX, read 15:XX UTC here. So with that, Sanjay.
Sanjay Mishra: Amir.
Brian Trammell: Do you want to sort of present the GitHub issues and PR lists? Shall we set you up with a screen share, or...
Sanjay Mishra: So, what I did was I summarized in the Google Doc or the PDF that I sent. So if it's easier to talk through the PDF and then we can jump over to GitHub if needed.
Brian Trammell: Yeah.
Sanjay Mishra: Okay, so my name is Sanjay Mishra, and I'm presenting here the updates we have made since the 01 submission, as well as issues on GitHub. And I'm representing my other co-authors. And some of the changes that I've made were kind of on the fly, so we haven't had a full author set to sort of agree on some of the things, so they might have some comments and so I'm definitely open. So let's go to the next slide.
Brian Trammell: Sanjay, you can kindly show your slides by yourself.
Sanjay Mishra: Oh, I can! Yes, thank you. Appreciate it. Thank you, that's easy. So just a quick recap. And I've got like five or six bullets here, but it doesn't do it justice in terms of—it's pretty much a rewrite of the whole document in ways, but just to call out a few things that are important just to make sure that we did some of the comments that were made at IETF 125.
So we have removed requirements type of text from the document and trying to refocus it on as an operational guide. Also a lot of back and forth on clarification, etc. So a couple of things that really stood out is to make sure that we recognize that SCONE advice is stateless, and per-flow state is optional and probably where it belongs is in the conformance monitoring part if there needs to be any state sort of looked at. Also, there were a lot of discussions and questions about SCONE and the other transport congestion signals, so we have attempted to clarify that in the sections. And also, added guidance on addressing if there's no network element on the path or there's a single network element on the data path, or if there are multiple network elements that are SCONE-capable along the path. So what happens and so forth, so we have addressed that as well. And then also added an operational considerations section. And this was done kind of late in the game, just like a couple of days back. So there's one section to start us off and there's other placeholders, so we need to work through that. And Ian Swett, thanks for sharing all of that and some guidance there, so we'll definitely be working on that. And just a quick comment on May 15th—I mean, it is aggressive, but I think we can if we have a good sense on good consensus on merging PRs. And if it is, then I think we can still hit the date and still try to shape up the operational considerations section as well.
Let me move to the next slide. Okay, it's a little bit slower. Let me see if I can make a full screen here for me. Ah, that's so much better. So, I've just listed out all the issues from—in sequential order of the timelines, starting with the issue number 7. And Gorry Fairhurst had a number of comments starting with number 7. And so some of the key things that he was trying to point out is that operators need to think through that there may be other network elements along the path that might also make information that might also influence the or update the SCONE packet. So we kind of recognize that and there's in some ways there's an implicit text to that. And then the other thing, Gorry, you mentioned was you mentioned that we need to address, as I said, no SCONE network element on the path and one or more, so we've done that. And also there was another issue here that there needs to be some description on when a forwarding path changes and what happens then. So what we have done is that we have updated the introduction section and you can look at the PR for all the gory details—pun not intended there. And then also you can look at the additional sections that we've added: "Presence of SCONE Network Elements" and also the "Change of Network Elements During an Active Flow." So between the introduction and those two sections, we've tried to cover all the three points. And there were some other comments that Mirja Kühlewind posted on that, so we've tried to address it.
I'm just going to walk through it, so unless I hear a question, I'll just keep going. All right, so the next is issue number 8, pointing towards Section 3.4 and it's on clarifying words. Although the comment does not say a lot, but it says a lot in the fact that there were a lot of inconsistencies in how we use the text or imprecise or sort of a little bit vague or too broad. So I think when he says "clarify words," it meant a lot, and there was a lot of things that we needed to do. In this particular case, though, the question was very simple: that it was not clear that what we were talking about in terms of CPU overhead. As I said, you know, the language was not as precise. You might be a bit loosey-goosey. Thank you. So yeah, yes, thank you. So we've tried to address that and then also we ended up updating the title of this section. The section was "SCONE Indication to Network Elements." We changed that to, as Mirja suggested, "Considerations of Processing Complexity," because that is kind of what it is addressing really. And some of the text—this is not all the text, but some of the text that we added is in here. And again, you can look at the PR which is out there. And then if you don't agree, or if you have questions or comments, you know, then your comments are absolutely welcome.
All right, I'm going to move on to the next one. Issue number 9, this is on Section 3.5, "How's Retransmission Realized?" Again, a good question that made us think through that, you know, what are we saying and what are we not saying? What should we say and what should we not say? All of those applied. So initially we addressed Gorry's question on to talk about more on the network elements and how the retransmission of SCONE packets is done. And then when we submitted the initial PR, there were a number of great comments that came through on top of that PR. So we did a tweak on top of the PR. Marcus Ihlar had questions on that the language that we had was that the endpoints cannot take into consideration what the CPU—how CPU is on the network element is, you know, how fast it is working and not working. So his point was that endpoints can send as frequently as they see fit, and the network elements make the decision on the update frequency based on considerations such as CPU load, etc. Another point that Marcus had was that networks that have dynamic policies will care much more about the timely updates than a network that has fixed policies, such as subscription-based policies. So the updates may differ basically based on the application. So we try to address those two points from Marcus. And then also, this is going to be throughout the theme: remove all the redundant text from the protocol spec. So we've done that. The initially, just as a defense of why we did that, it was to make sure that whatever we are saying in this draft is aligning with the protocol specification. That's why we were sort of citing some of that. But maybe we went overboard in terms of how much language we used. So we have now gone back to remove all the language that is already mentioned in protocol specification. So PR 29 addresses all of those issues. Again, have a look if you have not. If you have comments, please post.
Moving on to issue number 10. This is on Section 3.6, again clarify what we're saying. Essentially is the point that be very clear in what you're saying, just be state, you know, state that. So there was a bunch of changes we made. One is we noted that the frequency of SCONE signaling is really driven by the application endpoints. And important to note is that how the frequency will change based on ABR video clients that are short—that are fetching short media segments. They may choose to send SCONE packets frequently than the non-ABR applications such as bulk application transfers, software updates, etc., so they may not be as critical in terms of generating SCONE packets. So we've just sort of sort of made a statement there that yes, applications would behave differently and there could be a different sequence and priorities in terms of SCONE packets. So what we've also made sure is that we say that there's a boundary. So SCONE protocol has defined the baseline timers to prevent advice from expiring. And what we've noted is that operators should expect the actual frequency of passing SCONE packets to vary significantly depending on the application type. That's really is the message there.
And I'm going to keep moving on, so issue number 11, Section 3.9: "Please clarify words around compliance." So really, as I said, this theme is the same. Again, questions on precision and explanation was needed to what we were saying. There were several comments. One was initially that we were trying to address Gorry's comment that, can we document and explain what compliance means with respect to SCONE? And then Mirja had some good discussion points that she added onto on top of the PR. So we went back and updated the PR based on some of the language actually she provided, such as using a sliding window and also what to do if a violation is detected. So added those two points in the on top of the PR. And she also had a good point that there may be scenarios where operator decides to do nothing at all and so that wasn't there. So that text has also been added in PR 33. So that's kind of what really and here's the some of the gist of the text. I'm not going to read all of that. As you can see, so that's been updated in PR 33.
I have I think about 20 or 22 slides, so I'm just going to keep on going and unless there's any discussion then I'll stop. This is issue number 12, Section 3.1. Again, clarification, what we meant by "stable." So we have removed that word "stable," by the way, because that wasn't really conveying anything. What we were thinking about stable as in where—like bulk file transfer, etc. So we we removed the word and just gave clear examples of where some of this would apply. On this particular issue, there were other comments as they related to our language of using the word "transport protocols." Magnus Westerlund gave some good wording, so we incorporated his suggestion. And Mirja reminded us that it would be better off talking more in terms of the application use cases. And there were a couple of other things we had said that we're not going to be discussing how operator determines its policies. So there was a question Mirja raised that maybe we should talk about it and it shouldn't be necessarily out of policy—out of scope, I should say. So adjusted that. And then there was also a question about harmonizing the word "harmonizing," so removed all of that. As you can see, if you will look at PR 34, that is again tackling all of those issues, really addressing those points, removing confusing language or choice of words.
Brian Trammell: Uh, so we've got Zaheduzzaman Sarker in the queue. And I actually need to step away for a moment. So Zahed, go ahead.
Zaheduzzaman Sarker: So actually, I'm in I'm on the queue because actually I have a question for the chairs. So I was not sure like I understand how you want to proceed from like I think like Sanjay has slides, shall we just he just present the slides or are we trying to say like when the presentation is done you go to and PR try to see like if you're merged or not or like what's the what's the plan here? Did Brian say he was going to step away for a second or something? Yeah, I think he did. So so I don't know if you if you were at the very beginning of the call. Maybe not because maybe I was not very paying attention. Yes, yes. So so we talked about whether Brian asked me if I wanted to go through the the GitHub or through the issues or so I suggested that you know since I have the the slide deck already created and it's it's addressing all these issues, so I suggested that I walk through all of these issues and if if folks have questions you know we can discuss that. And Brian also said that at the top of the session that the objective is to see we can get to the point where these PRs can be merged. And I see Ian Swett and Brian they're both here, so let me not put words in their mouths.
Zaheduzzaman Sarker: Yeah, so this is this is where I want to be clarified here like okay, how we are going to do that because if you are presenting and we are not discussing the PR there is no reaction. Does it mean like we're going to merge it? Because the issue 12, nobody has anything to say.
Brian Trammell: My assumption is that if we're not getting comments on these on these issues and the PRs as we're going through here, my assumption is we're going to merge.
Zaheduzzaman Sarker: Okay, that's basically I was trying to understand because if that is the case, then when one issue is done, I'm going to merge them. I'm going to maybe you chairs can merge them or somebody can merge them. Yeah, I don't know like if that's the plan, but anyway. Thanks for the...
Brian Trammell: So yeah, so if there's anybody who wants to say a thing on the previous things that we've the previous issues that we've talked about, now would be the time to get in the queue. Hi Mirja.
Mirja Kühlewind: Yeah, I get in the queue because you said we merge right away. Because it feels like we are still in the middle of the discussion. I mean like the PRs are there since a week or two, we provided some comments, there was a revision made in the last one or two days, right? So I didn't review all the changes up to now. I mean the the deadline was a nice deadline but I think we are not ready to merge right away.
Brian Trammell: If there are if there are, how to put it? We're trying very hard to hit a relatively aggressive timeline to get this document for early OpsDir review. So, you know, keeping in mind that like merging a PR does not make that the final language that's going to go into an eventual document that goes up to working group last call, it's just the one that's going to go into the OpsDir review. I would ask people to like consider there be a relatively high bar to say no, no, no, no, this is not mergeable at this time, right? Like so we want to keep this iterative that calling a PR merged into the current rev of the doc is not necessarily going to close that discussion. Does that make sense?
Mirja Kühlewind: I think after merging all these PRs, I mean like I have to look at all the details right, but I think we might not be ready for Ops review because I think what we really need for Ops review is to be sure that we have all the content in we want and in the right structure. And like I can still see that we want to remove some of the content because there was still redundancy with the main spec and I think we should avoid that. And there might still be sections that we want to remove entirely or merge with another section. So I think there are still structural changes that might come up, maybe not like like huge, but I think we need to be sure about that the you know the the rough shape of the content is there before we give it to the Ops review. I mean you can change the wording but not too much the scope.
Brian Trammell: Are there are there particular PRs here that you have a stronger objection to merging?
Mirja Kühlewind: Not the full PR. So as I said, I didn't look at all the latest changes from the last hours or yesterday or whatever. But in all the PRs I think there was part some language here and there that shouldn't go into this document or would need to be adopted a little bit more like unified a little bit more.
Brian Trammell: So I would I would still suggest given that we have the let me do the math, 14 more of these to get through, and that we are like about a third of the way through this review of the doc. Again like I think and we got a bunch of inflight PRs in some issues that are not yet assigned to have a PR on them, and I'd like to get like a human attached to those by the end of this meeting. Would you have an objection to essentially merging anything that isn't like completely wrong and then doing the structural review after those merges?
Mirja Kühlewind: Yeah, I don't think yeah, I think these are fine to merge knowing like but as I said, I think for some of them we are in the middle of discussion, so you know, like it might be make more sense to merge them like in three days than right now. But like in general, these are all fine to merge more or less and then do another pass as long as that is clear. I think like we are not ready to to get this out for external review after these merges.
Brian Trammell: Okay, okay, good. Well I mean like this is why we have like another two weeks to do this, right? So.
Sanjay Mishra: I'll so... Okay, sorry, go ahead. Because I had some something to do with the previous point that we're trying to make.
Zaheduzzaman Sarker: Okay, go ahead. Yeah, I was thinking like the one thing I see like merging the PRs is like I think the procedure I would suggest like we merge the PR if there is not like huge objection, then we have a revision version in the data tracker that people can look into and then also like come and open the open the issues on the on the data tracker version because otherwise it's like lots of things going on. If there is like as Mirja said we're if there's some PRs that we are in the middle of the thing or like some issues that we need to have a more discussion, we can park them, but the things that we can merge, I think we should try to merge them and then go for the data tracker version.
Brian Trammell: So I think one... Go ahead Sanjay.
Sanjay Mishra: Yeah, I think because I did a bulk of work here and I did multiple based on the multiple discussions, there were multiple updates made to the PR on top of the PR. So I think administratively it might be just easy to to do a one pass now, merging all the PRs and generate a document that we have a clean version of the document. Not to say that we agree with the content of the document, but there's PRs have been merged and make sure that sections are are all listed that we have. And then I was planning on and that's in my last slide by the way, I was going to propose that that once we have version 2, we look at it. Authors first of all look at it to make sure that we have truly addressed all the outstanding questions. And and then go back and update those if not. And then also gives everybody a clean slate to look at and and work on it. So that was at least what I was going to put on the table.
Brian Trammell: So I think broadly that makes sense. I think we can continue this sort of like maybe go a little bit faster through through this review of the discussions. I I like Mirja's point that like some of these the discussions died down we can probably just merge them, but if we're in the middle of of detailed discussion in a PR we should maybe hold off on that until that resolves. I'm going to go through in parallel over in GitHub in in this window over here and have a look at which of these look like there might still be discussion to go on versus the ones that I'm pretty sure are mergeable and I'll make a a suggestion when we get to your last slide on this. Does that sound good?
Sanjay Mishra: Yeah and I just I just felt that you know it'll do everybody good if these are merged because it's easier to look at a clean document.
Brian Trammell: Yeah, yeah the idea is—I mean like yes, we're going to do the thing where we merge them all, but the idea is is that for the things where there's for the PRs where there's still inflight discussion we'll say okay, that's going to resolve by Monday-Tuesday, right? We for the things where it's not inflight discussion we go ahead and merge them, for the things with inflight discussion we give it another, you know it's Thursday now, so I'd say Tuesday, um a couple of days to resolve, minus the weekend, then we um merge the remaining ones and and push a new rev. And then we continue the discussion from that new rev. Because I I do think that like when you're in the middle of a discussion on a PR, it does make sense to go ahead and let that resolve so that you don't have to then start that back up. It's a context management thing. Does that make sense to you?
Sanjay Mishra: Yeah, fair enough. I'll take a quick look at these and have like a have a opinion based on how the how the discussion is going. Um, all right. Lucas.
Lucas Pardue: Yeah quickly. Sanjay and um and you and Zahed kind of touched on some things I was just going to say, so getting a a baseline of the merged stuff sounds good, I can look at that. Whether that's just the editors' draft of of all the stuff we merged, like that's fine. Um, and if Brian wants to collect the issues that are still remaining open whatever, all I'd ask is like, can you put that in an email to the list because that'll make it a lot easier to to just refer to and work through as a checklist of of things for people to to look at. And then, um, following on, when we do cut a draft, it sounded like we were saying that the working group would take another quick look over it before we submitted it to an Ops review. Was that right?
Brian Trammell: That's what I've heard from Mirja and Zahed, yes.
Lucas Pardue: Okay that sounds good. Yep, cool, thank you.
Brian Trammell: All right, um, I think this one we covered when Zahed came out, so move on to the next one.
Sanjay Mishra: So this is issue number 14, Section 3.3: "Please consider the interaction with other configured IP mechanisms." So this was one of the the section in the document. Um, number of issues, a couple of them from Gorry on consideration of how SCONE signal interacts with DiffServ and other methods, and also what happens when you use two or more DSCP code points, etc. And then Mirja also pointed out that there were some contradictory statements in that section as we had it. So the PR 27 addresses those and I I don't see anything outstanding there. Um, so I would say that those the at least the the three key points that I've listed are in the PR 27. And oh actually, and one other thing is that at the end of it what we also came out with was that there was a QoS awareness section, so I have put that on Mirja had suggested that maybe we just don't need that. So I have not removed that, but I do plan to remove the QoS awareness section. Um, but I I do want to see my other co-authors also make sure that they agree with it before we do that. Um, and maybe in focus on so the so the one is remove that QoS awareness all together and then maybe the the section that we now have "Determining Throughput Constraints" as part of the operational guidance maybe any language that needs to go there can belong to that particular section. I don't know if I was rambling or if I was clear but that QoS awareness goes out and the new section comes in which is called titled "Determining Throughput Constraints."
All right, um moving on to next one, issue 15. This is sort of tied to the previous one we looked at again to clarify any relationship with the ECN. Um, so Gorry had suggested to include some explanation on so talking through if there's any anything that ties back. So we have again clarified that in PR 34. Um, and there were also some comments from Magnus and Mirja that are addressed in PR 34.
Moving on to issue number 16, says "Add discussions about the relation of SCONE with L4S." It's sort of again similar to what we just talked about in the previous section. Um, also Mirja had some some suggestion that the what we talk about is congestion control and also mention L4S. So, you know, talk about congestion control in general and L4S. Um, so more text on that would be good. So so the same as the last one, same PR continues in this same section that talks about ECN, L4S, etc., and provides the clarifying language. But obviously more eyes are always good, so have a look at 34 and see if it if it's really answering the questions that have been raised in the in GitHub.
Okay and then moving on, issue number 17, to discuss network deployment use cases with or without throttling fallback. So and then the issue was that in Section 3.9 we should talk more about how to do compliance measurements, and sliding use of sliding window and what to do if the violation is detected. So all of that I think we have that in the PR 34. Compliance monitoring includes some verbiage on sliding window and that we took directly from what Mirja had suggested into the text.
All right, um issue number 18. So we had these two sections previously in 01, "Flow Session Awareness" and "Per Flow Signaling." So we we basically removed those sections and and created a new section based on the feedback and the new section is simply titled "Flow Awareness and Per Flow Signaling" in PR 27. So again have a look and just see if this is really answering the questions that you have, Mirja, in terms of the difference between the two. So I mean that's a moot point because we actually have don't have those two sections but really one unifying text with clarity on what we meant by quick flows, and also added language on stateless signaling so that network does not has any state and it just sees a packet and it provides value in there as it need if it needs to. So have a look at PR 27. Mirja.
Mirja Kühlewind: Yeah, I mean actually now I lost track a little bit here. Um, so maybe you can actually submit an interim version where you remove the bit that we decided to remove and then we can work on another version where we add the new stuff. Um, that would help me a little bit to track that down.
Sanjay Mishra: Right, which is why I was suggesting that it just be easier um to look at because things have been deleted, new things added, everything's being reworded. Um, so yeah, in in here the these two sections are removed, the 3.1 Flow Session Awareness and the 3.2 Per Flow Signaling, both of those sections have been already removed.
Mirja Kühlewind: Yeah, what I was proposing was that like things we remove, that's an easy change. I mean as long as we have consensus, but the change is easy to see. And then also maybe smaller PRs where it's straightforward, small text changes or whatever, just submit those together as an interim draft version and then the parts the PRs where we have a lot new text and discussion ongoing we just like keep them for another draft version, hopefully soon as well.
Sanjay Mishra: Um, don't trust me with making the decision because um I guess I I could. Um, like in this case the these two sections have been removed and the new section has been added, so this one I think is easier to just you know accept that PR I guess um in the interim version as you said.
Brian Trammell: Has PR 27 been updated to effect that removal? Like there's an agreement on a removal in the PR 27 discussion, but has the PR been changed to effect that removal?
Sanjay Mishra: So the I've submitted the PR, so the the PR has removes the two sections and creates a new section, so all of that is in one PR 27. So it it removes and it adds, it does both.
Brian Trammell: Okay, so the suggestion is to keep the removals but do the add later.
Mirja Kühlewind: I'm not sure, I'm looking at PR 27 now and it doesn't look—no.
Brian Trammell: It also doesn't look like it's it's got... All right, so I have that one noted as it needs additional additional discussion.
Sanjay Mishra: Make sure that you're looking at the latest one because as I said I also did additions on one on top of the other, so but I'll I made a note also I'll just make sure I check that out.
Brian Trammell: I'm only seeing one commit in that PR, so.
Sanjay Mishra: Okay.
Brian Trammell: All right, we we'll need to re-review that one, good.
Sanjay Mishra: Got it. All right, so Section 19, issue 19, Section 3.4. This is the QoS awareness and we had lot of discussions that I've and I've just captured couple of those here. So the this is the section that we Mirja had suggested that just take that out. Um, after a lot of discussions, you know, that was the bottom line, so um I had agreed that yes, this can come out but I have not actually done the removal. So this is the one that I I actually need to remove it and I can submit a PR for that.
Mirja Kühlewind: Yes, a PR would be helpful, thank you.
Sanjay Mishra: Yeah. Okay, um this you brought up a good point that we should talk something about MASQUE proxy, um and you have a a PR that you have proposed. Um, and I know Zahed had had some comments, so I I would like um you know others to look at it. You know I I posted a comment I was okay with it in terms of the the context so that is fine. Um, there may be some editorial type of you know things and making sure that the declaration block is all correct, so it needs just that declaration part needs a little bit of fixing. Um, and I don't know Zahed if you have had a chance to look at the actual PR um which Mirja submitted after the discussions.
Zaheduzzaman Sarker: Yeah I had a look at it, but my question was like what I I wanted to discuss for us today or like in the subsequent meetings is like whether we need to do anything there, and what's the minimum we can do because um for me, I mean as I explained in my comment like I see there's a no way you can screw things up, but but I think Mirja's text looks okay, but do we need to say all those things or like do we need to say at all anything? That's basically my question. I think if we say that, yeah, we need to do something there, then we can start working on Mirja's text to make it happen. But I was not sure like whether we need to do anything.
Mirja Kühlewind: Yeah so we had a little bit of a discussion at the last meeting about MASQUE and I do get this question about like, can you use SCONE with MASQUE or whatever, so that's why I wrote it down. But I I definitely think um it would be nice to get more review of the text and if we can keep it very brief or if we argue we don't need it, that's fine as well. Um, as I said like I do get this question so it might be useful. And I want to name Lucas here because he also had some comments about this, so maybe if he can review that would be really useful.
Zaheduzzaman Sarker: Yeah, Mirja I also do get the question, and that's why perhaps I'm also trying to see like whether this working group would like to work on something that combines SCONE and MASQUE, and that's I'm full on with with that. But what I was thinking like, well we have not really put SCONE and MASQUE anywhere, now we are trying to do like there was some discussion to put something in the one text in the SCONE document, MASQUE document, SCONE document about MASQUE perhaps or like something else, I don't know. Oh now, that's the spin bit thing. Um, but yeah, I mean that's why I was a bit like cautious here like, do we need to do that in this AppMan document? There is no kind of like kind of indication from the working group on that one, and if we really would like to have a complete solution maybe we need to work on a different different draft. I think we have a draft on that one how to work with MASQUE and SCONE. Um, but I don't really see much of an issue with the tunneling thing, so that's why I'm asking the question like whether we should do anything about it. But I completely agree with you like some day we need to work on this one um and and we need to basically what the working group here could decide like whether MASQUE is an special network element that we need to cover and in that question how many more network elements we need to cover. So I think those those are the things that SCONE working group can decide on and give us a guidance.
Mirja Kühlewind: Yeah, let me just quickly um add on this one. So while the section says MASQUE, the first paragraph is actually general about tunneling. Um, the the second part of the of the section is about MASQUE specific because MASQUE is using QUICK as well. So that raises because SCONE is on QUICK and MASQUE is on on QUICK, it raises the question: can I use SCONE in my tunnel connection, which is only true for MASQUE and not for any other tunnels.
Christian Huitema: Yeah I mean on this specific point, I mean this reminds me a lot of the discussion about ECN and tunneling which have been going on for a long time and I I really believe they do not belong in this specific working group. I mean if if we have to do something, my best advice would be to publish SCONE quickly and then makes it the problem of people specifying tunnels to say what they want to do. And in any case it doesn't belong in the AppMan document, it's something else entirely.
Lucas Pardue: Um yeah to add I think um although I I have some visions of of MASQUE being relevant in general, for this document I wonder if it's more relevant to consider just a network element that may do UDP encapsulation. And if if there's anything we could say about it in that sense. Um and but to Christian's point, maybe the whole thing is that we explicitly avoid saying anything, um but we don't do it via omission of just not saying anything. We say there there would be potentially, you know, AppMan considerations for this aspect of the protocol, but that they're out of scope for this specific document, which would leave the door open to somebody else doing some work in the future knowing that if you are deploying anything that's doing encapsulation tunneling things, there are there's something to be aware of but we don't have any answer right now and this is kind of an open question. Maybe just capturing that would be sufficient here um and leave us in a good place.
Zaheduzzaman Sarker: Yeah Lucas thanks um for saying that because I was actually trying to say similar thing, saying like maybe we can just warn the case like hey, if you are doing tunneling you need to think. Um but if we cannot say what you need to think, that would be an incomplete um thing to write and to agree on like what to write on it. And because I mean the thing here is like we definitely talked about with in the beginning of the AppMan document, we talked about what happens to the tunnel, what do we do with the tunneling and this has been there, but I don't I have not seen like any particular viewpoint on that one. Mirja has one as I say, but that's pretty MASQUE specific. Um so the again the question is like whether we tell MASQUE is an special network element that use QUICK and that can also have SCONE and then this is how you work, we can capture that one or we can capture a kind of generic discussion or like like like this behavior of these things in a in a shorter or more generic network tunneling UDP tunneling kind of scenario. That would be good if you if somebody has some opinion, strong opinion and somebody has some text on that, that would be good because it's very hard at least for me to come up with some good text that we can agree on.
Mirja Kühlewind: Um yes, so I think actually so the reason why it makes maybe sense to have it in this document is because it this document is addressed at people who want to deploy SCONE from the network side. So I'm a network operator who wants to put a SCONE endpoint and I may want to put this at the same place, and I also want to, you know, operate a MASQUE tunnel and so what are the dependencies here. So that was the the thinking behind this. Sure, you can also separate that out, but um in order to address Christian's comment, I don't think that things are that complicated as tunneling in general. Um and also to address other people's point, the part where it becomes complicated there's actually no detailed guidance here just mentions that you have to consider that. So um in in to be more clear, you can read the the PR yourself, but there's three things the PR is trying to say. One is um if you are operating a MASQUE proxy and you want to also provide SCONE advice for the inner traffic, you can do this at at ingress, no problem, just do it. Um so that's the easy case. If you want to use SCONE on your tunnel outside, then there are two cases. One is that the other end the the MASQUE client is also kind of the endpoint, and then you must have to make sure that like the outer SCONE signal can be also somehow provided with an interface to the inner one so it actually reaches the application. You know, that's also straightforward. And the third part is which is like in in lot of MASQUE cases right the client is the endpoint, but like if you actually have this as a real tunnel where you have an egress and something happens behind that, then what it says is basically if you if you use SCONE, you either have to react to SCONE yourself or you have to also somehow transmit this and this means your egress might need to act as a SCONE network device and then you have to figure out some policy in how to set this actually correctly, and it doesn't say more than that. So that's the scope we have in the PR right now.
Christian Huitema: Uh, Mirja, I think what you said is actually a great reason why we should say nothing and be generic. because um MASQUE, you can't speak of MASQUE in isolation. Uh are you speaking of MASQUE UDP tunneling? Are you speaking of MASQUE QUICK-aware UDP tunneling? Uh are you speaking of IP tunneling? Are you speaking of Ethernet tunneling? All there MASQUE is is a framework with a lot of applications. So, I think it's really better that if we do anything like that we do that inside the MASQUE working group.
Mirja Kühlewind: Yeah, I mean I I didn't want to make this too complicated. The reason why this is talking about MASQUE specifically and in this case it doesn't matter what's inside, it's really just because MASQUE is the only tunnel protocol that can use QUICK on the outside and you can only use SCONE together with QUICK, right? So you cannot use SCONE for other tunnels.
Christian Huitema: You don't know that. You don't know that. No no, but I'm just saying it is the only specified protocol. I am aware of people for example using QUICK as a side channel for Wireguard.
Mirja Kühlewind: Okay, so it yeah. But I mean so so I mean MASQUE uses QUICK and so you can use it with SCONE, so it doesn't have to be the only one. But it's like I mean the the point where like you also need to figure out what's inside, you know, that's the part where it gets complicated but I'm not I'm just saying like this is your problem you have to consider it, I'm not giving guidance here.
Christian Huitema: But yeah but this is basically what Lucas said. But we we should really not I mean the AppMan document is downstream from the specs. I mean it's basic it's based on the specs, it's kind of explaining the point making the fine points for operators that the spec document doesn't make. Uh that is way too far. I mean that's like I I would keep it simple.
Mirja Kühlewind: Yeah I mean this is fine like if you if you want to say anything in this space then please comment on the PR and make text proposals, or if we decide we don't want any of this that's fine for me as well, we just need to have a discussion.
Brian Trammell: So I will I'm going to go ahead looking at the clock, I'm going to go ahead and um put my chair hat on, it's over there somewhere. Um and point out that I do think that sort of like the wider discussion around MASQUE, SCONE um and the generalized interactions of SCONE with tunnels is something that we do want to get into more depth in the Vienna meeting. Um so like any discussion here that doesn't end up going into AppMan I think we want to we want to table and bring to a a an in-person discussion in Vienna. I have marked this PR as needing maybe a little bit more discussion or closure before it's mergeable. Sanjay, you want to keep going? We have 12 minutes and I'd like three at the end to point out what I've the sort of the what I think we're going to do next steps. So speed on through and people please do like if you have like serious issues with these please raise them here, otherwise we'll do the post-review after the next rev of the doc. Thank you.
Sanjay Mishra: All right, so issue 21, "Explain how throughput constraints are determined." Good point, good question, issue. In follow-up questions there are: do you measure actual bit rate per flow, do you observe its local radio, etc., subscription-based policy. So suggestion was that add the operational considerations section um and and have have text in there. So yes, totally agree with that. So we've started a new section, "Operational Considerations," and then there's a subsection added um which is called titled "Determining Throughput Constraints." And it has it explains it has those four sub-subsections underneath it: "Subscriber Policies and Data Planes," "Application-Specific Policies," "Changes Due to Dynamic Network Conditions," and "Changes Due to Capacity and Load Management." So it sort of tries to address that. Um there are other finer points we probably need to talk about it in terms of performance management and other things, so um this is the section that we need to grow a little bit more. Um but that's that's what we are starting to work on that operational considerations section. If you have things to so if you have things to want to add, that's the PR that you want to go to and add to it, or if you have questions of course. And then number 22 is asking to explain throttling policy and impact of throttling.
Brian Trammell: Go ahead. Zahed, did you have one on the previous one or around 22?
Zaheduzzaman Sarker: The previous one.
Brian Trammell: Okay. Go ahead.
Zaheduzzaman Sarker: Yeah here I'm a bit like not really sure what we're doing. So the thing is like how do how the throughput constraints are determined is completely network operator specific. We can list the thousands of way perhaps to do that. And I am not sure like we should give I mean I don't think like people can capture all the things that network operators do, and whatever we we say here might be not valid for another operator or like maybe many operators. So I'm not even sure like we need to do anything. I think like we can just say like hey this this could be couple of things for example but no further discussion perhaps. So I don't know, I'm not sure like this chapter is needed at all and there are four sub-chapters, there could be hundred more.
Brian Trammell: Following discussion and guidance from our from our AD, um especially for setting this up for an OpsDir review, um we would rather have the Operations Directorate tell us that we don't need this chapter than to not have it before um before sending it up for OpsDir review.
Zaheduzzaman Sarker: But how do we determine like we have enough options sub-chapters there?
Brian Trammell: Uh, I expect that we will get some feedback from the OpsDir review.
Zaheduzzaman Sarker: Okay, so we're going to work on it.
Brian Trammell: Yes.
Zaheduzzaman Sarker: And then we say and they say like hey these are not correct thing to do and then we scrap it.
Brian Trammell: Right.
Zaheduzzaman Sarker: Okay, but can we do not can we not like ask them whether without really spending so many cycles on it?
Brian Trammell: Uh, I mean I think we have a PR that's almost ready, almost ready.
Zaheduzzaman Sarker: That's fine, I mean if if the working group wants to do that that's fine, it's just like for me I don't think like we can satisfy people. But maybe I'm wrong, I'm fine.
Brian Trammell: I think there is like so I've taken a quick look at this as part of my like scrub to to see whether this was mergeable or not, um and I don't have a verdict for whether it's mergeable or not but um I do think this is probably a case of of like the whole document is kind of operational considerations, right? Um and you probably want to have a little bit of language there pointing that out. Um the...
Mirja Kühlewind: So can I just quickly make a couple of points. So this PR was created two days ago, I didn't have time to review it. So maybe there's not discussion because nobody reviewed it yet. So I don't think it's ready to merge. Further, as you just said, the whole document is about operational considerations. So I don't think we need to call a section. So the subsections might be useful but like I'm not sure why it's structured in this way. But again I still need to review it in detail. Um and then the third point is if you if you go for the Ops review, the Ops Directorate, they actually have a checklist of things that they look for, like for example do you have configuration Ops and whatever and so on, and I don't think a lot of these things apply here. So they what they think about operational considerations is not exactly what we're talking about here. Um if you want to address that, you have to look at their guidance document and go through it one by one but I'm not sure that is actually the most useful thing here to do.
Sanjay Mishra: I see Dan on the list here.
Dan Druta: Yeah, thank you. Thank you for bringing this one up. I honestly agree with Zahed on the part about, you know, the different the different constraints that is not necessary and maybe more than those four. But I do believe that you need we need to be able to have a way to explain how the throughput is measured because early in the process I put together a draft on the video session data rate, basically allowing both the endpoints and the network to compare apples to apples and and make sure that what's what's actually measured by the application is consistently being measured by the by the by the operator for conformance. So I do think that there's a need for explanation on on how the measurements are being performed because this way, you know, it's actually clear on all parties. But the part about the constraints taxonomy, I think that's more use cases unless they bring specific measurement details that are unique to these use cases. I don't I don't know if those sections are required. Um but I do believe the explanation on the measurement to be consistent between applications and the network is necessary. Thank you.
Zaheduzzaman Sarker: Yeah me again. I think as like we're saying like the whole thing is operational operational considerations and the whole document, and I do agree with Mirja. I mean there is a checklist from Operations Directorate of Ops and then we we don't really satisfy all of them. I don't know if we need to satisfy all of them but we don't. But the whole document um is an operation considerations. And but there are other things that I'm I'm really afraid that we need to go into. Say like subscriber plan and policy. The moment you start describing those kind of data plan, you need to go into nitty-gritty details of 3GPP network perhaps or like Wi-Fi network perhaps or like BBF, you need to bring on them on like them all these different kind of access. How do we do that? because people will come back, hey I don't understand what is P-Gateway. Uh I cannot really review this anything. This is 3GPP or not. Or like the DBF does something that I don't understand. So it would be problematic on that one. And then also what we are doing here. I think as I said like the text, whatever, I mean people can come back and review and they can always have a disagreement with like how they do things in the network. Um and I'm saying that because I work with operators, my operators, my customers that they are things doing things differently. I have different customers doing applying the same data plan in different way. I have 3GPP colleagues or like other fora colleagues, BBF colleagues, they measure the throughput in a different way on a aggregate per-flow or per-pair basis. So do we want that explained to be explained? I think I don't think so. So I think like the only the issue could be just close saying like hey the only thing that we can specify here is like yeah, we are talk whatever you do, however you determine the throughput, this is per-flow. You apply it per-flow. That's it from the SCONE point of view. And the on the Dan's point like what's the mon like what is how do you measure this one, I think what Dan is asking for is monitoring period because that's already covered in the SCONE specification, so I don't need to we don't need to write it again here. So I don't see like we need to do anything. So and I'm pretty strong about it, I'm gonna I'll be talking about it because I don't I don't like this section, I don't like these things at all. Thank you. I don't like because I don't have I don't agree. I cannot agree with this like what we are writing there, that's the point. But if the working group wants to do that, please go ahead.
Brian Trammell: I I think I'm being a bit slow, so apologies if I'm asking something that was already covered. Like we're sending something to the OpsDir for an early review. Are we sending the SCONE protocol document in addition to AppMan because just reviewing AppMan on its own isn't like they're not going to have enough context about what we're saying. Um and so if we're going to send both documents, it would seem more correct to me to have an operational consideration section in the SCONE protocol section that maybe captures some of this, I don't know, but that otherwise just points to AppMan and says a lot of this stuff is covered in another document and we're going to be kind of publishing them together anyway at the end um and other things we don't know. That kind of seems more natural to me, but maybe I'm in the rough there.
Sanjay Mishra: My comment to Zahed, Zahed you said you don't want to bring in any considerations related to subscription or packet core elements. So I think I wonder how an implementer will implement SCONE let's say, you know, someone working in 3GPP access or Wi-Fi access, they wants to develop SCONE, how would how do you think they'll develop it without we talking about that. So on your larger comment IETF specs, you know the we have many examples where we talk about packet core architectures, right? How IPv6 is deployed in, you know, 5G system. These are informational specs. In informational specs, we can absolutely bring in those considerations.
Brian Trammell: So I'm sorry we are out of time for this situation or for this discussion. I have locked the queue. Please take remaining discussion to the list. I think with respect to applicability to specific um considerations three like so for example Wi-Fi, um I think we do want to have um some discussion in Vienna about potentially adopting additional documents in that space. Um so I think where we should go from here, sorry Sanjay, I'm going to cut you off over the remaining eight slides. I think there's still discussion on all of those in the in the in GitHub. Um I counted one, two, three, four, five, six, seven of the current PRs are seven of the current PRs are mergeable, right? Like it looks like so the the there was discussion and that has um that has resolved um or or there was no discussion and it's a week old, right? Like so okay fine, it's good let's just do it. Um there are other ones that I've marked with comments as like please resolve the discussion and um um and then merge. So I would ask um the editors of AppMan to go ahead merge the mergeable ones now, um merge the additional ones. Um I'll have another look at this on Tuesday um in GitHub. We can just follow up offline. Um try to get those those discussions to resolve at least to the point where we have language that we can merge and then like Tuesday, Wednesday submit a new rev. Um and then we can continue discussion um on GitHub and on the mailing list for those. Um the one question I have is that since we have like sequential PRs you know starting from Section 1 and on, so is that going to be a problem if I go ahead as an example accept something in Section 6 and then go back and accept 5 and then 4?
Sanjay Mishra: No the I mean GitHub GitHub handles that as long as your PRs aren't conflicting with each other over the um like over the same text. Um and it looks like the structure of these is not such that there's conflicts over the same text. Like you should just be able to click, click, click, click and then no merge conflicts. If there are merge conflicts you'll have to like GitHub has a merge conflict editor you can use to to resolve merge conflicts.
Mirja Kühlewind: I know you locked the queue but I really want to disagree here. So like there are at least two issues that I saw that you flagged that where the discussion is ongoing, just because there wasn't a comment for a week, for one week, right? Doesn't mean the discussion has ended. So I think like being overly fast here is also very confusing because as soon as you merge it the discussion is gone and we are somewhere lost.
Brian Trammell: If you have disagreements with those, please note that in the GitHub um in the GitHub PR. Have you done so?
Mirja Kühlewind: Yes, just now. I mean like we are very interactive here, right?
Brian Trammell: Yes, yeah, exactly. I do also think that like the next time that we do this so for the second AppMan interim because it's looking like we're probably going to be getting into the document, I probably do want to move toward the way that we've done the previous interims where we're actually um live editing the um the GitHub queue and looking at the GitHub queue um as opposed to like discussion on slides and then GitHub in the background, right? Because it it makes it a lot easier to synchronize um what's going on. Um and I can I can drive that next time, it's fine. Um okay so there which ones did you want to block, Mirja?
Mirja Kühlewind: Do we still have Mirja? Yes, I just tried to find the button. Okay. There was one about retransmissions and there was another one, but I commented on them so I don't I lost track, too many.
Brian Trammell: Okay. Okay, so have a look at the comments, merge the ones that don't have comments and then like try to try to get the other like I still do very much want to get these resolved as soon as possible uh so that we can um push a clean doc next week. Is is that something that we think we can do?
Mirja Kühlewind: So what's the urgency here for next week?
Brian Trammell: Uh I'm trying to get this document ready so that we can get something that we believe in up for early OpsDir reviews so that we can pull that back and make the changes by a second um AppMan interim in June so that we can have this done for Vienna and then move on to other um move on to other topics in Vienna.
Sanjay Mishra: And I think merging is not going to end the process here right? It's I think the the thing is there are so many PRs it just behooves upon us to have a have a clean document to look at and then make sure that we have we have closed out all the comments that were still outstanding um and rework the text. I mean it's it's so much easier.
Brian Trammell: I kind of do get Mirja's comment on though like when the when the conversation is ongoing in the GitHub PR then basically merging that PR kind of closes that conversation and then you have to restart the context, right? So uh like I would uh I kind of agree with both of you here. Um uh like I'd like to get I really do want to have a clean document sooner rather than later um but this is fine. Can we can we try to drive the open discussions to closure by like middle of next week?
Mirja Kühlewind: I think your timeline isn't realistic. I mean as much as I understand your timeline, but you have to give the um OpsDir probably four to six weeks to do the review. And so your timeline isn't realistic anyway, right?
Brian Trammell: Wow. Okay, well then then we need to go even faster. You're agreeing for going faster.
Mirja Kühlewind: No let's do it right, that's the point. Because like getting an OpsDir review I mean even if we push if we push some PRs now, it's not the version that we can send to the OpsDir, right? Like let's get it right and then make sure that...
Brian Trammell: So so from what I understand from having reviewed these relatively quickly and listening to the discussion that we've had here today, uh a lot of the questions that I'm seeing on these PRs aren't actually on the PRs, they're on the structure and the scope of the document. And for those I really do want to have the PRs merged in together so that we have a single document that we can talk about the structure and scope of. Does that make sense? Like I see a couple of discussions where the discussions are so definitely ongoing about the details, but I do think we want a checkpoint that we can have a structural discussion about.
Mirja Kühlewind: So I think I mean not sure you asked me but like what I what I would like to see is rather not like pushing any huge amount of text that we then just remove a week later again. I would rather like to see a document where we have all the text that we agree to as a starting point and keep the other ones in the discussion, merge them when they are ready.
Brian Trammell: Can you all please work this out on the threads in the PR and come up with something that is that is submittable by the end of next week, where there might be open PRs beyond that submission. Hearing nothing I will take that as the plan of record. Thank you very much. Uh thanks a lot for organizing this, Sanjay. Um we will drive forward and try to uh get something submittable soon. Um but this does this make sense like we basically the things that we are still discussing we continue discussing but we get like everything that everything that we can resolve by next week we get resolved, merged and we might have open PRs for continued discussion. Does that can we do that?
Sanjay Mishra: I'm okay with it.
Brian Trammell: Cool. All right thanks very much. Uh Martin Duke, take it away.
Martin Duke: Are you going to put up my slides? They could be controlled... I'm going to try to put up your slides, just a second, hold on.
[Martin Duke presents SCONE-ECHO v2: https://datatracker.ietf.org/meeting/interim-2026-scone-01/materials/slides-interim-2026-scone-01-sessa-scone-echo-v2-00]
Martin Duke: All right, I submitted this um gosh it was a week a week and a half ago, uh it got pretty good response. I mean one person or a couple people said this is really great we should do this and a bunch of other people dove into details which at least indicates interest if not approval. Uh do I have control? I do, great, thanks.
This will be brief. I'm going to run through this, it's as you can see it's six slides, I'm going to run through this very quickly then you guys can shoot at it unless you have an absolutely huge burning um clarifying question. The concept here is pretty simple, it's just doing the feedback at the QUICK layer. So, um the SCONE sender sends a SCONE packet with a valid QUICK packet, uh the receiver then uh once validating that it is that it is a decryptable QUICK packet will then compose a SCONE echo frame that basically just has the seven bits of throughput advice and sends it back at the QUICK layer to the sender. Um there's a packet number, that's a detail, it can go away, people hate it, it's not the level of detail we need to get into today.
Okay so why would I want to do this? Well to do SCONE as we have um in the in the current spec you you really need full support. Uh obviously the QUICK layer needs support to process the packet, uh the application needs the support to you know do something with the with the bandwidth advice and if there's stuff between QUICK and the application i.e. JavaScript etc., um that all has to be there too. Um those APIs need to be piped through. So there you know in any case where so in the left there everything's green which means there's support everywhere, uh you I don't think it's hard to imagine situations where um not all that is present. Um I know at YouTube we we often send content to third-party apps which we obviously do not control, um it would be great to be able to do some sort of SCONE process with that as well. Um, uh in principle like I mean you have you have browsers that are based on the Chrome networking stack, um, uh in general as I understand it, that is far from my area of expertise, in general they propagate JavaScript APIs through, but they might choose not to and the um, you know getting JavaScript APIs for for SCONE is going to be a bit of a process on its own. The the other point I'll make here is that um we have a pretty narrow waist at QUICK if we're trying to just make SCONE as as as widespread as possible. Uh QUICK client implementations are kind of a narrow waist, with apologies to my many friends in the QUICK implementer community on the client side at least there're probably four QUICK implementations that at scale, the one that that you don't see here is is Meta, which of course is usually pretty tightly mated to their application. Um so if we can get just a small number of people on board we can have a large population of SCONE receivers out there.
Okay, so the higher order bit on like should we do this is of course privacy. And to be honest, like I have a lot of trouble reasoning about this, at least relative to um relative to uh the sort of vanilla SCONE. Um there's a there's a qualitative there's a quantitative matter here where like SCONE has certain privacy properties and this is more SCONE and so it's that squared. Uh again this is I have trouble reasoning about this like on the one hand if there's more SCONE there's less of a fingerprint for clients, on the other hand uh you senders get the literal uh on-the-wire bandwidth advice instead of something filtered so maybe that's more of a fingerprint. Um is it qualitatively different? I'm not 100% sure. A couple things that that have come up that maybe are true. One is uh you know in a perfect world for anything like this that has privacy implications we would have informed user consent. I personally am a little skeptical that all these apps are necessarily going to do a great job of that. However, when we're pushing it into a the OS default um we're even further from informed user consent. So that is that is a consideration. Um another one is uh there is this seven bits of feedback that you get that's not filtered through the receiving application at all. Does that provide some more fingerprinting? Um if an application is getting the data and doing something maybe it's doing a new HTTP GET request, maybe it's doing something with flow control credit, whereas this is a a very precise signal of what the bandwidth advice is that the sender wouldn't receive. I think Lucas Pardue, who's not on the call anymore, made a point that you could build like a network scanner, right? Where if I have a server if say say we're incredibly successful and all the major client QUICK implementations support SCONE echo by default, then um a server if a server can get clients to connect to that you can build a pretty good map of bandwidth advice through the through the internet. Now every researcher in the audience just thought of two papers they could do, um but is that a good thing or is that a bad thing or is it a neutral thing? Uh it's hard for me to say.
There's a medium order bit that is probably low level we need to get on like on the do we want to pursue this argument or not, uh and that is coexistence with SCONE. What is in the draft today is what you see there in the big the big letters, which is "If your application can do SCONE, do SCONE. Don't do SCONE echo." Uh SCONE echo is potentially more verbose uh in that it sends um almost every SCONE packet has a one-to-one relationship with a SCONE echo frame, which I gather is not what is going to happen elsewhere. And secondly, uh I think a lot of use cases of SCONE involve a receiver-driven response, and for it to go to the sender and then ping-pong back to the receiver is kind of silly. So let's do SCONE if we can do SCONE. Um now like how to manage this coexistence is covered in the draft unfortunately sort of complicated dance of transport parameters. Um uh you could read that and I think it's not that hard to follow but maybe the reasoning's hard to understand. Section 6 of the draft talks about um how it probably relates to what likely application APIs are. But the the high-level the high-level concept here is that we are trying the transport parameter rules are designed to create the outcome where a receiver that can do a receiver that has an application that can do SCONE at the app layer is going to do that. If it can't do that it'll default the QUICK layer will default to sending SCONE echo. We could do other design I'm not married to that. There are other design choices that are possible. We could have it where SCONE echo is preferred, we could have it where you send it to the app and you do send SCONE echo. That sounds kind of confusing to me, but um uh that's you know again I'm open the discussion in the group. And that's really all I had to say, like do people how do people feel about this? Uh I read the charter it wasn't really frankly clear to me if we need to recharter to do this uh regardless um uh you know before even asking if we want to do the charter do you want to pursue this work or not, and I'm happy to take your questions and comments.
Brian Trammell: I think we got like uh loose five minutes for questions, comments, praise, antipraise. Go ahead Zahed.
Zaheduzzaman Sarker: Yeah I'm really sorry but I have not read the whole draft very carefully.
Martin Duke: How dare you.
Zaheduzzaman Sarker: So so but I think I think this is something that we can discuss, I mean is whether we need to adopt it right now I'm not sure, but yeah I mean there are some privacy concerns raised by Lucas I guess, I think this looks sound. Um we do talk oh I mean is there any way to the network elements who is like setting the sending the advice actually get an idea on from the application that would be even nicer perhaps but I was like you said that you have a edge use cases. But I was do you have any details on the use cases like what you want to really do with this with this echo thing?
Martin Duke: Well uh this is motivated by YouTube of course. I imagine it's not just a YouTube thing but uh to take some examples um as I said YouTube does deliver its content to third-party apps which we obviously do not control, and it would be great to apply SCONE bandwidth advice to that. Um we anticipate a pretty long lead time to having it piped up all the way through JavaScript apps even in Chrome, to say nothing of other browsers and you know when running YouTube in the browser we would like that to um uh to that to work sooner rather than later. And then fine and the other rollout thing is you know um there are other Google apps besides YouTube of course and none of them right now are super excited about SCONE but maybe they would be, and it takes a long time to update clients out there in the world, right? So to be able to have something work um immediately uh at scale for experimentation would be great rather than having to roll out an app and having it just slowly percolate through through the system.
Zaheduzzaman Sarker: Oh so so the the rolling out app thing is tough but how do you add a new QUICK frame without rolling out the app?
Martin Duke: Well... Well no so well so okay we probably have to we can take this offline Zahed but very briefly the idea here is that if this is successful then then the client QUICK implementations implement this by default. And so in the future when when I don't know Google Maps decides they really need SCONE, then there's a much lower barrier to entry for them than there would be otherwise. And over time they can roll out an app that supports this. All right I I'm going to have to move on, we can take this offline Zahed. Christian Huitema.
Christian Huitema: Yeah, my main concern with your document, Martin, is that we discussed that like last year when we started SCONE, and we decided explicitly to not do it. So it's basically reversing a a design decision that was made just a year ago. So we have to understand what changed. Uh I am not convinced by your example of the YouTube client because the YouTube client might well be SCONE aware if they want to main- like one of the classic deployment of SCONE is that the client receives the SCONE advice and uses that directly to select what kind of video it asks for and what kind of compression. and there is no need to do that at the server. So so we had all those design decisions that were made a year ago, so they have to we have to balance that with this new draft.
Martin Duke: That's fair. Uh I didn't participate in that discussion, uh I'll be sure to go back and take a look at it. Thanks Christian. Ian.
Ian Swett: Yes I appreciate your point Christian and um I I think I need to relook at that discussion as well. Um I mean in the case of YouTube it's actually more useful in the server side than the client side, but actually both sides actually want that information um and so if we only give it to the client it basically has to just echo it to the server in some new metadata, which actually for YouTube is quite a doable thing because YouTube is vertically integrated, but like um the JavaScript API thing is actually a bit of a adoption hurdle. Um I mean I think one thing to think here is like I think there's three possible options here. One is like we don't like this at all, but the um and one is like we want to actually make it like an RFC someday, and another is maybe this is a draft that sits around and eases adoption of SCONE and then a year from now or two years from now we decide whether we want to actually make it an RFC or just use it as a like you know a a stepping stone to get more SCONE adoption in the interim before let's say browser APIs become available and all those things. So I don't I think in my mind this doesn't have to be a like yes or no thing, it can be a you know this is how we get SCONE adopted widely. Thanks.
Brian Trammell: Ian I'm the champion of of drafts that sit around, so yeah sounds great. Mirja.
Mirja Kühlewind: Yes so I'm not necessarily against this draft, but I mean I I do disagree that SCONE needs to be adopted widely in the sense that I don't think it's equally valuable for all kind of applications. It's most valuable in a case of video for example where you can actually change the amount of data that you send. It's not only that you shape them, it's really kind of because you're you're selecting a different coding that has actually sets less bits over the network, you know, that's where it's really valuable. In other cases when you do a bulk download or whatever, actually you want to send it as quickly as possible because like it's the same bits some number of bits no matter what, right? So these are the kind applications where it is very valuable, it might be more than just video, but at the end you shouldn't just blindly apply it to all kind of applications without having the knowledge that the application has this kind of ability and you need some probably some kind of channel to the application in order to like realize that probability.
Martin Duke: Well, well I don't think the point is to use SCONE for all applications. I think I think the point is that uh if you have a server that knows it could benefit from this that it could just do it without um relying on a client that has written a bunch of code.
Mirja Kühlewind: So what I'm saying is you shouldn't necessarily just do this because that doesn't gives you the benefit, you shouldn't you shouldn't just do it without also having the ability in the application to change the number of bits you want to send.
Martin Duke: Well right, I mean it it's implied that the server would not send SCONE packets if it if it had no ability to act on them.
Mirja Kühlewind: Yeah so like this definitely needs a warn- like the risk here is that you do something on the transport layer with this information and that's usually that you know it's not the worst thing but probably not the best idea, right? Like you really need it back to the application. Yeah.
Brian Trammell: All right so what I am seeing is some interest in continuing the discussion on this draft. Uh so please take that to the list, we'll definitely make sure we have time for wider discussion on this including do we want to do it, and if we want to do it do we have to do any charter shenanigans in order to uh be able to do so, uh at the latest in Vienna. Um but let's let's continue discussing this on the list too um until then. Sound good? Thanks a lot for bringing this Martin. Uh thank you all for uh discussion on the applicability manageability statement. Uh we will um follow up on that uh on the list and in GitHub in the coming days, and we will um also um schedule a second AppMan interim. Uh please fill out the doodle on the list, I've also put it in the chat if you have not done so already. Uh thanks a lot for your time and see you soon. Bye.