[e2e] Open the floodgate

Jonathan M. Smith jms at central.cis.upenn.edu
Wed Apr 28 14:47:03 PDT 2004


There were also a batch of good ideas in the TP++ work done by Dave
Feldmeier, et al. at Bellcore.
								-JMS


On Wed, 21 Apr 2004, Jon Crowcroft wrote:

> let me just clarify what i was reacting to, as some people may not recall the XTP
> debate, and I may also have misinterpreted noel's use of the term.
>
> XTP suffered from several problems, not just the kitchen sink and bandwagon, but also from a massive NIH
> allergy it incurred in the early e2e community (nih != national institute of health, although they could well do
> with initiating a study into Not Invented Here syndrome for psychological well being reasons).
>
> XTP contained several ideas on protocol implementation, which, while a little underbaked, were quite cutting edge
> (remember we are talking 85/86 here) - for example, they revisted the integration of layers 3/4 (and 2 on LANs) as
> did VMTP, and this was for a variety of reasons we now understand to be good (performance by cutting layer crossing
> overheads - viz clark/tenennhouse ILP/ALF work) - they revisited rate versus window and had the packet train idea
> (see also VMTP, Netblt and so on) which retains stat mux properties when goign through a set of routers with other
> bursty traffic, but could (if done right) lead to smoother rate varation than the AIMD work that dominated shortly
> afterwards until recently. They looked at hardware accelerators (see work on packet processors from many in last
> few years, again, e.g. Intel, Procket etc). they even looked at trying to understand protocol correctness. The
> design was modular (component oriented transport has reappeared inthe IETF in the RMT working group) and they
> provided relaible multicast, with network information so that source routed messages could be used to avert
> problems with retransmits and so on and so on....
> connection management (and i already mentioned dccp, sctp with different multiplexing goals, and should probably
> also have said xcp) is something else that has been revisited in the light of persistence, different session
> lifetime models, different attacks to concern oursleves with, nat traversal and stateful 'firewall/router' world
> to worry ourselves with...
>
> aside from the personality problems (and you can find the tech. debates on e2e archives and elsewhere
> comp.protocols.somethingorother probably, even alt.disorder.internet i expect), the committee/bandwagon effect, and
> just Too Many Things at one go doomed it....
>
> but in the community that were the True Defenders of the One Faith of TCP, it became short hand for "Bad Idea" - i
> think i may be being a bit of a revisionist, but I dont think One True Fair, or Bad Idea type discussions help us
> with moving along. there are pieces of XTP worth understanding....
>
> and there are other protocols worth reading up on (TP4, delta-t, VMTP, etc) which also have things to offer. and we
> need to stay abrest of the new techniques (control theory for rate and window management, information theory for
> transmssion on wireless) that mean we can do things that were NOT done in the past, or if done, only understood
> through a glass, darkly
>
> anyhow, back on topic, the Binary Increase/search stuff (as per infocom paper) is one of several (see Injong,s FAQ)
> attempts to revist the throughput for networks with bandwidth/delay products we could only dream of in the 1980s,
> but with loss rates we were all too familiar with...
>
> btw, I just spent 1 hour last night talking to a New Scientist journalist who had got a bee in his bonnett about
> The GRID being a great potential threat to world security - I am just waiting for the headline
> "SuperComputers on the Internet-  Are Weapons of Mass Destruction already amongst us?"
> or some such tosh:-)
>
>
> In missive <4085EA1C.A0790398 at attglobal.net>, Cannara typed:
>
>  >>2nd to that Jon.  Enough decades have passed for TCP improvements to be
>  >>allowed without knee-jerk dismissal of ideas, even if they're other than
>  >>committee-approved works of 'genius', say like IPv6.  Of course, TCP is just
>  >>one part of the flow and the problem these days.
>  >>
>  >>Alex
>  >>
>  >>Jon Crowcroft wrote:
>  >>>
>  >>> I'm not sure what your point is
>  >>>
>  >>> XTP had a LOT of good ideas but was a kitchen sink protocol
>  >>> by the time everyone climbedon the bandwagon
>  >>>
>  >>> TCP has a few good ideas - most of which were NOT n the original design - for exasmple despite Postel's wortk on
>  >>> correctlness using petri nets, t here were several bugs in the state machine (see ian heavens (RIP) discovery
>  >>> relatively late) plus the byte stream nature and lack of optimal packet exchange or nonce/syn cookie meant that
>  >>> there were loadds of KNOWN attacks (with known solutons)
>  >>>
>  >>> all the stuff vj did on header prediction/40 instricton per packet, and criag and others on rtt estimation, and
>  >>> the berkeley/kk ramakrishanna/raj jain/vh congestion control was dne welll after the oritinal work and coudl (and
>  >>> WAS ) donr to other protocols too (decnet transport)
>  >>>
>  >>> the actual work on BIC (as opposed to the crap written by the reporter) is a delta to TCP much like FAST,
>  >>> scaleable, highspeed, all of which the real work cites...
>  >>>
>  >>> i wonder if you have ever read vinnecombe's control theoretic work on TCP, or the dccp and sctp work on secure cx
>  >>> setup, or the stuff people have actually invented since the boring old farts like thee and me actually had a new
>  >>> idea...there are people trying to move right along, despute carping or journalism, and it ill behoves us to diss
>  >>> them without reading more.
>  >>> stet
>  >>>
>
>  cheers
>
>    jon
>


More information about the end2end-interest mailing list