TCP_CORK 200ms maximum cork time -- expected behaviour?

Gidday,

The TCP_CORK socket option allows us to perform multiple write()s (or send()s or sendfile()s) while delaying the transmission of an outgoing TCP segment until the option is disabled (or a segment MSS is filled or the socket is closed).

All is fine and good, but there's one point I'm puzzled about: even when TCP_CORK is set, buffered data will still be transmitted after a 200 millisecond delay (the delay counts from the time that the first corked byte was written), even if TCP_CORK is still set. So, I'm wondering:

1. Is this intended behaviour, or simply an outgrowth of the combined implementations of TCP_CORK and TCP_NAGLE_OFF?

2. If it's intended behaviour, what is the rationale for the ceiling time on corking?

Cheers,

Michael

PS I first observed this behaviour quite some time back, but I've verified that it is still current (2.4.26 and 2.6.7 kernels). (In passing: of course, similar behaviour occurs with MSG_MORE on TCP sockets.)