[Top] [All Lists]

Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???

To: Jes Sorensen <jes@xxxxxxxxxxxxx>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: Matti Aarnio <matti.aarnio@xxxxxxxxx>
Date: Mon, 12 Jun 2000 20:29:48 +0300
Cc: netdev@xxxxxxxxxxx
In-reply-to: <d3zoos42xe.fsf@xxxxxxxxxxxxxxxxx>; from jes@xxxxxxxxxxxxx on Sun, Jun 11, 2000 at 06:07:09PM +0200
References: <Pine.OSF.3.96-heb-2.07.1000610174812.19185A-100000@xxxxxxxxxxxxxxxxxxxxx> <d3og58ewmh.fsf@xxxxxxxxxxxxxxxxx> <39433342.4A9E80CC@xxxxxxxxxxx> <d38zwc5j4z.fsf@xxxxxxxxxxxxxxxxx> <3943C086.930DF571@xxxxxxxxxxxxxxx> <d3zoos42xe.fsf@xxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
  [Cc set truncated..]

On Sun, Jun 11, 2000 at 06:07:09PM +0200, Jes Sorensen wrote:
> >>>>> "Ben" == Ben Greear <greearb@xxxxxxxxxxxxxxx> writes:
> Ben> So just because you don't see a use for it means everyone else
> Ben> should be denied the use of it???  Gleb's argument is valid
> Ben> whether or not IPX exists, because other, so-far-unthought-of,
> Ben> protocols may be created, and they would have the same problem
> Ben> that IPX would now.
> Try to take a look at how IPX behaves on the wire before commenting -
> the people who designed it need serious larting.

        IPX is/was protocol used in XNS networking, which had its
        origins in early Ethernets -- I mean BEFORE the Ethernet
        was standardized to be 10 Mbit/sec.

        As such it worked reasonably well with 2-10 stations in
        the network.   Growing beyond that has proven to be non-trivial..

> Ben> TCP/IP is not the end of the line in network protocols!  At the
> Ben> very least IPv6 will be extremely important in the near future.
> Some people still believe that, I used to think that but I don't see
> the push for it anymore.

        One could say same of IP(v4) multicast.
        Only now the userspace has gotten *some* support for it,
        and all manner of multimedia things are still burning
        network bandwidth for kwazillion point-to-point unicast
        copies of datastreams.

        Of course networks don't very widely support multicast, as
        nobody has called for it because there are no applications
        which would use it, and application writers don't use MC
        because networks don't support it ubiquitously...

        One of the major things which IPv6 has over IPv4 is its seriously
        expanded address space.  However...

        Emergence of NAT/PAT for IPv4 has somewhat reduced the network
        address space explosion with the unpleasant feature of it not
        being completely transparent for all applications.

        New "Realm Specific IP" (RSIP) mechanism requires that hosts
        interact with external RSIP gateway (which NAT doesn't need),
        so in my thinking it is similar magnitude thing to IPv4 for
        the kernel stack.  It isn't quite the same task for e.g. user-
        space, which gets most of RSIP handling "free" from kernel.
        Deployment requires a new kernel, of course.

> Ben> Broad support for almost every protocol known is one of the very
> Ben> best features of Linux.  Doing anything to make that less true
> Ben> would make Linux less useful to the rest of us.
> Broad support for as much as possible is good, but limiting support
> for the mainstream in order to improve support for something broken is
> wrong.

        Hmm.. I think I have already scrubbed the thread start
        so I am not sure what thing you are talking about.

        But on broad terms, in Linux having two competeting
        implementations which have performance differences
        affecting commonly used protocols, performance winner
        gets picked -- usually.

> Jes

/Matti Aarnio

<Prev in Thread] Current Thread [Next in Thread>