[e2e] TCP Framing

RJ Atkinson rja at inet.org
Fri Mar 23 14:23:20 PST 2001


>Moral: Over-engineering may be bad for the Internet, eventually.

        I'm not known for being subtle.  I might have
phrased the above more along these lines:

        "Folks are doing lots of micro-optimisations these days,
        at various points in the stack and in the end-to-end 
        network system.  While a given micro-optimisation might
        be worthwhile in a micro-network, many micro-optimisations
        are being deployed in a haphazard manner in the global
        Internet these days.  The real result is a significantly 
        less robust network for very little (if any) real 
        measurable benefit."

>Finally, an historical irony: the ULP hack is acknowledged to be a
>stopgap until SCTP has advanced to save us.  Essentially, SCTP is OSI
>TP4 with features.  TCP's idea of decoupling API from wire protocol
>units was, at the time of its development a new idea that was at
>variance with the evolving OSI suite.  Now, things seem to be
>running full circle.  

        The property of SCTP that I am hearing the most interest
in is the decoupling of the transport-layer session state from
the actual IP address at each end of the connection.  Lots of
folk seem interested in having a transport-layer session that
could have increased robustness simply by multi-homing each
end-host for the session onto different networks (providing
path diversity).  In this regard, I'm influenced by talking
with folks who are implementing or deploying SCTP for various
purposes.  My sample space is certainly not statistically valid.

        IMHO, if the TCP checksum were bound to some form of
host identifier other than the IP address, TCP could provide
that particular property quite nicely.  Obviously I'm influenced
by conversations with jnc on this particular point.  It would
be an interesting exercise to work out the details for such
an approach.

        All that noted, I could imagine using SCTP underneath
a suitably generic API.  It isn't clear to me that the API
has to necessarily be as tightly coupled as is the case in
some SCTP API proposals.  Mayhap I'm confused.

Cheers,

Ran
rja at inet.org





More information about the end2end-interest mailing list