Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!think!Think.COM!barmar
From: barmar@Think.COM
Newsgroups: comp.protocols.tcp-ip
Subject: Re: more on Fletcher
Message-ID: <32096@news.Think.COM>
Date: 9 Dec 89 01:08:43 GMT
References: <8912060542.AA05854@WLV.IMSD.CONTEL.COM> <1989Dec6.190415.19049@brutus.cs.uiuc.edu> <18511@bellcore.bellcore.com> <8912071916.AA23996@beaches.hub.toronto.edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA
Lines: 28

In article <8912071916.AA23996@beaches.hub.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
>In my view, data integrity can be effectively provided by chaining
>together reliable links
...
>When does this approach fail?  Obviously, if your packets are going
>over a network you know nothing about, or have no control over, it is not
>safe to make assumptions about its error properties.  In that case,
>higher-level error detection does make sense, but it should be provided
>as an option, or perhaps as a gateway function, and it need not be
>application-to-application.

This is probably true.  It does mean that the interfaces between the
transport and link layers must provide ways of querying about the error
properties of the path that datagrams will take.  This, however, implies that
the route is fixed, or at least can be determined ahead of time.  IP uses
dynamic routing at the packet level (caller-specified routes are possible,
but out of the ordinary).  A call to TCP_WRITE may result in multiple IP
datagrams, which may be fragmented into multiple link layer packets, each
of which may take a different route.

Also, there are very few links with the kind of reliability most
applications would like.  Ethernet is usually considered a reliable medium,
but when we had UDP checksums turned off on our Suns I saw lots of NFS
problems between hosts on the same Ethernet.
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar