Subject: RE: description of recovery mechanisms

From: [email-masked]
Date: Fri, 9 Mar 2001 15:54:31 -0500

Julian,

> If you mean a complete formal description (including state charts) the
last
> complete description I've seen was the SNA manual and that was many years
> ago (and included hundreds of pages on recovery alone).  I've tried to go
> into enough detail so that an implementation should be possible and given
> the amount of options possible I am afraid that either we give them all
and
> that is an inordinate (and wasteful) amount of work. None of the major
> TCP/IP protocols have it and they have all added details in a pragmatic
> fashion.

The underlying issue here is that "given the number of options possible"
it's almost certainly possible for implementers to choose different sets
of options in a way that the implementations don't interoperate.  If it
takes state charts to prevent this, so be it, and if that's "an inordinate
(and wasteful) amount of work", then the option space needs to be
dramatically reduced in size.  The requirement is not for state charts
per se, but for a sufficient level of clarity and explanation of important
details that independent implementers applying the same text to different
implementations wind up with results that interoperate (or that fail
to follow the explicit instructions given in the text).  TCP error
recovery is specified in excruciating detail down to minor tweaks in
the retransmit algorithms.

I hope this is clear ... because if this isn't done right, it will have to
be
done over courtesy of the draft not making it through WG Last Call.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Glen Turner <[email-masked]>
Date: Sat, 10 Mar 2001 15:06:53 +1030

Julian Satran wrote:
> None of the major TCP/IP protocols have it and they have all added
> details in a pragmatic fashion.

Black David replied:
> TCP error recovery is specified in excruciating detail down to
> minor tweaks in the retransmit algorithms.

That lack of detailed state diagrams for TCP notoriously
lead to an undefined state that needed to be clarified
in a later RFC.  There was then a lot of work, recorded
in the academic literature, to check that no other undefined
states existed.

And, as illustrated in earlier work in this list, we are
still suffering in a lack of precision in the definition
of TCP's Urgent field.

Glen