Re: [hybi] On Fragmenting of Frames

[Bob Gezelter <[e-mail]>]

Nowhere in the recent discussion of Frame Length have I seen a reference to
the realities of extended length (> 64KB) frames. Instead, I have seen
references to requiring extended frame sizes to support "sending extended
messages with no overhead". With all due respect for hyperbole, this concern
is not supported by the realities of the network. [In the interests of
smooth reading, I am omitting the citations from the following couple of
paragraphs.]

The WebSocket protocol is emphatically TCP-based (however, my concerns also
hold true for WebSocket protocol implementations over other network
protocols, e.g., SCTP). Even "Jumbo Frames" limit the MTU to less than 10K
bytes (octets). Of necessity, a WebSocket frame of more than slightly less
than IP MTU (upon which TCP is reliant) will involve the chunking of the
message into a number of packets, and the reassembly of those packets at the
destination into a single, sequenced stream. This is not negotiable, it is a
fundamental part of TCP, which is in turn dependent on IP.

Even if we were to ignore the overhead and processing of IP and TCP, the
realities of the network make it unwise to use extended frame sizes at the
WebSocket protocol level. Extended frame sizes quickly create large
potentials for network and application problems. Consider the case of a
1Gbps network. 1Gbps translates to a theoretical (emphasis: THEORETICAL)
maximum bandwidth of 125 MB/sec. Sending gigabytes of traffic in one frame
means that the time until the next frame is measured in seconds. This is,
with all due respect, not a realistic presumption, even on a LAN. If one
includes wide area networks, it is even farther from real-world feasibility.

Protocol overhead drops quickly with packet length to a point. Once frame
overhead is well less than 1%, it becomes statistically insignificant. It
is worth noting that Packet Switching was chosen for the ARPAnet because it
solved a number of problems, one of which was latency. Message switching
long predated packet switching, and was well-known to have issues. Hence,
packet switching.

The latency of PING and PONG are directly affected. If an extended length
frame is transmitting, PING and PONG will be delayed. For that matter,
since no event will be signaled until end of frame, seconds could pass
before ANY event is noticed. This is a poor idea, even when transmission
errors are handled at lower levels. I can easily see timeouts being
declared whose root cause is nothing more than a very large frame. [We
have been here before; before ubiquitous broadband, it was common when
running error-correcting modems over direct dialed circuits. It was
difficult to justify to users, and difficult to track down after the
fact. It was not something that is worth repeating.]

In summary, I would be all for limiting the frame size to 16 bits on grounds
of latency and efficiency. Larger frame sizes are not a demonstrable
performance gain. If an application is dependent on the performance
difference between a 64Kbyte frame and a 1Mbyte frame, it in all likelihood
is far too close to the edge of what can be achieved reliably. We do no one
a service by encouraging unreliable design.

- Bob
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  [e-mail]  |
| Robert Gezelter Software Consultant                                      |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                    http://www.rlgsc.com         |
+--------------------------------------------------------------------------+