Re: TCP MSS issue

From: Vernon Schryver (vjs_at_calcite.rhyolite.com)
Date: 12/26/04

  • Next message: Walter Roberson: "Re: TCP MSS issue"
    Date: Sat, 25 Dec 2004 23:32:16 -0700 (MST)
    
    

    In article <cql0fs$6ib$1@canopus.cc.umanitoba.ca>,
    Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:

    >:I_SRDOPT is an option for Streams and not for TCP. It works if a
    >:transport protocol honours this option. TCP is certainly not one of it.
    >
    >Emil, TCP can (and has been) implimented in terms of STREAMS.

    As far as I know and recall, there have been two major implementations
    of TCP/IP in System V STREAMS. The first was done by people at Lachman
    (perhaps Steve Alexander?) for AT&T and was part of what wrecked AT&T's
    suit against BSDI when it came out that AT&T had been shipping the
    Regent's code without the Regent's copyright legends. Judging from
    my diffs with with the SVR4 source, it consisted of the BSD 4.3 TCP/IP
    of various flavors jammed into STREAMS modules. The second was the
    from-scratch Mentat code that Sun shipped in a paniced reaction to
    that legal stuff.

    >The following are from the SGI IRIX man pages:

    Please check the IRIX kernel source instead of trying to infer from
    man pages, which themselves were related to BSD and SV man pages.
    I think you'll find that IRIX STREAMS TCP/IP was really a wart on top
    of and beside good old 4.3 BSD SOCKETS TCP/IP, including Sam Leffler's
    protocol switch, Van Jacobson's slow-start, ack-pacing, and
    header-predicting, etc.

    Well, there is (or was?) also the other, later STREAMS-related wart
    underneath among the interfaces, ostensibly to support SAPs. What was
    that over elaborate, committee designed, utter disaster of a driver
    abstraction called? I though it stupid because it required upper
    layers to do things like handle the differing bit orders of IEEE MAC
    addresses for 802.3 vs. FDDI.

    (Survey the $author$ tags in RCS logs of the IRIX kernel TCP/IP and
    STREAMS code to see the basis of those claims.)

    > For STREAMS files [see intro(2)], the operation of write is determined by
    > the values of the minimum and maximum nbyte range (``packet size'')
    > ...

    That seems to be confusing the SRV3 STREAMS in IRIX with the BSD
    SOCK_STREAMS also in IRIX--at least as of IRIX 6.?.

    >There is no mention at all of sockets in the write(2) man page, but the
    >section on STREAMS describes fragmentation into packets. Would it not
    >be rather strange to describe in detail packet fragmentation for the
    >obscure STREAMS and yet not even mention sockets at all, let alone
    >describe their fragmentation rules, unless sockets are indeed a kind of
    >STREAM ?

    Things are indeed strange, undreampt of things in heaven and earth.
    20 years ago were already "streams," "STREAMS," "SOCK_STREAM," and
    many other kinds of canals, rivers, creeks, pipes, aqueducts, and
    other flowing things, all different and related.

    As I see things, no one in their right minds writing a STREAMS module
    for the TCP state machines would handle dividing data into segments much
    differently than the BSD code does. TCP is what it is. If you are
    building T/TCP, UDP, RDP, or something else, you might do other things.

    I recognize the names of some contributors to this thread. Greetings.
    You guys are still far more gentle than I am.

    Vernon Schryver vjs@rhyolite.com


  • Next message: Walter Roberson: "Re: TCP MSS issue"