> Le 8 mars 2023 à 19:56, Marten Seemann <[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 >>> Status: >>> https://datatracker.ietf.org/doc/draft-blanchet-quic-peerhints/ >>> Html: >>> https://www.ietf.org/archive/id/draft-blanchet-quic-peerhints-00.html >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-blanchet-quic-peerhints >>> >>> >>> Abstract: >>> Abstract >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>
