Session Date/Time: 23 Jul 2026 09:30
[00:00:17] Michael Scharf: Hello. This is TCPM, and since we have a packed agenda, I think we should start on time. My name is Michael Scharf, one of the co chairs. Remotely, you see Yoshi, which is Hello. Chair. This is the note well, which you should have seen this week a couple of times, so I'm not going through it in detail. But if you have any questions, talk to us or talk to the IDs. You should know that the session is being recorded. We have a notetaker, which is Richard, and we have a jabber scribe, which is Yoshi, I guess. If you submit an Internet draft where you think tcpm might be interested in, please put tcpm in the name, then it shows up on our filter. The door is always opening again, so when people come in, they close it. So this is our agenda. We talk about the working group status. We have two working group documents where we have presentations for, which is the Ack-Rate Request and TCP-AO, a couple of new algorithms for TCP-AO not requiring other changes. And we have two individual documents. One is about tcp-ao with hashes requiring a TCP change and a packet trimming proposal. Do you have any comments for the agenda? Then we'll stick to it. This is the list of working group documents with the milestones. The milestones have been changed recently and also new milestones have been added recently. Since the last IETF, Accurate ECN became an RFC eventually, We have right now Ghost-Acks in working group last call, which is a simple document. So please give it a read, provide feedback. It's implemented in Linux and BSD and it's being used in production. After that, as you see, we have a monthly schedule for a couple of documents. We will ask for a generalized ECN, which we held back until accurate ECN was done. Was done meaning we have actually an RFC. After that we have diagnostic payload, which is an internet draft. We have no presentation this time, but changed substantially since the last IETF, the payload format, and now it seems to be pretty stable. And then we have two documents where we have presentations today. One has a milestone in November this year. This is the new algorithms for tcp-ao and the aggregate request document. We have a monthly schedule and the earlier the documents are on this list, the more realistic we think these milestones are. So it might be that some documents further away might take more discussion. But Ack-Rate Request had already a lot of them, so that might be pretty stable. So TCP EDO was moved to March 27, which is intentionally the last document because that's having the least implementation experience right now. Yoshi, you want to say? Add add something?
[00:05:13] Yoshifumi Nishida: Nothing particularly.
[00:05:15] Michael Scharf: Okay. So this means we can move on to the first presentation, which is cards. Carlos, you should have, slide control.
[00:05:46] Carlos Gomez: Okay. Thank you. Hello, everyone. My name is Carlos Gomez. I'm going to present the last update of the draft entitled TCP Ack-Rate Request Option. My co authors are John and Michael. And first of all, bit of motivation for this draft, is a web use mechanism which is intended to reduce protocol overhead. However, it may also continue to suboptimal performance in a number of scenarios, such as, so called large congestion window scenarios, meaning scenarios where congestion window size is much greater than the MSS, while saving more than one of every two x may help improve the performance, and also small congestion window scenarios, meaning congestion window size up to the order of about one MSS where delayed x may incur too much delay and limit congestion window growth and so on. This is the main format for the TARR option. The r field indicates the act rate, which is requested by the sender, meaning after how many liquor segments received, the the receiver is requested to send an ACK. There's the special case of r equal to zero, which indicates the request of an immediate ACK while keeping the steady state value of r. On the status of the draft, it was adopted in February 2023. And today, I'm presenting revision 12, which, provides a new section, section nine on implementation status. This is after comments from the last meeting. Also related with that, there is a new contributors section. So on the new section on implementation status, this is a section that follows the guidance in RFC seventy nine forty two, which is intended to assist the ITF in its decision processes, since, running code provides billable experimentation and feedback, and the section is intended to be removed according to data that you see before eventual publication of this document as RFC. So this section has two main subsections. The first one, nine dot one, is about the Linux implementation. So, you can find the GitHub link with the code publicly available on the slide and also in the draft. This is a TAR implementation for Linux kernel seven dot zero dot zero r c two, and it covers sections three and four of the present specification. So these sections are the core of of the draft. Sections five and seven are not covered. Section five is actually, about guidance about handling and which is the impact of stretch axe. And section seven is, about socket API considerations. So sections three and four conform to the previous version of the draft, and the project code is licensed under the GPL 2.0 license. One important point is that the experience from the main developer, who's, Nasir Rohan, was that, he found no issues with the draft. Hopefully, it was clear enough for him. And here we can see one example capture, from a communication where there is TAR being used, actually. And, the highlighted frame corresponds to the SYN-ACK segment sent by the receiver announcing support of TAR. And it's quite interesting to note that, already, correctly identifies, this option and its format, possibly in part because of the early allocation of an experiment ID value specific for TAR. And then we also carried out a few validation tests with different values of r, and the resulting behavior was according to our expectation. Then we also have nine dot two. We have a TAR implementation for lightweight IP, in this case, developed by Ahmed Al Jabri and supervised by Jon Crowcroft from the University of Cambridge. And, for those of you who are not, aware about it, lightweight IP is a TCP implementation which is suitable for constrained devices with about 10 kilobyte of RAM. And, this implementation also covers sections three and four, again, the main core of this draft, according to revision 11. The licensing terms are the same as those for lightweight IP, and, also, the main developer didn't encounter any issues with the draft while, developing implementation. And you also have n s three simulation code, developed by the same authors, and, the corresponding code is publicly available on the link that you can find on the slide. And then it's possible to run n s three simulations with TCP flows supporting TAR. So this is on the slide, we have a figure. It's an example figure showing some results. In this particular case, this corresponds to a scenario that's intent intended as a small congested window scenario where there is 50 flows sharing some resources. Actually, there's a one gigabits per second Ethernet link that's shared. Half of the flows you star with r equal to one, the other half do not you star. And in this case, what we can see is that most of the flows that you star you complete, much earlier than those without use of TAR. However well, this is just anyway one example of simulation results that can be obtained by using this available code. Okay. So, at this moment, the authors, I believe, we are not aware of any outstanding issues with the draft. And, also, we have, the two implementations mentioned before and also n s three simulation code. So we would like to ask the working group and the chairs whether this could be a good moment to consider working group last call.
[00:12:20] Michael Scharf: Thank you. Are there any questions? I have a question. Really like the implementation stuff. Did you also test between the two implementations? Or
[00:12:43] Carlos Gomez: No. No. We did a test between the two.
[00:12:47] Michael Scharf: But that should be possible, right, because both are
[00:12:52] Carlos Gomez: Yes. In theory, it should be feasible, yes. But we needed to do such tests, yes.
[00:13:05] Michael Scharf: Any more questions?
[00:13:12] Yoshifumi Nishida: Did you do any performance test for actual implementation?
[00:13:26] Carlos Gomez: Sorry. Is is this was that a question for me?
[00:13:34] Yoshifumi Nishida: Maybe I should yeah. It's a question. So did you do some kind of performance test with implementation?
[00:13:43] Carlos Gomez: Well, the the performance test that we did was basically with the first implementation, the Linux implementation, but it was very basic. So it was not like a comprehensive set of experiments. But at least with the initial test that we carried out, we tested, for example, r equal to one three five. And then the acts that were generated by the receiver, the amount of acts was according to the expectation. So that is the level of of evaluation that we carried out so far.
[00:14:26] Yoshifumi Nishida: I see. Thank you.
[00:14:37] Michael Scharf: There is one question on the chat. How can the LightWide IP efficiently operate with CoAP over TCP? Are there any implementation or validation? You can see that question in the chat.
[00:14:53] Carlos Gomez: Yeah. Okay. So at this moment, the lightweight IP implementation is just a fork of of the default LightWid IP with support of TAR. So we haven't tested CoAP on top of that, but I agree that it would be actually interesting to to do so.
[00:15:24] Michael Scharf: Okay. There are no further questions from the room regarding the question of our working group last call, we I presented earlier the updated list of milestones, And they took into consideration which documents stayed here pretty long in the working group and which documents have a different pressure of implementation. So if you think we should talk about the milestones, we can do that offline. Okay? Yes. Thank you. Thank you. Thank you for the presentation. It can come. Pardon? We do the tcp- a o. Yeah. Maybe I got this wrong. It's it's is it this one? Or
[00:17:03] Ron Bonica: Additional yes. That one. Thank you.
[00:17:14] Michael Scharf: Should have slide control.
[00:17:20] Ron Bonica: Hi. Ron Bonica, HPE. And we're going to talk about some additional cryptographic algorithm algorithms for use with TCP-AO. Currently, TCP-AO supports only two cryptographic algorithms, HMAC-SHA-1-96 and AES-128-CMAC-96. NIST is advising transitioning from SHA one to SHA two or SHA three by 12/30/2030, which means we have a short term need to get some more cryptographic algorithms. NIST allows 96 bit MAC truncation, but only for selected purposes. For the purposes of routing protocols, it's okay, but not for other purposes. So, we need some stronger algorithms by 2030. We have some solution constraints here. The TCP-AO length must not exceed 20 bytes. The reason why is we only have 40 bytes of tcp option space and we need to leave some space for other options. SHA two can produce two twenty four, two fifty six, three eighty four, and five twelve bit max. And you can only allow if you're gonna truncate that mac, you can only truncate it to 50 of its original size. So that means if we're gonna meet our constraint of keeping TCP-AO under twenty twenty bytes, the best we can do is shot two fifty six truncated to one twenty eight bits. So we have we have a draft in which we present we propose two new authentication algorithms. HMAC two fifty six one twenty eight and KMAC two fifth SHA two fifty six one twenty eight. We've had significant review on them from Eric Biggers, John Matson, Russ Housley, and Ping Chen. And lately, we had a security a sector review, and the draft has been up updated. Here are the updates we've made. First, we've chosen the authentication algorithms that we'd like to use. The KDFs are listed here as are the MAC algorithms. In the sector review, we've had a bit of controversy. One security person, Eric Biggers, suggested HKDF-SHA 256. The other security reviewer, Brian Weiss, recommended a different KDF. We need to get consensus between these two, pick one of them, and then we can go forward. But we're pretty stable on these four, you know, these two KDFs and these two HMAX. We've also added a section on test vectors. This is very much like the test vectors that we produced for TCP-AO and r f c 9235. The test vectors use all the same test cases as r f c ninety two thirty five. It's just that all of the KDF's and max are are all TBD. We haven't actually done the experiment yet. So what are we asking of the working group here? We were asking for a sector review. We've got that now. What we need to do is get the two security people to agree on which HMAC KDF we're gonna use. Once we do that, I think we have the draft in stable condition. The second thing we need is a second implementation. And the reason we need a second implementation, you know, we at HPE can do an implementation, generate the test vectors and, you know, for given inputs, what MACs should you generate, what what traffic keys should you generate. But we need a second implementation to make sure that our implementation doesn't have bugs. So I'm looking to the working group for somebody to do that second implementation. We already have the call for adoption. After that, we'd be looking for a last call. Any comments on this draft?
[00:22:27] Michael Scharf: Richard?
[00:22:32] Richard Scheffenegger: Richard, Jeff Necker. So I believe if you're asking for a second implementation, this group is probably not necessarily the best group. I think the routing area would probably have more implementers present.
[00:22:47] Ron Bonica: Thank you.
[00:22:50] Lars Eggert: Lars, I got Mozilla. So I can't comment on any of the crypto part of this, but I'm very happy how this played out in the working group because in the beginning, you know, it it it looked like this is gonna turn into a big big argument, and then we decided we're gonna do the reasonable small thing first and worry about the more complicated thing later. And I think this approach is working well, and you guys have been very active editing documents and talking to a group talk of us. And, yeah, this worked really well for my opinion. Thank you.
[00:23:18] Ron Bonica: Okay. So it looks like we have consents well, consensus in the room at least on this document. I'll take the action item of getting the two security guys to agree on which HMAC KDF we should use. Once we do that, we'll do an implementation and we're still looking for a second one.
[00:23:35] Michael Scharf: Yes. Thank you. I remember there is one additional point in the discussion with the security people, and this is about in TCP IO, the term master key is used. Yes. And people so it was pointed out that some people understand this as an ASCII passport, which has not the same amount of entropy as a random number of the same length. And how do we deal with that?
[00:24:12] Ron Bonica: Yes. This is a problem that we've had ever since the beginning of tcpao. The k d f's that we use do not necessarily protect against weak master keys. One possibility is to require the operator to put in a strong master key. A master key with 250 with a 128 bits of entropy. That means ASCII keys won't do it. It's probably unreasonable to ask an operator to enter something other than an ASCII key. One of the h max that we proposed, the initial one, actually does protect against weak master keys. That is this one you'll see h k d f SHA two fifty six. One of the security people objected to that one, wanted to go to a different one that doesn't protect against weak master keys. The other security person is arguing back. Yes. We should use the one that does the key expansion and protects against weak masters.
[00:25:32] Michael Scharf: Or at least make it clear in the security considerations that this is an issue the operators need to deal with. Possibly, you can't change existing implementations, what they accept or whatnot. Should not forget this and deal with it. Gauri was in the line? He is still in the line or he's not in the line anymore? Okay. Any further questions for Ron regarding this document? And we switch slides.
[00:26:13] Ron Bonica: Okay. This is only a temporary stop gap. It gets us some runway so we won't have a problem in 2030. But sooner or later, we are going to need even stronger algorithms. And these are algorithms that are do not truncate the MAC to a 128 bits. They're real SHA two algorithms that give you a two fifty six bit MAC without truncation. Now
[00:26:43] Michael Scharf: Is it this one you want?
[00:26:44] Ron Bonica: Yes. This one. Okay. So, sooner or later, we're gonna have to go to things like h mac SHA two fifty six without truncation or k mac SHA two fifty six without truncation. That means that we'll have a two fifty six bit or a 32 byte MAC and tcp a o will be 36 bytes long. That's 36 of the 40 bytes available in the tcp header for options. The problem is that the option field will not be long enough when that happens. So we have a proposal to deal with extending the option field. Now, I realized there's another proposal on the table, the EDO proposal. This is an alternative. It's experimental like the I believe EDO is experimental or is it proposed standard?
[00:27:41] Michael Scharf: Right now, it's proposed standard.
[00:27:43] Ron Bonica: It's proposed standard. Okay. It's experimental. We have an implementation. We know that it it works and we'll talk about it a little bit. The problem statement TCP o well, we've talked about the problem. The TCP header only accommodates 40 byte of op bytes of options. We need more. This experiment allows us to accommodate up to a 16 bytes of options. A little overview of the problem. This is the TCP header as we know and love it today. I'm gonna call it Seg-O. It's the original segment header. You'll see in it a data offset field. It determines the data offset. It's in 32 bit units and the valid values are five to 15. Because the valid values are five fifth to 15, the maximum size of the option field is 40 bytes. This is the upgraded TCP segment. It's what we're adding here. You'll see that it's absolutely identical to the original segment header except for one difference. The valid values in the data offset field are zero and five to 15. So, a value that used to be invalid in Seg-O is now valid in Seg-U, zero. Because of some magic and how that zero is processed, now the maximum size of the options field is one k. Actually, it's 1,016. And the way we do this is in the Seg-U, the first eight bits of the option field is the length measured in 32 bit units. So, the option field can be up to a k. So, we have two TCP session types. There's the original TCP session. We're gonna call it TCPO. Every pack every segment is a Seg-O. That means that the data offset field must have a value five to 15. Then we have an upgraded TCP session. We're gonna call it TCP u. Every segment in the three way handshake must be a Seg-U even if it carries no options. So every segment in the in the three way handshake has to have a data offset field of zero. It would be invalid in a TCPO. And subsequent segments can be Seg-O or Seg-U depending on how many bytes of options they carry. Now, what does this say about compatibility between a TCP-U and a TCP-O? T c p o and TCP-U are 100% incompatible incompatible. Legacy t p Legacy TCPs silently discard Seg-U. So, if a upgraded TCP tries to initiate a TCP u with a legacy TCP, The legacy tcp will discard the SYN packet and the session initialization will time out. This isn't a bug. It's a feature. And the reason we say it's a feature is a TCP-U cannot be used to attack as an attack vector against a legacy t c p. That first SYN packet will be ignored and TCP-U's cannot talk to TCP-O's at all ever for any reason. So given that we have 100% incompatibility between an upgraded TCP session and an original TCP session, how do we make nodes compatible?
[00:32:06] Lars Eggert: Well, we
[00:32:09] Ron Bonica: get backwards compatibility with something called a dual three way handshake. And in this case, what's happening is the upgraded TCP sends two SYNs to its peer. Depending on which ones it gets an answer on, it can tell whether its peer is upgraded or not or upgraded or legacy, and it proceeds with the correct TCP session. This should remind you of two things. One is happy eyeballs, something used to determine whether you're gonna do it I p v four or I p v six connection. It's also something that was introduced in this working group about ten years ago. And back then, it was again called a dual three way handshake. Now, how does this dual three way handshake works? The TCP client sends two SYN segments, a SYN o and a SYN a seg o and a seg u. The seg o initiates a tcp o session, seg u initiates a tcp u session. The client receives a SYN-ACK from the tcp o, the tcp u, both or neither. If it gets a SYN-ACK from the tcp u, it continues with the tcp u and that that didn't get an ACK from the tcpu, so there's nothing else to do. If it gets an ACK from the tcpu only, it continues with the tcpu or terminates it as per local policy. It may well be that this particular app application can't live with a tcp o. It needs to use options that exceed 40 bytes. In that case, it just terminates it. If it gets an ACK from both, it continues with the tcpu and terminates the tcp o. And if it gets an ACK from neither, it retries both. So what is the call what is the ask from the working group? Yes.
[00:34:25] Richard Scheffenegger: This is Richard Schaffnerger again. I agree with the notion that utilizing a currently undefined or reserved value should not cause any problems. However, I can tell you that especially some hardware implemented stacks do not necessarily validate all these numbers. They expect the incoming traffic to adhere to standard TCP header and TCP header formats. So if you send them something like this, they may cause problems. So before going any further, I would really want to see some actual experiments against the less common TCP stacks. If the assumptions that you're making that this doesn't cause harm, does not cause harm, or, you know, have the people where this does fail, this test does fail, fix their implementation.
[00:35:30] Ron Bonica: Okay. A quick question. You say that some TCP stacks, when they receive a SYN packet with the offset segment of zero, they they will accept it even though it's invalid.
[00:35:46] Richard Scheffenegger: I know I know for a fact for an undisclosed security
[00:35:50] Ron Bonica: Yes.
[00:35:51] Richard Scheffenegger: Issue in a hardware in a hardware offloaded stack.
[00:35:54] Ron Bonica: There's a detail in the draft that is not in the slides. They will send something back. If the thing that they send back does not all
[00:36:03] Richard Scheffenegger: They will crash. I'm sorry. What will they do? They crash.
[00:36:07] Michael Scharf: They will crash.
[00:36:09] Ron Bonica: Oh, they will crash. Okay. That that is a bad thing.
[00:36:13] Richard Scheffenegger: Yes.
[00:36:13] Ron Bonica: If they if they sent something back that didn't have a zero, I would clear them away. If they crash, that's a problem.
[00:36:21] Richard Scheffenegger: Just saying the assumption that that people should should not should do something sensible when they receive something that is unexpected is a little bit bold.
[00:36:30] Ron Bonica: Yeah. If they crash, I think they're noncompliant already.
[00:36:35] Richard Scheffenegger: I would agree.
[00:36:40] Gorry Fairhurst: Gorry, as an individual question. The two TCP sends in flight in parallel, how does that work with connection tracking? The device that do connection tracking between the two endpoints.
[00:36:56] Ron Bonica: I'm sorry. Could you say that again?
[00:36:57] Gorry Fairhurst: So this is TCPM, not Quake. We have boxes in the middle and many boxes do connection tracking, trying to work out which TCP connections are being set up to either act as a firewall or accounting or whatever. How does that work? Have you tried it with middle boxes?
[00:37:18] Ron Bonica: Okay. If the middle box is not aware of this, when it sees the data offset of zero, it should discard the packets too. Then just
[00:37:31] Gorry Fairhurst: just discards the packets or will it then discard everything else for that TCP session because it you've now got an invalid packet on the path.
[00:37:39] Yoshifumi Nishida: I mean, like
[00:37:40] Ron Bonica: But when a middle box sees an invalid packet, shouldn't it discard the packet?
[00:37:45] Gorry Fairhurst: It should discard the packet. Does it discard all the state for the connection as well?
[00:37:50] Ron Bonica: Well, it's the first packet in the connection. So there there shouldn't be any state yet.
[00:37:57] Gorry Fairhurst: Let let's see how that works.
[00:38:01] Lars Eggert: Lars Eggert, Mozilla. Now I have three things. I think what gory means is that if you have such a middle box and they, for whatever reason, decide that that your two sins are part of the same flow and one of them is invalid, they might decide something about the others and that They normally would have gone through.
[00:38:19] Ron Bonica: They will not be part of the same flow. They have different
[00:38:22] Lars Eggert: Source ports.
[00:38:22] Ron Bonica: Source ports.
[00:38:23] Lars Eggert: Okay. K.
[00:38:24] Ron Bonica: But that wasn't in the slides. It is in the Okay.
[00:38:27] Lars Eggert: Draft. The the the thing I actually got there's two things that I actually got in line for. One is that there's two proposals for extending the option space. One has been going on for a really long time, and and now there's this, which is conceptually much simpler, and I therefore maybe like it more. But but I don't think the working group should should do two things. I think we need to have the discussion about what do we wanna take forward and in which form. And and, you know, I'll leave it there. The other thing I also don't wanna rat hole on, there is an IPR disclosure against this draft that talks about the usual boilerplate if this is adopted in this standard. But you're targeting experimental at the moment. And that means that the IPR disclosure on the draft doesn't extend if we publish it as experimental. So you probably wanna, yes, down the road, fix that so that if it were to be published as experimental, it it did apply the IPR disclosure
[00:39:26] Ron Bonica: to it. Agree. We'll have to think about the IPR.
[00:39:31] Magnus Westerlund: Magnus Westerlund, Ericsson. I I didn't get up in the early part of this and challenge your I think, the need for these long tags. I think you need to maybe clarify. To my understanding, the only way of attempting a forgery is to send a packet to the receivers, which requires you to use bandwidth. There's no offline attack here for attempted forgery on on on tcp a o. And that means that you are restricted by I don't understand why you don't need a 384 bit tag. Because even at a 128 bit ideal tag, we're talking about the time to do an attack that is longer than universe has existed. So, I I I just think we need to be clear on what's what is the constraints on this Cypher, etcetera, aspects here that requires this untruncated tags of this length. I agree the key length might be very well be useful, but I don't understand why the authentication tag needs to be so long. So that's just a reservation from my perspective here.
[00:40:49] Ron Bonica: Okay. Myself, I'm not a security heavy. I do know that customers are asking for stronger authentication than what we do in the first draft.
[00:41:03] Michael Scharf: I could took some from the floor, which means speaking as an individual. When I read a TCPM specification, I expect that I get told what the TCP stack needs to do. Your happy eyeballs thing with SecU and SecO runs on top of TCP. So that's using different port numbers that would be implemented on top of TCP. So from my perspective, this does not need to be in this document. It confuses many people. You might have a statement there that you can do happy eye happy eyebots like of style of things. But talking about this like here
[00:41:52] Ron Bonica: I agree.
[00:41:52] Michael Scharf: People get the impression that these sins segments are sent by the t c p stack racing against each other or or something else.
[00:42:01] Ron Bonica: I agree. It might be a good idea to break this off into a separate document and, you know, say you can do this either with the dual SIN or without.
[00:42:12] Michael Scharf: I mean, you can mention that in an annex and see whether there is additional information needed or if it's just good enough.
[00:42:19] Ron Bonica: All reasonable.
[00:42:23] Tony Lee: Hi. Tony Lee, HPE. Several points in no particular order. To the IPR question, yes, our IPR claim currently only does talk about things going standard. And, yes, we should extend that to be experimental. And, yes, we've already spoken to our lawyers. I have verbal approval from the lawyers, and they say they're going to fix that. But, obviously, it hasn't happened yet. I assume we can wait for that. Earlier, I heard what I think I heard was a request that we wait until other people have fixed their TCP implementations to not crash if they see a zero segment length. This is not nineteen eighty three, guys. I don't think that's a reasonable ask. So
[00:43:18] Michael Scharf: So I would agree that crashing is not a feature. It's always a bucket that should be fixed.
[00:43:29] Allison Mankin: Allison Mankin, Packet Clearing House. So I I I can think of another reason to separate out the question of doing dual or not, which is all the DNS people who are terribly afraid of getting too many DNS, TCP connections and having to deal with all those ports. So you you might wanna consider, you know, advice for those whose TCPs should perhaps never do this because they really don't need to. They have other mechanisms And and not make it so that it's kind of universally going to be that you'll see more ports being consumed because that will that will drive the DNS community to be very unhappy. Mhmm. But I I I like where this is going a lot, and I I think this is but this is really clear. I really appreciate your presentation, Ron.
[00:44:20] Ron Bonica: Thank you very much.
[00:44:27] Lars Eggert: Rather than a different port, have you considered just using a different sequence number?
[00:44:30] Ron Bonica: I'm sorry. I can't
[00:44:31] Lars Eggert: Oh, sure. So, rather rather than using a different port, have you considered using a different sequence number?
[00:44:37] Ron Bonica: Yes. We did. And the reason we decided to use a different port for the dual SIM is so that they would be different state. And if a middle box as Corey brought up, if a middle box got confused about the leading state, it would be easy if they were different source ports.
[00:45:00] Gorry Fairhurst: Gory as a d with a new hat. One of the things that does confuse me, which shouldn't confuse anyone else afterwards, is the title.
[00:45:11] Ron Bonica: The title?
[00:45:12] Gorry Fairhurst: Of the draft as in
[00:45:14] Ron Bonica: the I forget. What is it? Extended?
[00:45:17] Gorry Fairhurst: Whatever. It's not unique enough for kind of like what we're working on because I think if I understand the proposal, now you have to correct me, that this is intended for a particular place and it's particularly extended to extend it in this way. And the EDO thing, if that continues, is another way of doing it for a slightly different case.
[00:45:41] Flavius Mazillo: And we
[00:45:41] Gorry Fairhurst: need to have at least titles and clear distinction between these two ways of operating because I still have concerns if you're not going to do middle box testing of what exactly happens with your case. And I I don't wanna see these two things muddled up by anybody else in the future.
[00:45:59] Ron Bonica: I get it. If you could propose a title, I'll take it. I'm
[00:46:04] Gorry Fairhurst: that isn't really something has to be done at this stage. As long as we're confident we have a different title in mind, that would be enough to carry on. It wasn't meant to be blocking in any way. It was a mean, let's keep these two piece of work separate. So when we talk about working group adoption, the chairs can decide what they want to ask, but this is separate to that other piece of work. And it will be clearly differentiated from that. Okay.
[00:46:33] Michael Scharf: So King is separated from EDO?
[00:46:37] Gorry Fairhurst: The other piece of work is EDO, that document that's been going on for a while,
[00:46:41] Michael Scharf: yes. Yes. Lars was also asking for exactly this. One potential way forward could be that tcp- EDO progresses as experimental as does this document. And then they are addressing different use cases, and then we can see which one gets traction, implementations, whatever. And later, based on that experience, we can move one of them, none of them, both of them the But making this decision now seems to be hard. So any feedback from the working group about that way of progressing?
[00:47:49] Ron Bonica: Oh, I'm sorry?
[00:47:51] Lars Eggert: There's somebody remote in this
[00:47:52] Ron Bonica: Oh, Mike Hurt is in the queue.
[00:47:59] Mike Heard: Yes. I I I would, prefer not to see this thing two ways of doing the same thing, and EDO seems to have been a very long and somewhat morbid effort. But it it right now, it's it's destined for standards track, we certainly don't I I don't think that's that's appropriate given that this is technically preferable and or at least I think it is.
[00:48:31] Michael Scharf: So just a clarification, the the stuff I was asking is both documents progressing as experimental. So this means changing EDO from intended state proposed standard to intended state experimental?
[00:48:50] Lars Eggert: Lars, I got Mozilla. So I think that would be a disappointing outcome because it's really confusing to have two somewhat similar but slightly different proposal option extension proposals. I mean, EDO has been going on for a very long time and is is a a much more complex mechanism and also doesn't quite solve this use case where you really seem to want it in the SIN. And and and the the difference here seems to that you you only really do this in the SIN if I understood it correctly or in the initial option space. So I kind of wonder if you could do something similar like we did when we did AO in the beginning where for AO, we really tried hard to make it a generic TCP extension that might have all kinds of users. In reality, it was only ever used for BGP sessions as far as I know. And I kinda wonder if we just, like second time around, like, in light of that fact, just, you know, be honest and say, this is an extension, whether it's experimental or maybe it's an experiment. Let's leave it at it's an experimental extension meant to add additional security to some TCP workloads, specifically BGP, where it's suitable, and people might experiment with using it for something else. But that's not at least where the working group has placed the emphasis. And and and it gives us then the ability to do something simple. It gives us the ability to do something that isn't that we know isn't gonna work for many other things, but it maybe also doesn't need to. Right? Because we can be pretty sure similar to a o that the that the routers of the world will implement this correctly. And to the point of I forgot who made it that this is a mechanism on top of TCP. It is. But you could phrase it differently. You could say, if you speak this, you send this in, and if you don't get an answer, then you're done. And the fallback is then something that you handle at the application layer. We don't need to specify it. You can maybe put an appendix in it. As you know, if you're clever, this is a way in which this would work. You just build this little mechanism on top of your TCP sessions. But I so I really like to focus this on one thing and not both. I I to be clear, I wouldn't mind EDO winning out too, but it seems to have not a whole lot of momentum behind it at the moment, and this one doesn't. So, you know, it's it's where the energy is is is what determines what happens.
[00:51:18] Michael Scharf: Yep. Thank you for the comment. Yoshi?
[00:51:27] Yoshifumi Nishida: Yeah. I understand Raj's point, but it's very difficult. At this point, it's very difficult to decide one of them because, you know, it seems to be that, you know, we need some kind of implementation or experimental result to decide it. At this point, if we want to try to one of them, it just kind of favoring both, which sounds like we, you know, better option, but we don't have any solid evidence. So that's why it's very difficult to decide one of them at this point from my point of view.
[00:52:12] Michael Scharf: Thank you. We'll discuss this on the meeting as to how we
[00:52:17] Ron Bonica: Okay. Thanks. Actually. Thank you. And thank you all.
[00:52:31] Flavius Mazillo: Okay. Hello, everyone. I'm Flavius Mazillo, and I'll be presenting TCP packet trimming extension co authored with Valentin Mobaro and Christina Raicho. This draft ask whether TCP can make use of a signal that is already becoming available in data center switches, and that is packet trimming. Just one second. I'm not sure I can control. Okay. Thanks.
[00:52:56] Michael Scharf: I'm controlling the slides.
[00:52:59] Flavius Mazillo: Okay. Perfect. Okay. So today, TCP loss detection generally relies on indirect signals of loss. This includes duplicate acknowledgments, seg based cooperating, and time based mechanisms such as in rack TLP. These mechanisms work well in many environments, but they are still heuristics. They can be delayed, and they can sometimes infer loss incorrectly, especially when there is significant packet reordering. One source of packet reordering in modern data centers is PacketSpring. That is instead of sending all packets of a flow along the same path, packet spring distributes them across multiple path to better utilize the available network links. While this improves the load balancing, it also introduces substantial packet reordering. And as we'll see, packet trimming handle this scenario particularly well. At the same time, several modern data center switches support packet trimming. However, TCP currently has no standardized way to use the information provided by a trimmed packet. The main improvement that package trimming brings is an explicit notification for packet loss. Okay. Next slide, please. How packet trimming works? So when a switch become congested, instead of completely dropping the incoming packet, it will remove the payload while preserving the IP and TCP headers. The switch also changes the DSCP value in the IP header to indicate that trimming occurred. The trimmed packet can optionally be sent to a higher priority queue so that the receiver learns about the event quickly. The important information that remains available in the trimmed packet is the connection tuple and the TCP sequence number. This is enough for the receiver to identify which data segment was affected. Okay. Next slide. This is not only a theoretical capability. Packet trimming is documented or supported by vendors, including Arista, Broadcom, NVIDIA, and Juniper. Next slide. Okay. So the first part of the proposal is capability negotiation. The host exchange a TCP option called trimming permitted during the three way handshake. This is similar in spirit to the SAC permitted option. Only more when both SYN and SYN-ACK carry this option does the connection become trimming capable. The sender then marks subsequent data packets with configured DSCP trimable value. If either endpoint does not support the option, data packets use the default DSCP marking and remain subject to ordinary packet dropping. Next slide. The second part is the TCP option called trimming NACK. So when the receiver gets a packet marked with the SCP trimmed, it knows that the packet payload was removed by the network. It does not treat any remaining payload as valid data. Instead, it extracts the sequence number from the packet and immediately send a TCP packet containing the NACK option. The NACK carries the sequence number of the affected data. The data receiver should handle the TRIM packet especially because the TCP checksum is no longer valid. The switch updates the IP header, but it does not recalculate the TCP checksum over the shortened payload. Next slide, please. The flow is there for us follows. The sender transmits a normal data packet with the sequence number x, as you can see in event one. A congested switch trims the payload, changes the DSCP value to DSCP trims, and forwards the headers. The receiver detects the trimming and sends a NACK identifying the sequence number x, when the sender received the NACK eventually at event two, it locates the corresponding segment and retransmit it immediately. The transmission is still subject to congestion window and flow control limits. Once it arrives, the receiver gets the complete data packet and normal TCP pro sorry. TCP processing continues. Next slide. Okay. An act provides both a precise loss indication and an explicit congestion indication. Therefore, the sender should treat it as a loss event, meaning retransmit the affected data and enter fast recovery. Package trimming can also coexist with some already existing loss detection mechanisms. Administrators may disable them or keep one as a fallback since some packets may still be dropped rather than trimmed. Obviously, RTO still remains the base fallback. This capability should be scoped to data centers for broad Internet using the DSCP field would not be feasible since many ICPs just strip them away. Next slide, please. Also, the switches don't update the TCP header, only IP header. Thus the checks the TCP checksum remains calculated against the original full payload, rendering it invalid for the trim packet. Also, switches may not trim the payload precisely at the TCP header boundaries as doing so require parsing parsing variable length TCP headers to locate the data offset also because of some hardware consideration and so forth. Therefore, a trim packet may still contain a partial payload fragment Since the TCP checksum is invalid, the integrity of this data cannot be verified. The DSCP Trimable and the DSCP Trimmed, the two main, the DSCP values are configured by network administrators on the hardware switches. Thus, they should be configure configurable on the two hosts to manage the values on switches too. Finally, NACK packets should ideally receive higher priority than regular data to avoid delays caused by queuing. Alternate transport specification proposes a third value called the DSCP control mapped to the same high priority queue as the DSCP trimmed packets. Next slide, please. Ultimately, some questions for the working group, and some examples of them would be, is the problem useful for t s and TCPM to work on? Is a proposed shape reasonable with the two options, trimming permitted and NACK option? What would be the main concerns? Maybe the SAP usage or check some handling for congestion control. And, ultimately, if in at the end, if people would be interested in reviewing or discussing a revised draft.
[01:00:16] Ron Bonica: Thank you.
[01:00:18] Michael Scharf: Thank you for the presentation. We would have time for one quick question.
[01:00:28] Richard Scheffenegger: Richard Jaffna again. Thank you for bringing this work here. I think it's very valuable. However, I'm a little bit concerned about the external configuration of the trimmable and trimmed DSCPs. I think there should be an inbound oh, sorry, an in band signaling to negotiate or at least signal this on flow so that intermediate devices can detect potential misconfigurations.
[01:00:55] Flavius Mazillo: Mhmm. Makes sense.
[01:00:59] Lars Eggert: Similar. So I'm I'm interested in this shocker. We talked about this for a while. Same thing. The DSCP stuff is is ugly, and it would be nice to find something that's a bit more elegant. The other thing is if if trimmed packets leak out of your control domain somehow, like, what happens? Like, we had the discussion earlier, like, where Richard said that, you know, even with the with the EDO pro not the the extended option proposal, if you set the offset to zero, things like crashes. There's at least a danger here too. So I think investigating this a bit more would be useful, but I'm wanna close out by saying what I think I talked to you privately. I'm sort of excited to think about what this packet trimming idea that's now available in switches means for the Internet. Like, can we do anything cool with it? That is really, I think, the the thing that I wanna think about. Thank you.
[01:01:58] Michael Scharf: Thank you again for the presentation. We can continue the discussion on the list. And this closes this session. See you on the mailing list and in San Francisco.
[01:02:13] Yoshifumi Nishida: Perfect.
[01:02:14] Flavius Mazillo: Thank you. Thanks.