Subject: RE: Re-visiting the jutification for BEEP

From: "Christian Huitema" <[email-masked]>
Date: Tue, 11 Sep 2001 12:16:54 -0700

> > > And your knowledge about fundamental networking rules has
> demonstrated
> > > a significant  disparity from the knowledge of quite a few other
> > > folks. Any literature references to this fundamental rule would
> > > be appreciated.
> >
> >The effects of layered multiplexing were mostly experienced when
> trying
> >to run stuff TCP/IP on variation of protocols doing their own flow
> >control
> 
> Interesting.  CSNet (the predecessor to NSFNet) ran TCP over X.25 just
> fine.  (There are lots of other examples, but that one rather stands
> out.)

Well, I remember running TCP over the Transpac's X.25 network at about
the same time as CSNET, and my memories would certainly not qualify as
"fine." What did happen quite frequently was that one of the many TCP
connections would send a burst of packets that would saturate the X.25
flow control; this would result in long delays, leading to timers on the
other VCs. The underlying X.25 network, Transpac, may well have behaved
differently than CSNET; the transmission speed were about 9600 bps; so
that may explain the differences. Also, this was before the introduction
of congestion control and the revision of the RTT estimation algorithm.
But I can certainly see variations of the problem happening in BEEP,
e.g. if the buffer estimation at the BEEP layer goes out of whack with
the actual buffer management at the TCP level.

-- Christian Huitema

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Sep 2001 12:39:26 -0700

At 12:16 PM 9/11/2001, Christian Huitema wrote:
>flow control;

Sounds as if Telenet (the provider I was using) had better flow control 
signalling up to the X.25 user level...

>  Also, this was before the introduction

Well it was certainly before the burst of excellent congestion control work 
done in the mid/late 80's, but TCP did have a functioning mechanism, as I 
recall.

>But I can certainly see variations of the problem happening in BEEP,

Please forgive my making a play on your words, but the problem with this 
exchange is not that you "can see" the problems but, rather, "can imagine" 
that they might exist.  However the current specification attends to the 
problem, rather carefully.

If you could "see" problems, you could document them or at least describe 
the failings of the current specification.  So far, no such detailed 
technical analysis of the specification's deficiencies have been forthcoming.

There is, of course, a possibility that the specification is flawed, but 
that is true of all specifications that have not been fielded.  That is why 
we have a 3-stage standards process.  It is NOT, therefore, a basis for 
preventing entering standards track.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464