HDB and \"e\" protocol

[Jonathan Clark]

Lauren Weinstein @ Vortex:
>Actually, the higher speeds reported with the ethernet and direct
>X.25 connection protocols in X.25/ethernet environments 
>is not so much a result of the "error-free" end-to-end (computer-to-
>computer) connection but the result of the end-to-end hardware flow
>control that must be present on such circuits.

Guy Harris @ Sun:
>What hardware flow control?  An Ethernet interface doesn't know whether
>anybody's picking up the packets you're sending; there's no end-to-end flow
>control in Ethernet.  The "e" protocol runs over protocols like TCP that
>*do* provide end-to-end flow control; that's usually not done in the
>hardware, though.

Both authorities are correct but there is some terminology confusion.

Lauren doesn't mean flow control in Guy's sense - he means 'resource
control'. If I write a 4K block down a Ethernet then the remote end is
always able to accept it (expect in rare circumstances) so the data
doesn't have to hang around waiting for the resources to be made available.

The cost of grabbing a 4K buffer when asked, as well as the protocol
overhead of saying 'there is 4K coming your way - let me know when you're
ready' sounds rather large. I can well believe that that and the n (32?)
inter-packet gaps (and the buffer copies saved) are most of the reason for
the speedup.

Lauren also doesn't mean 'hardware flow control' in Guy's sense - he
means 'out-of-band flow control'. In the cases discussed here the flow
control is combined with the rest of the protocol, so comes free.

-- 
Jonathan Clark
[NAC,attmail]!mtune!jhc

My walk has become rather more silly lately.