[ih] GOSIP & compliance

[Craig Partridge]

Hi John:

The answer at the time ran as follows.  X number of datagrams are sent from
the monitored station to the monitoring center (let's say X is 4) and all
but one are discarded in the routers due to congestion loss.

In UDP, 1 datagram gets through -- one hopes with useful data -- in a
timely way.

In TCP, unless the 1 datagram that gets through is the first datagram, you
get nothing until the missing datagrams arrive to move the window forward.
So you get substantially delayed or not data, as in many cases in the
1980s, the connection would instead fail.

Craig

On Sat, Apr 2, 2022 at 11:26 AM John Day via Internet-history <
internet-history at elists.isoc.org> wrote:

> Please explain how UDP packets are less susceptible to congestion than TCP
> packets?  I would really like to know.
>
>
>
> > On Apr 2, 2022, at 12:41, Greg Skinner <gregskinner0 at icloud.com> wrote:
> >
> >
> >> On Mar 28, 2022, at 11:19 AM, John Day <jeanjour at comcast.net <mailto:
> jeanjour at comcast.net>> wrote:
> >>
> >> Just to add to the comments,
> >>
> >>> On Mar 28, 2022, at 12:48, Craig Partridge via Internet-history
> <internet-history at elists.isoc.org <http://elists.isoc.org/>> wrote:
> >>>
> >>> The UDP vs. TCP debate was pretty fierce and the experience of the time
> >>> came down firmly on the UDP side. Recall this was the era of daily
> >>> congestion collapse of the Internet between 1987 and 1990.
> >>
> >> Somehow this argument (which I know was intense at the time) is the
> most absurd. All of the functions in TCP that are relevant are feedback
> functions that only involve the source and destination. In between, the
> handling of UDP and TCP packets by the routers is the same. If anything,
> TCP packets with congestion control have a better chance of being received
> and a TCP solution would have required fewer packets be generated in the
> first place. (The last thing a management system should be doing when
> things go bad is generating lots of traffic, but SNMP was good at that.)
> >
> > No argument from me about management systems generating too much
> traffic.  However, regarding congestion control, around 1987, mitigation
> was underway, but solutions that were widely deployed in TCP/IP
> implementations were still a few years off.  That helped make UDP more
> attractive, at least in the short term.
> >
> > […]
> >
> >>> There was a network management project in the late 1980s, name now
> eludes
> >>> me but led by Jil Wescott and DARPA funded, that sound similar in
> goals to
> >>> what Jack H. describes doing at Oracle.  I leaned on wisdom from those
> >>> folks (esp. the late Charlie Lynn) as Glenn Trewitt and I sought to
> figure
> >>> out what HEMS should look like.
> >
> > Right.  From the tcp-ip mailing list and Usenet newsgroup, January 1987:
> >
> > ——
> >
> > Date:      Tue, 20-Jan-87 12:12:04 EST
> > From:      leiner at ICARUS.RIACS.EDU <mailto:leiner at ICARUS.RIACS.EDU>
> > To:        mod.protocols.tcp-ip
> > Subject:   Re: Gateway Monitoring
> >
> > Craig,
> >
> > As you probably are aware, there has been quite a bit of work done
> > already in "monitoring".  In fact, Jil Westcott at BBN has been doing
> > some work in automated network monitoring related to ADDCOMPE and packet
> > radio networks.  There have also been several proposals for "monitoring
> > protocols".
> >
> > I'm happy to see you working in this area.  It is clearly critical for
> > large internets like NSFnet and the evolving national research internet.
> > Hopefully, with this new push, a "standard approach" can be developed.
> >
> > Barry
> >
> > ——
> >
> > BTW, interested readers can see discussions on this and related topics
> at the ban.ai TCP/IP mailing list archive <
> https://ban.ai/multics/non-multics-docs/tcpip-digest/sd-archive/archive/>.
> (You may get a message indicating SSL certificates have expired.)
> >
> > —gregbo
> >
> >
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.