Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Say we have a maximum data size #4288

Closed
larseggert opened this issue Oct 28, 2020 · 5 comments
Closed

Say we have a maximum data size #4288

larseggert opened this issue Oct 28, 2020 · 5 comments
Labels
-transport ietf-lc An issue that was raised during IETF Last Call.

Comments

@larseggert
Copy link
Member

A QUIC endpoint MUST NOT reuse a packet number within the same packet
number space in one connection. If the packet number for sending
reaches 2^62 - 1, the sender MUST close the connection without
sending a CONNECTION_CLOSE frame or any further packets; an endpoint
MAY send a Stateless Reset (Section 10.3) in response to further
packets that it receives.

I know that this is a lot of space, although you subdivide it so its
smaller, but I would be useful is the fact that there was a maximum data size
was stated up from and it was specified. There are some applications that
expect to send continuously without disruption and would need to take action
prior to termination of the transfer.

@larseggert larseggert added -transport ietf-lc An issue that was raised during IETF Last Call. labels Oct 28, 2020
@larseggert larseggert added this to the transport-genart milestone Oct 28, 2020
@MikeBishop
Copy link
Contributor

How are the packet number spaces subdivided? But yes, there are some absolute limits that it might be useful to mention earlier.

@martinthomson
Copy link
Member

I think that the packet number spaces caused a little confusion here: they multiply the number of packets (in theory, in practice they just add a small fixed number).

It's good systems design to be prepared to lose fragile resources like connections, so I'm very happy that packet numbers eventually run out. I would almost have been happier with a lower limit, but this is where we ended up.

BTW, the connection flow control limit is more likely to be the limit that applications hit (at least if you don't consider DATAGRAM).

@martinthomson
Copy link
Member

Proposing no action here.

@martinthomson martinthomson added the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Nov 5, 2020
@janaiyengar
Copy link
Contributor

I don't think we can come up with a maximum data limit, since:

  • packet numbers apply to packets, not to bytes (unlike in TCP)
  • each packet is sized based on MTU,
  • even theoretically, there are various control frames that need to be sent for protocol operation, which take away from any byte limit that we come up with.

I expect that we can do an approximate maximum (2^62 * MTU = 4.6 * 10^18 * MTU), which will have no practical value to an application.

@LPardue
Copy link
Member

LPardue commented Dec 8, 2020

The proposed resolution was to close to with action, which was signalled to the appropriate review channel.

Hearing no pushback, I'm closing this.

@LPardue LPardue closed this as completed Dec 8, 2020
@LPardue LPardue removed the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Dec 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport ietf-lc An issue that was raised during IETF Last Call.
Projects
None yet
Development

No branches or pull requests

5 participants