.....snip
>
> OK. I have been a ham for 27 years (WB9SML, now N9FCW). I have used
> AX.25 and TCP over packet radio for almost as many. I am great admirer
> of Phil K who frequencts this list. Nevertheless, this "packet radio"
stuff was
> great back in the early 80s! Today's radios are DSSS with huge bandwidths
> and incredibly capabilities that are VERY poorly harnessed by the IP
community
> and mostly completely wasted.
>
I said this already - I did not mean the amateur PR stuff but the ARPA PR
development
which was quite another thing - including spread spectrum and high mobility.
> > And this has significantly influenced the design
> > of the IP and TCP protocols when the Old Arpanet NCP had to be
redesigned
> > for a more heterogeneous and wireless environment!
>
> Yes, and it worked fine for non-realtime, non-commercial, best effort
traffic on
> a relatively lightly loaded and a much smaller global Internet. The
bu$iness world
> wants more. MUCH more. Mobility is a "chargeable" service. Why aren't
> mobile Internet service providers popping up? Because its hard too do.
Why is
> it hard to do? Because the IETF has become pompous and monolithic and
> slow to change. IP IS NOT PERFECT! IP over everthing inspired a huge
> growth spurt along with the WWW. Instead of standing around in awe at the
> marvelous Internet, can we get on with improving it finally????
>
IP IS NOT PERFECT! - sure but that also goes for many other widely deplyed
systems. As Alan Perlis(?) once said about Fortran "it is not a flower but
a weed -
and it grows in every computer!
> > Maybe instead of relying on a connection-oriented subnetwork and dealing
> > with "handover" problems it might be better tu use a basic datagram
> > subnetwork (remember - IP does not necessarily require a "link" layer
but
> > assumes what used to be called a "local network") and put the complexity
of
> > signaling and end-to-end aspects on a higher layer.
>
> Jeesh, how can a high layer work blindly! You are making my point for me!
> >
> > IP delegated these tasks to TCP - but TCP suffers from the fact that it
does
> > not get any information what happened inside the network, so it has to
>
> EXACTLY!!!!
>
> > implement artefacts such as slow start and a separate congestion window
in
> > order to do a good job. In my opinion this is the real problem we are
facing
> > and the question remaisn whether this is a "protocol" issue or an OS
issue;
> > in this respect I like the ISDN Refernce model which has separate
"planes"
> > for these aspects.
>
> ...and these issues with TCP are complained about bitterly in the various
> transport WGs. Isn't the solution becoming obvious???
>
For very good reason the ISDN people have come up with a 3-dimensional
Reference Model where certain aspects of signalling, resource management and
inter-layer coordination are delegated to separate planes in "the third
dimension".
TCP has attempted to resove some of these problems and it seems to me that
we are now attempting to look for simioar kludges for IP - instead of
accepting
the fact that we need a "control" plane with its own protocols for
inter-layer
coordination and singaling.
The question is: should the IETF get into this field or not? IMHO - if I
look at
what is happening with MPLS we are already in there!
> >
> > TCP has never been designed as a real-time end-end protocol; maybe the
> > wireless people ought to define such a beast on top of IP and use the
packet
> > radio techniques for the wireless network instead.
>
> We are in the process, but we keep running into people that want to impede
> our progress!! :-) The first step in building a closed loop control
system for
> handover, mobility, routing, and QoS is the feedback loop, i.e. L2
TRIGGERS!!!
>
Again - is it the IETF or some other body who should do this.
> quod erat demonstrandum
>
>
_______________________________________________
pilc mailing list
pilc@ietf.org
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/
This archive was generated by hypermail 2b29 : Tue Jun 11 2002 - 20:43:56 EDT