[ColorForth] reinventing the internet?

[Dirk Harms-Merbitz <dirk@xxxxxxxxx>]

On Wed, Dec 05, 2001 at 11:23:06PM +0000, Jeff Penn wrote:
> Hi Jeff
> 
> 
> > Dirk Harms-Merbitz wrote:
> > > 
> > > IPv6 is simpler then IPv4. It has extension headers.
> 
> What are your reasons for believing IPv6 is simpler?.  It is more extensible
> than IPv4 to enable it to support new services, but the stack would require
> significantly more overhead on a client.  

Header has fixed length for once. Much of the more complicated parts have been
moved into extension headers which can be ignored if you don't need the functionality.

There was a conscious effort during protocol design to support hardware based
implementations.

> IPv4 is showing its age.  For example, it is unable to distinguish between
> congestion & delay, it also performs poorly over high bandwidth connections.

IPv6 attempts to address most of those issues.

Seriously, I think we should implement IPv6 first.

Linux boxes can act as gateways to IPv4 if necessary.

> > 
> > I don't understand why UDP can't be used functionally
> > for most things that use TCP/IP.  Why is the
> > sorting of scrambled packets and complex recovery
> > and timeout mechanisms so important everywhere?
> > I want to know more.
> 
> It's a matter of where you want to manage the reliable transfer of data.
> You can use UDP and add your own mechanisms to manage the connection (as
> with as Sun's NCP).  You come unstuck when you try to run over a congested
> WAN or LAN which will make connectivity unreliable.
> 
> > understand not why it is complex, but why
> > that complexity is required in most internet
> > apps but not others.
> 
> Most apps will use connection oriented services because it makes the
> application simpler to code.  Since TCP is support is by default available
> in everything from super-computers to fridges it makes sense to use it.
> 
> > 
> > If UDP works so well on video for instance, why
> > is the more complex protocol required so often
> > for things that seem less demanding to me?
> 
> Alot of work has been put into developing standards to provide management
> of traffic on data networks.  Virtual LANS (VLANs) enable devices attached
> to the same LAN to be segregated and appear to be on separate networks.
> VLANs can be managed to provide desired throughput/qos levels.  Some of
> the VLAN traffic may be encrypted &/or authenticated.  Different types of
> data requiring different service levels (such as video and ftp) may take
> different paths to the same destination network.  All this functionality may
> be provided by the switch/router.
> 
> > Just because it is a standard that is being
> > used on the other end?  There must be some
> > valid technical reasons why the simpler one
> > isn't used more.  Can you try to educate us
> > about that?
> > ------------------------
> Using IP over a dialup connection is a poor use of limited resources.  Much
> more effiecient use could be made of the link using a specialised protocol.
> 
> The most effiecient way to provide connectivity would be to use a serial
> comms protocol similar to zmodem/kermit to connect to a server.  The server
> would provide services such as internet connectivity (similar to fidonet).
> 
> A more workable solution may be to use PPP.  PPP was originally designed
> for serial connectivity, but can now be encapsulated over ethernet.  You can
> also chose to add other features such as multi-link support, encryption,
> compression, authentication, & network login through a RADIUS server.
> Although this may be overly complicated :-).
> 
> Jeff
> -- 
>  Jeff Penn - jeff@xxxxxxxxxxxxxxxxxx (Demon Internet Dial-Up)
> 
>  Connecting via Demon Internet Ltd
> ------------------------
> 
> To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
> unsubscribe ColorForth
> as the first and only line within the message body
> Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
> Main ColorForth site   -   http://www.colorforth.com
> 
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe ColorForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main ColorForth site   -   http://www.colorforth.com