%% You should probably cite draft-kuhn-quic-careful-resume instead of this I-D.
@techreport{kuhn-quic-0rtt-bdp-03,
    number =    {draft-kuhn-quic-0rtt-bdp-03},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-kuhn-quic-0rtt-bdp/03/},
    author =    {Nicolas Kuhn and Stephan Emile and Gorry Fairhurst},
    title =     {{Transport parameters for 0-RTT connections}},
    pagetotal = 11,
    year =      ,
    month =     ,
    day =       ,
    abstract =  {The time-to-service duration depends on both peers and the peer initiating the connection may not be the peer actually sending data. Moreover, clients may be resource-limited, behind a low bandwidth or a long-RTT network and may need adaptations to improve data transmission or reception. While each client and server can have its dedicated solution to store path parameters, having a standard way of exchanging this information helps in providing symmetrical control of the optimisation and reducing protocol ossification. QUIC may not be limited to HTTP3: it can be used as a substrate for proxying and tunneling. This memo discusses a solution where the client is informed about path parameters: both the client and the server can contribute to the reduction of the time-to-service for subsequent connections. This would improve symmetrical transmission of data and reduce ossification of the protocol. To improve the time-to-service of subsequent 0-RTT reconnection the server currently sets in the early\_data extension the maximum volume of egress data the client is allowed to send when reconnecting. This memo proposes BDP\_metadata, an additional extension, to also inform the client about path parameters.},
}