APNs server sets maximum concurrent streams to 1 after a failed notification

Originator:jon
Number:rdar://27870881 Date Originated:2016-08-16
Status:Resolved Resolved:2016-08-17
Product:Other Product Version:
Classification: Reproducible:Always
 
Summary:
When establishing a connection to the HTTP/2-based APNs server, the server sends an initial SETTINGS frame that sets the maximum number of concurrent streams to 500. If the client sends a notification that is rejected by the server, the server immediately reduces the number of concurrent streams to 1.

Steps to Reproduce:
1. Connect to an APNs server via HTTP/2.
2. Wait for the initial SETTINGS frame, which will have a maximum concurrent stream limit of 500.
3. Send a HEADER/DATA frame pair for a push notification with an invalid token.
4. The server will reject the notification and send a SETTINGS frame that sets the maximum number of concurrent streams to 1.
5. Send a HEADER/DATA frame pair for a push notification with a valid token.
6. The server will accept the notification and send a SETTINGS frame that sets the maximum number of concurrent streams back to 500.

Expected Results:
The stream limit should remain the same, or at least wait for a larger number of failed notifications before throttling the connection, and then by smaller steps.

Actual Results:
The server immediately sets the concurrent stream limit to 1. After a successful notification, it immediately restores the stream limit to 500.

Version:


Notes:
Because the stream limit changes so drastically and is restored to the "normal" limit of 500 notifications so easily, this behavior doesn't seem to provide much meaningful rate limiting. In fact, we've seen it cause auxiliary problems where, in high-traffic conditions, the server will drop the stream limit to 1, then close the connection almost immediately with a GOAWAY frame complaining of a violated stream limit. It's not yet clear if this problem is on the client or server side.

Certainly, the server is entitled to change stream limits however it sees fit, but it seems like this particular strategy is causing non-trivial trouble without much gain.

For additional discussion, please see https://forums.developer.apple.com/message/162457 and https://github.com/relayrides/pushy/issues/356.

Thanks!

Configuration:
This behavior is reproducible in both the development and production environments.

Attachments:

Comments

As mentioned in https://forums.developer.apple.com/message/162457, this issue appears to be resolved. This issue has been verified as resolved and can be closed.

By jon at Aug. 17, 2016, 9:53 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!