> Haven’t found any quic stack that could enable me to set initial values for > some specific destinations. Happy to be corrected: please provide > pointers/urls
I’m not an expert in other stacks, but I expect most have some amount of configuration. For MsQuic, take a look at the QUIC_SETTINGS here<https://github.com/microsoft/msquic/blob/main/src/inc/msquic.h#L670> to configure things like idle timeout and initial RTT. If there is something missing, feel free to open an issue. > > On the other hand, I was surprised to see that these hints are not > > communicated to the peer. > Good point. The use case I’m working on set both sides with the hinted RTT > and other values. But it could be communicated through an extension I guess. I’m not sure these would have to be explicitly communicated. IMHO, each side likely should be aware of the expected scenario (e.g., space) and be configured appropriately directly. > > While I'm skeptical if QUIC would be the best choice for connections with > > RTTs of 20 minutes or more, > I did some testing using some stacks and changing in code a few of those > parameters detailed in the draft and “it worked”. However, those parameters > were global to the stack and there was no API I could find that would set > them. Moreover, in my mind, it has to be bound to specific destinations: not > all destinations have the same path characteristics: i.e. sending data to the > Moon does not have the same latency as sending to Mars. Hence the draft. I remember some discussion on Slack on this topic a few weeks back. I believe Martin Thompson and Christian Huitema had each played around with this scenario in their stacks. I know there is a bit of work to be done on MsQuic to (use 64-bit time fields instead of 32-bit) support these scenarios, but it should be straightforward to fix. So, I’m in agreement with Marten Seemann here, that this likely isn’t necessary to specify in an RFC. Thanks, - Nick Sent from Outlook<http://aka.ms/weboutlook> From: QUIC <[email protected]> On Behalf Of Marc Blanchet Sent: Wednesday, March 8, 2023 8:46 PM To: Marten Seemann <[email protected]> Cc: [email protected] Subject: Re: New Version Notification for draft-blanchet-quic-peerhints-00.txt Le 8 mars 2023 à 19:56, Marten Seemann <[email protected]<mailto:[email protected]>> a écrit : I'm not sure I understand the motivation of this draft. Setting initial values for initial RTT, idle timeouts etc. is already possible. How exactly this is done will depend on the API exposed by the QUIC stack. Haven’t found any quic stack that could enable me to set initial values for some specific destinations. Happy to be corrected: please provide pointers/urls. The QUIC WG hasn't specified any QUIC API, and different QUIC implementations expose very different APIs. Using the JSON as you propose seems like _one_ valid way to configure a QUIC stack, but I can think of 100 different ways that would be equally valid. Sure. I was suggesting one. Most importantly, since this is a purely local operation, it doesn't seem necessary to specify anything in the first place. This is entirely part of the API contract of every QUIC stack. On the other hand, I was surprised to see that these hints are not communicated to the peer. Good point. The use case I’m working on set both sides with the hinted RTT and other values. But it could be communicated through an extension I guess. While I'm skeptical if QUIC would be the best choice for connections with RTTs of 20 minutes or more, I did some testing using some stacks and changing in code a few of those parameters detailed in the draft and “it worked”. However, those parameters were global to the stack and there was no API I could find that would set them. Moreover, in my mind, it has to be bound to specific destinations: not all destinations have the same path characteristics: i.e. sending data to the Moon does not have the same latency as sending to Mars. Hence the draft. if you want to enable that use case, first of all the client would need to inform the server that it should expect such a long RTT, to give the server a hint to adjust (at the bare minimum) its values for initial RTTs (to avoid a flood of spurious retransmissions), handshake timeout (assuming the server applies such a concept) and idle timeout (which is usually set to much smaller values). Yes. See above. Right now, I was setting both sides. So I guess you are suggesting to write an extension to communicate those parameters to be communicated to the server? (Remember, the use case is some limited number of clients and servers in space: i.e. it costs a lot to have a server in space ;-)). Thanks for comments, very appreciated. Marc. On Thu, Mar 9, 2023 at 9:06 AM Marc Blanchet <[email protected]<mailto:[email protected]>> wrote: Hello, This is a draft about priming quic stacks for some parameters useful in the context of very long latency networks (such as in space): initial_rtt, max_idle_timeout, … Caveat: I’ve been involved for decades in IETF at the IP(v6) layer, application layer, DTN, but never in transport. So sorry if ideas are dumb. Having said that, would really appreciate reviews and comments. Marc. Début du message transféré : De: [email protected]<mailto:[email protected]> Objet: New Version Notification for draft-blanchet-quic-peerhints-00.txt Date: 8 mars 2023 à 15:02:06 HNE À: "Marc Blanchet" <[email protected]<mailto:[email protected]>>, "Marc Blanchet" <[email protected]<mailto:[email protected]>> A new version of I-D, draft-blanchet-quic-peerhints-00.txt has been successfully submitted by Marc Blanchet and posted to the IETF repository. Name: draft-blanchet-quic-peerhints Revision: 00 Title: Priming QUIC with Peer Hints for Atypical Networks, such as Delay-Tolerant Networks(DTN) Document date: 2023-03-08 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-blanchet-quic-peerhints-00.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-blanchet-quic-peerhints-00.txt&data=05%7C01%7Cnibanks%40microsoft.com%7C2621f9c271524c6301fd08db20402005%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638139232050365409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Eo36vDIf3ZnLZKPHtzXHxDwwiZklw6B709cmQ07CqTw%3D&reserved=0> Status: https://datatracker.ietf.org/doc/draft-blanchet-quic-peerhints/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-blanchet-quic-peerhints%2F&data=05%7C01%7Cnibanks%40microsoft.com%7C2621f9c271524c6301fd08db20402005%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638139232050365409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PD382XKnqIGPIkcgpPE%2BlXPQCt0ANtUA%2BUoU4GURRP0%3D&reserved=0> Html: https://www.ietf.org/archive/id/draft-blanchet-quic-peerhints-00.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-blanchet-quic-peerhints-00.html&data=05%7C01%7Cnibanks%40microsoft.com%7C2621f9c271524c6301fd08db20402005%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638139232050365409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m7lZ4IoTQKLfuMKZFTvKiuFIaBHJ2UcPLEbmusek5Xg%3D&reserved=0> Htmlized: https://datatracker.ietf.org/doc/html/draft-blanchet-quic-peerhints<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-blanchet-quic-peerhints&data=05%7C01%7Cnibanks%40microsoft.com%7C2621f9c271524c6301fd08db20402005%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638139232050365409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ISWi9eKC7segw7ST%2F8oQbPPf3DJaZaGjvIgBsqA2Bg8%3D&reserved=0> Abstract: Abstract The IETF Secretariat
