931431 - Enable SSL_ENABLE_FDX for SPDY connections and pipelined HTTP connections

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

It seems like SSL_ENABLE_FDX originally was intended to be used for the case when an application was using one thread for writing and one thread for reading for the same socket. However, there is another side effect to it that seems useful even when an application is using a single thread on the connection:

http://mxr.mozilla.org/nss/source/lib/ssl/sslsecur.c?rev=9483ef9455fe#1116

If I'm understanding this correctly, whenever we do a PR_Recv/PR_Read on an SSL connection, and when a previous attempt to send data on that connection blocked, causing us to buffer some of the sent data, then before we try to receive any data, we try to send the buffered data. This seems bad for performance in the situations that browsers typically care about--usually we're very eager to receive data so we can show it to the user. Also, as long as PR_Poll is working correctly, it seems wasteful to attempt to send data on a socket that PR_Poll hasn't told us is ready for sending data.

In practice, we often do not send a lot of data. Probably this case matters only for when we've POSTed something large to the server. However, I bet there are some cases where this hurts us, especially with SPDY and connection coalescing where potentially downloads from many hosts sharing a connection could get (slightly) delayed by this sending of data.

See also https://codereview.chromium.org/464083 and bug 88303 comment 37 and bug 676729 by wtc.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

EKR, I imagine that the DTLS code used by WebRTC must do things to prevent NSS from internally buffering data like this, as I don't know the DTLS code as well as I would like. If so, then this wouldn't be useful to WebRTC; if not, then it seems like it is probably useful.

Wan-Teh, it doesn't appear that you ever enabled this in Chromium. Did you find that it was problematic in some way?

Comment 2

[Wan-Teh Chang]

Brian: I studied the SSL_ENABLE_FDX option at least twice before but I
forgot the details of my findings. I only remember it is only used for
two purposes. One of them is what you have identified. The other has to
do with timeout, which is ignored in non-blocking mode.

I searched for SSL_ENABLE_FDX in Bugzilla and found my comment in
but 676729 comment 1.

I also seem to remember I concluded that it is not necessary to enable
the SSL_ENABLE_FDX option even if you use the SSL socket in "full duplex"
mode. I found another old comment of mine in bug 88303 comment 37:

  The definition of the SSL_ENABLE_FDX option is:
      SSL_ENABLE_FDX tells the SSL library whether
      the application will have two threads, one
      reading and one writing, or just one thread
      doing reads and writes alternately.
  (http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1086543)

  PSM only has one thread doing reads and writes
  alternately on an SSL socket, therefore it should
  not enable the SSL_ENABLE_FDX option.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Thanks Wan-Teh.