> I think the original intent was to use the mtu of the interface only if the > remote peer was directly attached to the same net. I was going to make the > code do this but there appears to be little interest so I didn't bother.
The original intent was as you say, Jim. It was a quick hack for a product that was supposed to die years earlier. The thinking was that sending jumbograms on a single LAN segment was a sure win, sending them through one router hop was almost certainly a win, but sending them through increasing numbers of routers was increasingly asking for trouble. The rationale behind four rather than three or five frags in a jumbogram was based on measurements of contemporary CPUs, and observation of diminishing returns beyond four frags, and the fact that Cisco routers of the period when configured with "fast" queues rather than "deep" ones could only buffer four frags from a single LAN segment. The original implementation of jumbograms only put one RX header on a jumbogram, and the RX packet-handling overhead was (still is) substantial. Subsequent revisions of RX reintroduced the per-packet overhead for an MTU-sized hunk of bytes. The "right" solution is to streamline the implementation, or to pitch RX entirely. What's the current state of ECN in the world? _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
