Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]

[John Day <[e-mail]>]

Let me get this straight, Brian.  It would seem you are pointing out 
that the IETF does not have a clear idea of what it is doing?  ;-)  I 
could believe that.

No, your example is not an example of what I suggested at all.

Yours is an example of not specifying the conditions that a 
congestion control algorithm must have rather than the congestion 
control algorithm itself.

What I was suggesting (and it is very easy trap to fall into) was 
defining a spec with one implementation environment in mind and not 
realizing you are constraining things unnecessarily. Consider the 
difference between defining TCP as a state machine with that sort of 
implementation in mind and building an implementation in LISP. (I 
know someone who did it.)  It would be very easy to make assumptions 
about how something was described that made a LISP implementation 
unduly messy, or missed an opportunity for a major simplification.

It is quite easy to do some thing mathematical in this area (not 
necessarily alluding to formal specification), but you do have to 
have a clear concept of the levels of abstraction.  Of course, once 
you do, you still have the question whether there is a higher 
probability of errors in the math or the program.

Yes, programming is just math of a different kind, which of course is 
the point.

Take care,
John

At 1:31 PM +0000 1/7/13, Brian E Carpenter wrote:
>On 07/01/2013 12:42, Stewart Bryant wrote:
>>  Indeed an interesting additional question.
>>
>>  My view is that you MUST NOT use RFC2119 language, unless you MUST use
>>  it, for exactly that reason. What is important is "on the wire" (a term
>>  that from experience is very difficult to define) inter-operation, and
>>  implementers need to be free to achieve that though any means that suits
>>  them.
>
>Agreed. Imagine the effect if the TCP standard had said that a particular
>congestion control algorithm was mandatory. Oh, wait...
>
>... RFC 1122 section 4.2.2.15 says that a TCP MUST implement reference [TCP:7]
>which is Van's SIGCOMM'88 paper. So apparently any TCP that uses a more recent
>congestion control algorithm is non-conformant. Oh, wait...
>
>... RFC 2001 is a proposed standard defining congestion control algorithms,
>but it doesn't update RFC 1122, and it uses lower-case. Oh, wait...
>
>RFC 2001 is obsoleted by RFC 2581 which obsoleted by RFC 5681. These both
>use RFC 2119 keywords, but they still don't update RFC 1122.
>
>This is such a rat's nest that it has a guidebook (RFC 5783, "Congestion
>Control in the RFC Series") and of course it's still an open research topic.
>
>Attempting to validate TCP implementations on the basis of conformance
>with RFC 2119 keywords would be, well, missing the point.
>
>I know this is an extreme case, but I believe it shows the futility of
>trying to be either legalistic or mathematical in this area.
>
>    Brian