[e2e] end of interest -- BP metadata / binary vs text

[John Day]

At 10:36 -0400 2008/05/11, David P. Reed wrote:
>"Traditional layering" my a**.  When the present Internet 
>architecture was constructed in the 1970's there was no OSI model at 
>all.  It would be revisionist (alas too common) to imagine that the 
>*goal* of communications architecture is to fit into a frame (OSI) 
>that was conceived ex post as merely an explanatory tool for the 
>decisions about modularity that were made on far more serious 
>grounds than a mere picture of a stack.

;-) lol.  Ophelia methinks thou doth protest too much!   I don't 
remember anyone mentioning OSI.  If there is any revisionist history, 
Dave it is yours.

I don't remember who said it, but when I refer "traditional layering" 
I am referring to the ideas we had of it prior to OSI.  "Traditional" 
layering did predate the OSI model by probably 5 years or more. 
Bachman's 7 layers (OSI) were proposed in 78.  I remember that by at 
least 72 - 73, it was common to talk about Physical, Data Link, 
Network and Transport Layers.  In the ARPANet, we weren't sure what 
was above that.  But ARPA shut down our attempt to find out in 1974. 
The Internet architecture was basically modelled on the CYCLADES 
network, which used the same separation of a connectionless network 
layer called CIGALE (corresponding to IP) and an end-to-end transport 
layer called TS (TCP).  CYCLADES was up and running by 74.

Everyone pretty much agreed on the lower 4. It turns out we were 
close but wrong.  (This was in that idyllic period when all of the 
non-PTT research networks were collaborating and just as the world of 
politics foisted itself on us. In around 75, we found out about X.25 
and were horrified.)  Charlie (Bachman) working alone used the lower 
four everyone was talking about and took a stab at what he thought 
was above transport (the upper 3) and got them wrong as well.  By 83, 
OSI had figured out there was only one layer on top of Transport, but 
politics prevented a revision, so the protocols were written so the 
clueful could build them as a single state machine.  However, it 
turns out that they were wrong for other reasons as well.

>The "end to end argument" was a pattern of argumentation used to 
>organize architectural thinking.
>
>I am afraid that those who treat the RFCs as scripture from high 
>priests mistake dogma for thoughtfulness.

Indeed. I have always been amazed at how people treat these things as 
gospel or worse: design specs! ;-)  They are distinctly thoughtful, 
especially the earlier ones before politics became so strong. Even in 
ITU, OSI and IEEE specs the same can be said.  Although separating 
the politics is more difficult there.  And in all cases, they 
represent our best understanding at the time. And if we are really as 
good as we say we are, that too will change.

>
>RFCs started out as a frame for discussion.  For making convincing 
>arguments.  The act of granting an RFC a number does not (anymore 
>than acceptance at a peer reviewed journal does not) create a "fact" 
>or a "truth".

RFC started out being RFCs!  ;-)  They really were Requests for 
Comments.  I still find it disturbing/ironic that an *RFC* is in 
effect the "standard" and an Internet-draft which sounds like it 
should be a draft "standard" is an RFC.  Boy, we don't have anything 
on Alice or the ITU!

>
>And now many on this list (which used to be above all that) behave 
>like Talmudic scholars or law professors - somehow thinking that by 
>studying merely the grammar and symbols we can ascertain what is 
>right, what is good, or what is fit to purpose.

Not me, bro!  I knew all those early guys and hell, we were just 
trying to stay ahead of the game!  The one I like though is hearing 
people explain why things I know were kludges are insightful pieces 
of design.  Hate to think what they would think if they ever saw what 
we had in mind but didn't get to do.  Best they don't find out. All 
that bowing would be embarrassing!  ;-)

>
>The essential valid measure of DTN ideas is that they work, and will 
>continue to work well, *to organize the solution* to an interesting 
>class of real-world problems.   It is irrelevant whether they 
>provide the basis for destroying some "traditional paradigm" and 
>creating a new religion.

The trouble is we do have a religion and one that is poorly 
understood and full of misconceptions and myths.  And we don't do a 
good job of debunking it to keep the inquiry fresh.  Much of this 
came about from the bunker mentality we were conditioned into during 
the fights with the PTTs. Some of it is the natural behavior of new 
converts.  I believe the real failure has been academics and textbook 
authors who should have been distilling general principles and 
pointing the way rather than merely reporting what was out there.

To some degree this brings us back to the discussion of a week or so 
ago, about research vs engineering the Internet.  As researchers, we 
were wont to let go of our creation.  And the war with the PTTs 
helped by forcing us to protect it.

O, well, too much rambling.

Take care,
John

>
>What made the Internet architecture useful was its attention to 
>"interoperation" and to facilitating support of "unanticipated" 
>applications and implementation technologies.  It framed those 
>things well, making progress possible.  DTN ideas frame a new set of 
>issues well - communcations that occur between entities that occupy 
>discontiguous regions of space-time influence.   Such communications 
>have always existed (books communicate across time in personal and 
>public libraries, postal letters transcend spatial barriers in 
>self-contained form) - DTN's merely ratify their importance by 
>focusing framing on those issues.
>
>
>
>Rajesh Krishnan wrote:
>>
>>Granted this matches the viewpoint presented in RFC 5050 of BP's
>>(non-threatening ;) relationship to TCP/IP.
>>
>>By including forwarding and dynamic routing (L3?), retransmissions (L4?
>>and L2?), and persistent storage and application metadata tagging (L7?)
>>concerns within the same protocol, BP does not fit harmoniously at L5 of
>>the TCP/IP Internet, IMHO.  This challenge to traditional layering is
>>precisely what I find most fascinating about DTN.
>>
>>With the CLA/BP split, there is still layering in DTN; just that the
>>layering is not congruent to conventional TCP/IP layering.  Effectively,
>>DTN/BP seems to relate to TCP/IP more or less the same way IP looks at
>>other network technologies.  At least that is my interpretation of
>>DTN/BP as an overlay abstraction (TCP/IP is relevant only as expedient
>>means for early deployment.  ;)
>>
>>I am speaking only for myself here (not past or present employers or
>>funding agencies or IRTF WGs), and this thread ought to migrate to
>>dtn-interest perhaps.
>>
>>Best Regards,
>>Rajesh
>>
>>
>>
>>