IPv6 Demonstration - Getting the wow factor? - TCP-IP

This is a discussion on IPv6 Demonstration - Getting the wow factor? - TCP-IP ; I am in charge of setting up a demo for a client for a small IPv6 lab to demonstrate some of our capabilities. Currently, we are using IPv6 tunneling through an IPv4 network, with various IPv4 and IPv6 web servers ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: IPv6 Demonstration - Getting the wow factor?

  1. IPv6 Demonstration - Getting the wow factor?

    I am in charge of setting up a demo for a client for a small IPv6 lab
    to demonstrate some of our capabilities. Currently, we are using IPv6
    tunneling through an IPv4 network, with various IPv4 and IPv6 web
    servers and IPv6 network cameras.

    It is a pretty quick task to show, hey you can access IPv4 and IPv6
    web pages seamlessly, and you can show feeds of digitial video of IPv6
    cameras, but at the end of the day, this leaves you saying "so what"?
    It is kind of difficult to demonstrate "protocols".

    In essence I need something with a little bit of wow factor in
    something that really doesnt have that much.

    I am curious about some other good ideas to just show the capabilities
    of IPv6 with a couple IPv4 routers, cameras, enabled workstations,
    etc. I would like to show maybe some security issues, maybe some
    gotchas if you just plug up IPv6 and dont really take security into
    account, just something that makes you say, "hey this IPv6 thing could
    be good for us".

    I appreciate any thoughts.

  2. Re: IPv6 Demonstration - Getting the wow factor?

    On Apr 1, 10:32*am, Whatever I Fear wrote:
    > I am in charge of setting up a demo for a client for a small IPv6 lab
    > to demonstrate some of our capabilities. *Currently, we are using IPv6
    > tunneling through an IPv4 network, with various IPv4 and IPv6 web
    > servers and IPv6 network cameras.
    >
    > It is a pretty quick task to show, hey you can access IPv4 and IPv6
    > web pages seamlessly, and you can show feeds of digitial video of IPv6
    > cameras, but at the end of the day, this leaves you saying "so what"?
    > It is kind of difficult to demonstrate "protocols".
    >
    > In essence I need something with a little bit of wow factor in
    > something that really doesnt have that much.
    >
    > I am curious about some other good ideas to just show the capabilities
    > of IPv6 with a couple IPv4 routers, cameras, enabled workstations,
    > etc. *I would like to show maybe some security issues, maybe some
    > gotchas if you just plug up IPv6 and dont really take security into
    > account, just something that makes you say, "hey this IPv6 thing could
    > be good for us".
    >
    > I appreciate any thoughts.


    Good luck.

    One of the hyped-up "advantages" of IPv6 is the supposed security
    advantage. It simply does not exist.

    What IPv6 did in the past, at least on paper, is to mandate IPsec in
    all hosts and all routers. Guess what? (1) There is nothing to prevent
    you from implementing the very same IPsec protocols in IPv4 nodes, and
    (2) there are plenty of IPv6 stacks out there that don't do IPsec
    anyway.

    As a matter of fact, just how much and specifically what security
    protocols should be mandated for IPv6 nodes is a matter of debate as
    we speak, within the IETF. But be that as it may, there is nothing
    INTRINSIC in IPv6 that creates a more secure environment. That's the
    bottom line. For what it's worth, RFC 4294 is being updated to reflect
    some of these debates.

    I know this doesn't help your cause. I'm just trying to introduce some
    reality.

    Bert

  3. Re: IPv6 Demonstration - Getting the wow factor?

    On Apr 1, 1:11*pm, Albert Manfredi wrote:
    > On Apr 1, 10:32*am, Whatever I Fear wrote:
    > > In essence I need something with a little bit of wow factor in
    > > something that really doesnt have that much.


    Take 10 IPv6 laptops and space them 50 meters apart.

    Take another IPv6 laptop and drive in your vehicle past the 10 IPv6
    nodes, with FTP session active, and show that the transfers continue
    essentially uninterrupted. Set this up this configuration in real-
    time, while your audience is watching, in under 10 minutes.



    > As a matter of fact, just how much and specifically what security
    > protocols should be mandated for IPv6 nodes is a matter of debate as
    > we speak, within the IETF. But be that as it may, there is nothing
    > INTRINSIC in IPv6 that creates a more secure environment. That's the
    > bottom line. For what it's worth, RFC 4294 is being updated to reflect
    > some of these debates.
    >
    > I know this doesn't help your cause. I'm just trying to introduce some
    > reality.


    Albert is right. IPv6 is, unfortunately, in 2008, highly overrated.
    This is what happens when duct-tape something as important at a system
    that is supposed be used by more than 10 billion people in its mature
    state: you end up with something that begins to rot in its own waste.

    Truth is, there probably is nothing you can do to wow your audience.

    The wow factor comes from applications, not necessarily the protocols,
    and since IPv6 does not exactly facilitate the creation of wow
    applications, you have no wow applications to show, and all you are
    left with is a protocol, which just so happens to be a mess to look
    at.

    -Le Chaud Lapin-

  4. Re: IPv6 Demonstration - Getting the wow factor?

    How are we supposed to know how to impress any client if we don't know
    anything about the client ?

    Bye,
    Skybuck.

    "Whatever I Fear" wrote in message
    news:e5c4c752-1a05-4aab-97e1-5f17a37847c8@f63g2000hsf.googlegroups.com...
    >I am in charge of setting up a demo for a client for a small IPv6 lab
    > to demonstrate some of our capabilities. Currently, we are using IPv6
    > tunneling through an IPv4 network, with various IPv4 and IPv6 web
    > servers and IPv6 network cameras.
    >
    > It is a pretty quick task to show, hey you can access IPv4 and IPv6
    > web pages seamlessly, and you can show feeds of digitial video of IPv6
    > cameras, but at the end of the day, this leaves you saying "so what"?
    > It is kind of difficult to demonstrate "protocols".
    >
    > In essence I need something with a little bit of wow factor in
    > something that really doesnt have that much.
    >
    > I am curious about some other good ideas to just show the capabilities
    > of IPv6 with a couple IPv4 routers, cameras, enabled workstations,
    > etc. I would like to show maybe some security issues, maybe some
    > gotchas if you just plug up IPv6 and dont really take security into
    > account, just something that makes you say, "hey this IPv6 thing could
    > be good for us".
    >
    > I appreciate any thoughts.




  5. Re: IPv6 Demonstration - Getting the wow factor?

    In article <4463255e-c9f7-4225-bfdc-1873870b08b0@u69g2000hse.googlegroups.com>,
    Le Chaud Lapin writes:
    >
    > The wow factor comes from applications, not necessarily the protocols,
    > and since IPv6 does not exactly facilitate the creation of wow
    > applications, you have no wow applications to show, and all you are
    > left with is a protocol, which just so happens to be a mess to look
    > at.


    I don't know if IPv6 is such a mess, I'm not a v6 expert, but it cannot
    be a bigger mess than the combination of IPv4 plus NAT that we are stuck
    with right now. I'm currently trying to set up a SIP based telephony
    network - a wow application - but the fact that some of the intended
    users are behind NAT is giving me a headache. ICE attempts to "solve"
    the NAT problem by building NAT traversal into the application layer at
    the endpoints, but that is just a symptom, not a cure.

    Wow applications like Internet Telephony would be a lot easier to create
    with a _proper_ solution of the address scarcity problem.

  6. Re: IPv6 Demonstration - Getting the wow factor?

    Hi all,


    Le Chaud Lapin schreef:
    >> As a matter of fact, just how much and specifically what security
    >> protocols should be mandated for IPv6 nodes is a matter of debate as
    >> we speak, within the IETF. But be that as it may, there is nothing
    >> INTRINSIC in IPv6 that creates a more secure environment. That's the
    >> bottom line. For what it's worth, RFC 4294 is being updated to reflect
    >> some of these debates.
    >> I know this doesn't help your cause. I'm just trying to introduce some
    >> reality.


    > Albert is right. IPv6 is, unfortunately, in 2008, highly overrated.
    > This is what happens when duct-tape something as important at a system
    > that is supposed be used by more than 10 billion people in its mature
    > state: you end up with something that begins to rot in its own waste.
    > Truth is, there probably is nothing you can do to wow your audience.


    Well, there is:
    Just shut down your IPv4 connectivity and say "this is the situation we
    will be in by in 3 years from now; and this is how we are going to solve
    it".

    In the end, this'll probably be the only thing that will drive IPv6.


    When I look at my situation at home, the only thing where IPv6 would
    really help is that it gives some devices on my local network their own
    public-addressable IP-address and this does allow for some nice ideas.

    It would allow my SIP-phone to be using in pure "peer-to-peer" mode and
    allows applications like jingle (voip over xmmp) to be implemented
    without some kind of relay.

    But these are all "nice features" because I like to play around with
    networks and computers; not really a necessity. They are not really
    things I really need.
    E.g. My SIP-phone works great in client-server mode, so -from a user
    point of view- I do not need IPv6 at all.


    In fact, all issues that IPv6 was created for to solve (with the
    exception of the scarcity of IP-addresses), have already been solved in
    IPv4 in some way.



    > The wow factor comes from applications, not necessarily the protocols,
    > and since IPv6 does not exactly facilitate the creation of wow
    > applications, you have no wow applications to show, and all you are
    > left with is a protocol, which just so happens to be a mess to look
    > at.


    To be honest,
    IPv6 is only a transport-layer. So I do not see any reason why IPv6
    would be more or less suited to write applications for then IPv4.



    > -Le Chaud Lapin-

    Cheerio. Kr. Bonne.

  7. Re: IPv6 Demonstration - Getting the wow factor?

    On Apr 4, 2:45*am, Kristoff Bonne wrote:
    > Hi all,
    > > The wow factor comes from applications, not necessarily the protocols,
    > > and since IPv6 does not exactly facilitate the creation of wow
    > > applications, you have no wow applications to show, and all you are
    > > left with is a protocol, which just so happens to be a mess to look
    > > at.

    >
    > To be honest,
    > IPv6 is only a transport-layer. So I do not see any reason why IPv6
    > would be more or less suited to write applications for then IPv4.


    IPv4 presents an unsavory interface for programmers: sockets. Many
    programmers, even experts, often spend hours trying to understand
    strange behavior or get clarification on the specification. IPv6
    extends the unsavory interface to be even more unsavory, in the name
    of "backwards compatibility."

    In a nutshell, the interface is really old, created at a time where
    one was really luckly to get more than 1 hour / day with a computer.

    We have to remember that sockets was devised during a time when
    researchers would get really excited at the simple idea that data was
    being transmitted reliably from one point to another. I remember when
    my electrodynamics professor in college was providing a demonstration
    of a 200MB hard disk. He was so excited, he started to salivate,
    saying "at one time 10MB was the rage!". The students were giggling
    under their breath. We were all thinking the same thing: "Don't you
    know that 9GB hard disks are already available, and that it is simply
    a matter of time before 1TB models become available?"

    So times have changed, and the expectations of the network programmers
    have changed too...but...sockets have not changed with them."

    But if you want duct tape, we have plenty of that. In fact, I
    challenge the reader to think of any new Internet technology that has
    arisen in the past 15 years that is not based on duct tape:

    1. SSL (original sockets had no security)
    2. AJAX (we do not have a projected window model for Windows, and X
    Windows...ahem.)
    3. OpenID (the naming system we have is broken)
    4. WebDAV (no global file system. NFS and AFS don't count).
    5. Secure FTP (see #4, but add security)
    6. NAT (addressing model was inadequate)
    7. NAT-busters (duct tape for #6 duct tape)
    8. Mobile XYZ (no mobility in Internet)
    9. Multicast XYZ (extremely cumbersome multicast in Internet)

    Anyhow, this list is very long.

    Note that it is not for lack of want. Every few months, some venture
    capitalist somewhere will inject millions of dollars into a start-up
    company to "address" one of these problems. The solutions proposed by
    such companies are generally hackish, yet still some of these
    companies get bought for hundreds of millions, if not billions of
    dollars.

    So market potential is not the problem.

    If someone were to redo IPv6, taking into account not what the
    designers of IPv6 actually did, but the promise thereof (security,
    mobilility, multicasting...) *AND*...provide a model that has sound
    theoretical underpinnings *AND* presented an interface to the average
    programmer that facilitated its use, without disrupting the current
    Internet, then there would be mass acceptance.

    -Le Chaud Lapin-


  8. Re: IPv6 Demonstration - Getting the wow factor?

    On Apr 4, 2:45*am, Kristoff Bonne wrote:

    > In fact, all issues that IPv6 was created for to solve (with the
    > exception of the scarcity of IP-addresses), have already been solved in
    > IPv4 in some way.


    I agree with this sentiment. I'd say it a little differently, though.
    And that would be, any new feature developed for the Internet
    Protocol, speaking generically, is developed to work over both IPv4
    and IPv6. Just about.

    On Apr 4, 8:53 am, Le Chaud Lapin wrote:

    > But if you want duct tape, we have plenty of that. In fact, I
    > challenge the reader to think of any new Internet technology that has
    > arisen in the past 15 years that is not based on duct tape:


    I assume you mean that they are starting not from scratch, but from
    some previous protocol or technique. This is always true in evolving
    systems, isn't it? It's rare to (1) have done such a perfect job from
    the start that no changes are ever required, or (2) start from scratch
    when introducing any new feature.

    > 1. SSL (original sockets had no security)
    > 2. AJAX (we do not have a projected window model for Windows, and X
    > Windows...ahem.)
    > 3. OpenID (the naming system we have is broken)
    > 4. WebDAV (no global file system. NFS and AFS don't count).
    > 5. Secure FTP (see #4, but add security)
    > 6. NAT (addressing model was inadequate)
    > 7. NAT-busters (duct tape for #6 duct tape)
    > 8. Mobile XYZ (no mobility in Internet)


    Mobile IP doesn't exist?

    > 9. Multicast XYZ (extremely cumbersome multicast in Internet)


    I'm not sure what you mean by cumbersome. Certainly, multicast enabled
    routers have to maintain state, whereas unicast-only routers do not.
    And certainly, an efficient multicast tree will change as group
    members come and go. So IP multicast is not trivial.

    But then, nor is unicast, if you start adding things like service
    differentiation or traffic engineering of any type, mobility, for a
    few examples.

    > If someone were to redo IPv6, taking into account not what the
    > designers of IPv6 actually did, but the promise thereof (security,
    > mobilility, multicasting...) *AND*...provide a model that has sound
    > theoretical underpinnings *AND* presented an interface to the average
    > programmer that facilitated its use, without disrupting the current
    > Internet, then there would be mass acceptance.


    I think, more simply, that if IPv6 had begun by ONLY increasing the
    IPv4 address space, and NOT tried to solve a whole laundry list of
    other problems, there would have been much faster acceptance.

    There are any number of new gizmos in IPv6 that still need to be
    worked out. Just the problem of selecting the "proper" source address
    to use, when each host has a number of IP addresses available to it,
    is creating problems. The level of security that should be required,
    without creating its own new problems, is an issue. Firewalls are an
    issue. Source routing has problems. Plenty of open questions resulting
    from trying to fix everything that was perceived as being broken, or
    at least overly restrictive, in IPv4, it seems to me.

    Probably always happens when a system originally designed to do one
    thing well is expanded into many new areas. In this case, a network
    for global point-to-point access for non-time-critical file transfers,
    is expanded to include functions best done by circuit-switched or by
    true broadcast networks.

    I got a real kick out of the description, a few years ago, of a
    DiffServ-capable router. The description was, "about the same level of
    complexity as an ATM switch." What a kick in the pants, eh?

    Bert

  9. Re: IPv6 Demonstration - Getting the wow factor?

    WARNING: LONG RESPONSE

    On Apr 4, 6:44*pm, Albert Manfredi wrote:
    > *On Apr 4, 8:53 am, Le Chaud Lapin wrote:
    >
    > > But if you want duct tape, we have plenty of that. In fact, I
    > > challenge the reader to think of any new Internet technology that has
    > > arisen in the past 15 years that is not based on duct tape:

    >
    > I assume you mean that they are starting not from scratch, but from
    > some previous protocol or technique. This is always true in evolving
    > systems, isn't it? It's rare to (1) have done such a perfect job from
    > the start that no changes are ever required, or (2) start from scratch
    > when introducing any new feature.


    Yes, this is true. But for each system, there is steady-state model
    that approaches perfection. I call it the "5-tau" state.

    I believe that, for each system, within a specified arbitary amount of
    time, a system starts at being non-existent and gradually rises in
    quality toward perfection. We might even define a function Q(t) to
    denote the quality of a system as a function of time. At t==0, the
    system does not exist, so it's quality, Q(t), is 0. At t = infinity,
    the system is perfect, so Q(t) = P, where P = perfection. Then,
    between t==0 and t==infinity, there is (hopefully) a monotonic rise in
    Q(t) as a function of t.

    We might ask: What those Q(t) look like, in general? There are some
    observations that can be made:

    1. At t = 0, any system is better than nothing, so Q(t) rises
    extremely rapidly.
    2. After a while, changes in Q(t) become increasingly smaller, the so-
    called diminishing rates of return
    3. There comes a point where though Q(t) is not yet == P, we might as
    well stop trying, because it's "close enough".

    There is a function that matches this pattern of quality improvement.
    It is the ubiquitous solution to first-order linear differential
    equation, which essentially says, in English,

    "the rate of change in something X is directly proportional to the
    current value of X and some ultimate reference point."

    dX/dt = A(X - X0)

    This formula governs a very wide variety of natural phenomena,
    including heat flow across adjacent faces of two objects, rumor
    spreading, and charging of a capacitor through a resistor. The
    solution to this equation, using Q to denote the charge on a capacitor
    that starts off at t == 0 being 0 is:

    Q(t) = P (1 - e^-t/tau)

    where tau is the product of resitance * capacitance, RC, and P is the
    final amount of charge.

    In electrical engineering, by convention, we say that the we can
    assume that capacitory is fully charge after waiting "5 taus", or
    5*RC. This is the value of t after which it is pointless to wait for
    further accumulation of charge, because for all practical purposes,
    the capacitor is fully charged.

    This same function, IMO, governs the quality of a system as a function
    of time.

    Q(t) = P [1 - e^-(t/tau)]

    "The quality of a system as a function of time approaches perfection
    exponentially and assumes perfection at t = infinity".

    Now I state why this is relevant.

    If you draw this function on a sheet of paper, the curve has a very
    distinct shape, instantly recognized by someone familiar with first-
    order differential equations. You can almost mark off on the t-axis...
    1-tau....2-tau...3-tau..4-tau....5-tau=essentially perfect.

    What I *think* happens often in systems design, especially ones like
    the Internet where the general public *really* like what you have
    done, is that the system is unleashed long before 5-tau. In some
    cases, it is released just after 1-tau.

    What "percentage" of perfection does 1-tauu represent? Well, that can
    be computed. it's:

    1- e^-1 = 63.2

    So after "1-tau", which is only 1/5 of the time that should have been
    spent making a perfect system, the system already is of 63.2% of the
    quality that it would have finally had. Not bad. Certainly useable.

    So in systems design, the designer, IMO, should remain cognizant of
    where he is on this time scale. If he has gut feeling that he is
    between, say, the 2-tau and 3-tau positions, the system should not be
    released. The more importan the system, the more important is
    adherence to this rule.

    So what happened with IPv4? Well...to understand that, one has to know
    what constitutes perfection of an internetworking protocol.'

    There are a lot of people who will claim that hindsight is 20/20, that
    we could not have forseen that security would be an essential element.

    I disagree.

    I think that, even in 1980, it would have been possible for a giant in
    this field, say a Butler Lampson or Paul Mockapetris, to recongize
    what elements would be essential ingredients for a 5-tau system. Note
    the distinction between recongizing what the elements are, and
    claiming to know how to deliver them. It is not necessary to have
    knowledge of how to deliver something to recognize its virtue.
    Distilled water is a good example. The moment that it was discovered
    that crystal-clear water might still contain germs, biologist probably
    began seeking ways to purify even further. Whether they were
    successful is separate from the notion that having stringently-
    purified water is good. The same goes for the Internet.

    > > 1. SSL (original sockets had no security)
    > > 2. AJAX (we do not have a projected window model for Windows, and X
    > > Windows...ahem.)
    > > 3. OpenID (the naming system we have is broken)
    > > 4. WebDAV (no global file system. NFS and AFS don't count).
    > > 5. Secure FTP (see #4, but add security)
    > > 6. NAT (addressing model was inadequate)
    > > 7. NAT-busters (duct tape for #6 duct tape)
    > > 8. Mobile XYZ (no mobility in Internet)

    >
    > Mobile IP doesn't exist?


    It does but...if one were to apply Q(t) to mobility alone...I don't
    think it would be very close to P.

    > > 9. Multicast XYZ (extremely cumbersome multicast in Internet)

    >
    > I'm not sure what you mean by cumbersome. Certainly, multicast enabled
    > routers have to maintain state, whereas unicast-only routers do not.
    > And certainly, an efficient multicast tree will change as group
    > members come and go. So IP multicast is not trivial.


    My vision of multicast would be a 20-year-old writing an application
    that can grab real-time video from a PC camera. Then, someone else,
    say a news reporter, by chance, sees something that is of interest to
    most people on the planet. The subsequent deluge of interested
    viewers, say, 8 million all at once, should not be able to saturate
    the PDA. The "setup" of this should be instantaneous, and the
    application should be no more dififcult than writing application that
    simply shows 1 person.

    > But then, nor is unicast, if you start adding things like service
    > differentiation or traffic engineering of any type, mobility, for a
    > few examples.


    QoS is an interesting beast. I have ideas about that, but I purposely
    avoid discussing it. Mobility, however, I think is definitely within
    reach and definitely has a regular theoretical framework waiting to be
    realized.

    > I think, more simply, that if IPv6 had begun by ONLY increasing the
    > IPv4 address space, and NOT tried to solve a whole laundry list of
    > other problems, there would have been much faster acceptance.


    Hmm...I think the opposite - I like the laundry list.

    When I have to design a system for someone, I generally have the "7-
    hour" conversation. This is where I sit down, in multiple sessions,
    and listen to the person who has a (perhaps vague) notion of what is
    wanted. My method, which some find unnerving, is to not do anything
    until I understand everything that is being asked. [One of the people
    on Big-Internet once mentioned that this same method was how a redo of
    IPv4 should be done.] Generally, after about 4 hours of listening, my
    client will begin to take pauses, frown, doubt...

    ...what's happening is that s/he is assuming that I have been given
    more than enough information to "be productive." S/he assumes that I
    should take what has been given, and go from there, and come back for
    the remaining 3-hours of talk. I resist.

    One of the worst things in systems design is to get all the nuts and
    bolts in place, only to discover that there are extra features that
    were not mentioned so as to not overload the designer's mind.

    I hate this.

    I would much rather they get it all out, up front, so I know the
    entire scope of the problem. That way, I don't end up doing something
    that will come back and bite later, such as committing to a packet
    format that doesn't allow space for a cryptographic element or not
    making room for mobility, for example.

    There is also a benefit from having entirety-of-scope upfront. You
    get the opportunity to find patterns in your entire system. This means
    reuse. Things start to fall into place. You no longer have that uneasy
    feeling that you're missing something. And the biggest benefit, I
    think, is that features that were never ask for will manifest
    themselves gratuitously..because you will find "nuggets-of-unuse" in
    the system, and just at the moment you say, "Hmmm...I seem to have 5
    extra Fraddles...I wonder..." and suddenly, they are no longer extra,
    but the remaining parts of a component that was only partially seen by
    foresight.

    > There are any number of new gizmos in IPv6 that still need to be
    > worked out. Just the problem of selecting the "proper" source address
    > to use, when each host has a number of IP addresses available to it,
    > is creating problems. The level of security that should be required,
    > without creating its own new problems, is an issue. Firewalls are an
    > issue. Source routing has problems. Plenty of open questions resulting
    > from trying to fix everything that was perceived as being broken, or
    > at least overly restrictive, in IPv4, it seems to me.


    Orthogonality will go a long way here. Also, as I mentioned before, I
    think they would have gotten *MUCH* further if they did not try to be
    backward compatible. One truth in 2nd-system engineering I have
    learned is that, it is OK to dump the old system if the new system is
    that much better, because, strange as it might seem, if the new system
    is so good, it almost always turns out that retrofitting it to
    accommodate the old is not as big and issue as originally thought.

    > Probably always happens when a system originally designed to do one
    > thing well is expanded into many new areas. In this case, a network
    > for global point-to-point access for non-time-critical file transfers,
    > is expanded to include functions best done by circuit-switched or by
    > true broadcast networks.


    All those conferences. I think Butler Lampson in his thinking cap over
    a period of a few weeks might have determined the "steady-state" model
    for the Internet in 2010.

    I am surprised with the $1 billion+ already invested in Internet
    research that researchers do not take walks in the woods more often.
    How can you fix something if you do not know what the goal is?

    > I got a real kick out of the description, a few years ago, of a
    > DiffServ-capable router. The description was, "about the same level of
    > complexity as an ATM switch." What a kick in the pants, eh?


    Yeah.

    And the ATM people, God bless them, they really are special.

    -Le Chaud Lapin-

  10. Re: IPv6 Demonstration - Getting the wow factor?

    On Apr 4, 10:28*pm, Le Chaud Lapin wrote:
    > WARNING: LONG RESPONSE


    Very interesting, though. It actually kept my interest throughout.
    I'll only respond very briefly to a couple of points.

    > I believe that, for each system, within a specified arbitary amount of
    > time, a system starts at being non-existent and gradually rises in
    > quality toward perfection. We might even define a function Q(t) to
    > denote the quality of a system as a function of time. At t==0, the
    > system does not exist, so it's quality, Q(t), is 0. At t = infinity,
    > the system is perfect, so Q(t) = P, where P = perfection. *Then,
    > between t==0 and t==infinity, there is (hopefully) a monotonic rise in
    > Q(t) as a function of t.


    Well, an untriguing model, but does it apply? To IP, you might make
    the argument that it comes close, at least as far as we know today.
    Other systems are a different matter. Sometimes you do reach dead
    ends, rather than lim(as t --> infinity) = perfection. Some functions
    do not converge. Some functions oscillate as a function of time, and
    others blow up.

    Since we mentioned ATM, that might be one example. The way things
    evolved, ATM was not the best answer. The way things evolved, rather
    than spending a lot of time and effort with mathematics, trying to
    make underprovisioned networks work better than they should, you throw
    cheap bandwidth at the problem, and let the mathematicians work on
    something else.

    (And even then, some of them continue to work traffic engineering
    problems, in the context of IP, very soon reaching similar levels of
    difficulty as in previous efforts.)

    > My vision of multicast would be a 20-year-old writing an application
    > that can grab real-time video from a PC camera. Then, someone else,
    > say a news reporter, by chance, sees something that is of interest to
    > most people on the planet. The subsequent deluge of interested
    > viewers, say, 8 million all at once, should not be able to saturate
    > the PDA. *The "setup" of this should be instantaneous, and the
    > application should be no more dififcult than writing application that
    > simply shows 1 person.


    Those are goals, not solutions. Those goals are good enough, but the
    network mechanisms to achieve them may not be trivial, depending what
    type of network you try to use.

    Of course, if you know ahead of time that a huge number of people will
    be interested in some particular stream, you can certainly select a
    network that is optimized already to handle that load. There is
    nothing difficult about getting a media stream simultaneously to 8
    million people. Use a broadcast network, or a combination of broadcast
    networks. Use storage at the destinations to allow non-real-time
    consumption. Done.

    In general, some things are just plain difficult to solve.

    Bert

  11. Re: IPv6 Demonstration - Getting the wow factor?

    On 2008-04-04 08:53:11 -0400, Le Chaud Lapin said:

    > IPv4 presents an unsavory interface for programmers: sockets. Many
    > programmers, even experts, often spend hours trying to understand
    > strange behavior or get clarification on the specification. IPv6
    > extends the unsavory interface to be even more unsavory, in the name
    > of "backwards compatibility."


    This quip here motivated me to chime in, and made me think - thanks,
    and no, this is not a directed flame, but merely a commentary.

    While sockets may be an unsavory interface (personally, I found Plan9's
    approach to networking & sockets rather elegant), they did get you at
    one point in time down to the bare basics of the hardware you are
    working with, sort of an old and outdated concept today, but one I
    think we need to revisit because with the exception of FreeBSD, Solaris
    10 and in some cases Linux, TCP/IP stack performance has been crud
    (don't get me started on M$, etc.). We can't just dump things @
    hardware and expect it to "deal with it", etc.

    A good portion of my life has been and is spent debugging applications
    from the network trace side upwards, and the things I discover that way
    demonstrate that there is too little knowledge of how the network
    behaves, what it can do, and what it can't do. I have no qualms saying
    that Java is my #1 offender here. At least the inconvenient socket
    interface gave pause to think about what we're putting on the network
    and how we're getting it there, not treating it as a pipe with no
    pressure limits, etc. Everyone likes to talk about bandwidth, but no
    one talks about latency and what that does to protocols, etc., etc.
    This perspective isn't purely from a network geek's perspective, I
    write code too, but probably not as prodigiously as other participants
    in this group.

    The answer too, is not a difficult & old-fashioned interface! I'm
    hoping in the future, we could find a compromise where, perhaps in the
    stack itself programmers can easily interrogate the stack for a guess
    about network conditions and easily make intelligent decisions on how
    to send traffic with some smarts. Maybe a dream for a future IPv6, not
    going to get there with IPv4.

    Thanks for the comments, Le Chaud Lapin, appreciated your perspective &
    comments. I'm glad we still have these conversations here. Cheers!

    /dmfh

    --

    __| |_ __ / _| |_ 01100100 01101101
    / _` | ' \| _| ' \ 01100110 01101000
    \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx


  12. Re: IPv6 Demonstration - Getting the wow factor?

    On Apr 8, 9:31*pm, Digital Mercenary For Honor
    wrote:
    > A good portion of my life has been and is spent debugging applications
    > from the network trace side upwards, and the things I discover that way
    > demonstrate that there is too little knowledge of how the network
    > behaves, what it can do, and what it can't do. I have no qualms saying
    > that Java is my #1 offender here. At least the inconvenient socket
    > interface gave pause to think about what we're putting on the network
    > and how we're getting it there, not treating it as a pipe with no
    > pressure limits, etc. Everyone likes to talk about bandwidth, but no
    > one talks about latency and what that does to protocols, etc., etc.
    > This perspective isn't purely from a network geek's perspective, I
    > write code too, but probably not as prodigiously as other participants
    > in this group.


    Yes, discovering where exactly is anomalous state in a system is a
    problem that could be better addressed, IMO. I spent 167 hours
    recently trying to set up IIS 7.0 on Windows Vista Ultimate. The
    error messages given were simply too vague. IIS of course is above
    the network layer, but same principle applies. While it might be
    unreasonable to ask software to fix itself, it is not unreasonable to
    ask the software to tell you what is wrong with it. I think engineers
    shun this part of design because it is tedious. I do.

    > The answer too, is not a difficult & old-fashioned interface! I'm
    > hoping in the future, we could find a compromise where, perhaps in the
    > stack itself programmers can easily interrogate the stack for a guess
    > about network conditions and easily make intelligent decisions on how
    > to send traffic with some smarts. Maybe a dream for a future IPv6, not
    > going to get there with IPv4.


    One change that I would make in this regard is to assimilate all tools
    into one blob, so that it is not necessary to go hunting at various
    disparate points in system for a problem: host file, ARP, PING,
    tracert, nslookup, etc. I would also use C++ exception handling to
    bring order to the call stack so that programmer can have as little or
    as much diagnostic information as desired. I would also expect the
    stack itself to be able to do some diagnostic work, and the diagnoses
    would have to be extremely detailed, unlike:

    "connection failed: please see your system administrator."

    > Thanks for the comments, Le Chaud Lapin, appreciated your perspective &
    > comments. I'm glad we still have these conversations here. Cheers!


    You're welcome!

    -Le Chaud Lapin-

  13. Re: IPv6 Demonstration - Getting the wow factor?

    On 2008-04-09 10:43:39 -0400, Le Chaud Lapin said:

    > One change that I would make in this regard is to assimilate all tools
    > into one blob, so that it is not necessary to go hunting at various
    > disparate points in system for a problem: host file, ARP, PING,
    > tracert, nslookup, etc. I would also use C++ exception handling to
    > bring order to the call stack so that programmer can have as little or
    > as much diagnostic information as desired. I would also expect the
    > stack itself to be able to do some diagnostic work, and the diagnoses
    > would have to be extremely detailed, unlike:


    Completely agreed. I think part of the answer we're all looking for is
    to look back in time at the transition in the late 1980's -> 1990's
    from IBM SNA networks to TCP/IP. We lost something big there in network
    technology - as inefficient as SNA might have been in moving data
    around in certain cases, it did have an excellent set of built-in
    diagnostics with rich hooks to the ubiquitous IBM "comms trace"
    facilities to both diagnose and model a given network. When we changed
    to TCP/IP world-wide, we put statistical math guesswork in the driver's
    seat and hoped for the best. I'm wondering how we could get that
    rich-type diagnostic goodness akin to the SNA days into IPv6, TCP/IP
    v.whatever, etc. Time for me to become more of a programmer and
    understand more and more of those perspectives.

    /dmfh

    --

    __| |_ __ / _| |_ 01100100 01101101
    / _` | ' \| _| ' \ 01100110 01101000
    \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx


  14. Re: IPv6 Demonstration - Getting the wow factor?

    On Apr 10, 10:11*pm, Digital Mercenary For Honor
    wrote:
    > On 2008-04-09 10:43:39 -0400, Le Chaud Lapin said:
    > Completely agreed. I think part of the answer we're all looking for is
    > to look back in time at the transition in the late 1980's -> 1990's
    > from IBM SNA networks to TCP/IP. We lost something big there in network
    > technology - as inefficient as SNA might have been in moving data
    > around in certain cases, it did have an excellent set of built-in
    > diagnostics with rich hooks to the ubiquitous IBM "comms trace"
    > facilities to both diagnose and model a given network. When we changed
    > to TCP/IP world-wide, we put statistical math guesswork in the driver's
    > seat and hoped for the best. I'm wondering how we could get that
    > rich-type diagnostic goodness akin to the SNA days into IPv6, TCP/IP
    > v.whatever, etc. Time for me to become more of a programmer and
    > understand more and more of those perspectives.


    Well, if you're thinking about fixing TCP/IP, the field is very much
    wide-open. Though its proponents refuse to admit it, IPv6 is _not_ the
    future of networking. It took 20 years for lead researchers to see
    that duct-tape is a very bad idea when you're talking recreating the
    universal model for digital communication.

    So now there are a bunch of Let-Us-Redo-TCP/IP-From-Scratch projects,
    the most prominent and soon-to-be most well-funded ($300US+ million)
    being http://www.geni.net. These projects are just starting in 2008.
    Some of their leaders were tweaking TCP/IP back when a megabyte of RAM
    cost $1000US.

    Much has changed. Tioday, there are no memory constraints. No
    transmission constraints. No CPU constraints. No hard disk contraints.
    No punch cards. No waiting in line for a terminal. No lack of books.
    No lack of compilers. No lack of OS that supports multi-threading. No
    lack of anything.

    It is one of the rare large problems in science where the imagination
    really is the only limitation.

    -Le Chaud Lapin-

  15. Re: IPv6 Demonstration - Getting the wow factor?

    On 2008-04-11 01:24:15 -0400, Le Chaud Lapin said:

    > Well, if you're thinking about fixing TCP/IP, the field is very much
    > wide-open. Though its proponents refuse to admit it, IPv6 is _not_ the
    > future of networking. It took 20 years for lead researchers to see
    > that duct-tape is a very bad idea when you're talking recreating the
    > universal model for digital communication.


    Encouraging to hear, and thanks for the additional information in the
    post - personally, I envision a world where the traffic is constantly
    analyzed, and the applications are offered a "menu" of protocols to
    pick the one that best fits the types of data needing to get someplace.
    Granted, sure, everyone will pick select(high_priority,
    my_data_is_important, me_too) or have a leaning that way, but inside
    the enterprise, not so much. I see a lot of smart ideas that die in the
    RFC graveyard or don't catch on, and it'd be nice to encapsulate those
    ideas in an open stack where anyone can just choose.

    Let's team up and take over the world. (*laughing*)

    /dmfh

    --

    __| |_ __ / _| |_ 01100100 01101101
    / _` | ' \| _| ' \ 01100110 01101000
    \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx


  16. Re: IPv6 Demonstration - Getting the wow factor?

    Le Chaud Lapin wrote:
    > Much has changed. Tioday, there are no memory constraints. No
    > transmission constraints. No CPU constraints. No hard disk
    > contraints.


    There are _always_ such constraints. They may not be as cumbersome
    today as they were yesterday, but tomorrow they will be back.

    rick jones
    --
    The glass is neither half-empty nor half-full. The glass has a leak.
    The real question is "Can it be patched?"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  17. Re: IPv6 Demonstration - Getting the wow factor?

    On Apr 14, 12:41*pm, Rick Jones wrote:
    > Le Chaud Lapin wrote:
    >
    > > Much has changed. Tioday, there are no memory constraints. No
    > > transmission constraints. No CPU constraints. No hard disk
    > > contraints.

    >
    > There are _always_ such constraints. *They may not be as cumbersome
    > today as they were yesterday, but tomorrow they will be back.


    Hmm...I'm inclined to agree with you that what's good enough today
    might be inadequate tomorrow...but if I did, then that would violate
    my "Five Tau's" priniciple, that the quality of a component or system
    approaches perfection exponentially according to 1-order ODE as
    described previously.

    So while it is true that the contraints will reappear later, I think
    the question to ask is where, exactly, are we on the qualtity curve:

    Q(t) = P [1 - e^(-t/tau)]
    t = time, P = perfection, tau = natural time constant of rate of
    approach of quality of system toward perfection.

    When the telephone system first came out, there was very rapid changes
    in qualtity. As time passed, the changes became less and less
    drastic. Today, it is accepted that one should be able to talk to
    anyone else in the world who possesses a phone. Before, that was
    unthinkable.

    The same is true for automobiles, I think. While waiting for a friend
    in the library of a US university, I happened to be in the automotive
    engine section, and so I picked up a book, written in 1905, expecting
    to see strange looking concoctions that hardly worked, given that
    automotive technology was in its infancy then, or so I thought. I was
    extremely suprised to see detailed drawings that were very much like
    the engines today. One picture showed a V-6, with O-rings, valve
    timing, cam rods, etc.

    This confused me because automotive technology is still very much in
    development, and I suspect that there is far more development left
    than not, so how can a system 100+ years old not have changed so much,
    yet much change of it still awaits?

    They are two different systems.

    The steam engine is a reciprocating engine, and if you eyeball it
    closely, you will still see pistons, O-rings, etc. But it is different
    enough from petrol-powered engines that the two cannot be equated,
    though some engineers might have thought as such in 1900.

    So perhaps the confusion comes from two systems sharing common
    components, and serving the same function, thus appearing to be
    equivalent, but are actually not.

    VOIP serves the same function, more or less, as POTS. VOIP might even
    use POTS cabling to create the link for IP packets. But the system
    itself is sufficiently different. We are at present tweaking VOIP for
    sound quality with advanced coding techniques, while we tweaked POTS
    long ago (with Pupin coils).

    So I think perhaps we should ask ourselves if we are still tweaking
    the same system (steam engine), or have moved on to a new system
    (internal combustion), even though the systems essentially achieve the
    same results.

    Arguably, the most important feature of TCP, retransmission, IMO, is
    fundamentally inappropriate to actual nature of data transfer in the
    21st century.

    I am beginning to think that the replacement might be a different
    system altogether, though the overall function is essentially the
    same.

    -Le Chaud Lapin-





  18. Re: IPv6 Demonstration - Getting the wow factor?

    On Apr 14, 2:31*pm, Le Chaud Lapin wrote:
    > On Apr 14, 12:41*pm, Rick Jones wrote:
    > > There are _always_ such constraints. *They may not be as cumbersome
    > > today as they were yesterday, but tomorrow they will be back.

    >
    > Hmm...I'm inclined to agree with you that what's good enough today
    > might be inadequate tomorrow...but if I did, then that would violate
    > my "Five Tau's" priniciple, that the quality of a component or system
    > approaches perfection exponentially according to 1-order ODE as
    > described previously.


    I'd say, feel free to violate that principle. It's perhaps true that
    ultimately, everything improves along an S-shaped curve, as you
    postulate. The problem is that the second knee of that S is often way
    too far off to even consider it.

    In this case, CPU power and networks, the safest bet is to be looking
    to each subsequent bottleneck. You improve one component, so just look
    ahead and find the next roadblock. Just like traffic engineering when
    doing urban planning.

    > So I think perhaps we should ask ourselves if we are still tweaking
    > the same system (steam engine), or have moved on to a new system
    > (internal combustion), even though the systems essentially achieve the
    > same results.


    In 1906, with vacuum tube amps, longer distances than ever before
    could be reached with telephone connections. That's one hurdle
    resolved, at least for now.

    In the 1920s, the phone people were trying to figure out how to
    continue to expand the system, because their telephone poles were
    filling up with too many cables. That's when they first introduced
    automatic dialing and mutliplexing, where a single cable could carry
    multiple phone connections. Also, radio to carry telephone was first
    used, to cover distances where cables were not easily installed.

    In the 1940s, solid state electronic switching invented, to reduce the
    size and improve the reliability of switches, now allowing personal
    phone numbers for everyone. Solved another bottleneck.

    In the mid 1950s, the first modem is introduced, to send data over
    telephone lines.

    In the early 1960s, packet switching is invented. In the late 1960s, a
    complete digital tlephone system (ISDN) is invented, to further
    improve efficiency.

    In the 1980s, data started to outstrip voice as the major load on long
    distance networks. That's when schemes were developed to carry both
    data and voice efficiently, as opposed to force-fitting data over a
    network design optimized for voice, using a combination of circuit and
    packet switching (SONET, ATM).

    Now it's the other way around, Voice is being added as a minor load on
    top of networks optimized for data.

    Possibly, the next step is to optimize the network infrastructure for
    multimedia streams, big time, where these streams demand more network
    resources than voice and data combined.

    So the way I see it, you are chasing after one bottleneck after
    another. Fix one, another pops up. It's not so easy to ever do that 5-
    tau you talk about, because the problem keeps changing.

    Bert

  19. Re: IPv6 Demonstration - Getting the wow factor?

    On Wed, 9 Apr 2008 07:43:39 -0700 (PDT), Le Chaud Lapin wrote:
    ....
    > Yes, discovering where exactly is anomalous state in a system is a
    > problem that could be better addressed, IMO. I spent 167 hours
    > recently trying to set up IIS 7.0 on Windows Vista Ultimate. The
    > error messages given were simply too vague. IIS of course is above
    > the network layer, but same principle applies. While it might be
    > unreasonable to ask software to fix itself, it is not unreasonable to
    > ask the software to tell you what is wrong with it. I think engineers
    > shun this part of design because it is tedious. I do.


    You might enjoy Peter Da Silva's article "The case for stupid
    software" -- google for the exact URL. (He uses a POP3 client as one
    of the examples, so it it not entirely off-topic here.)

    /Jorgen

    --
    // Jorgen Grahn \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!

  20. Re: IPv6 Demonstration - Getting the wow factor?

    On May 1, 11:58*am, Jorgen Grahn wrote:
    > On Wed, 9 Apr 2008 07:43:39 -0700 (PDT), Le Chaud Lapin wrote:
    > ...
    >
    > > Yes, discovering where exactly is anomalous state in a system is a
    > > problem that could be better addressed, IMO. I spent 167 hours
    > > recently trying to set up IIS 7.0 on Windows Vista Ultimate. *The
    > > error messages given were simply too vague. *IIS of course is above
    > > the network layer, but same principle applies. *While it might be
    > > unreasonable to ask software to fix itself, it is not unreasonable to
    > > ask the software to tell you what is wrong with it. I think engineers
    > > shun this part of design because it is tedious. I do.

    >
    > You might enjoy Peter Da Silva's article "The case for stupid
    > software" -- google for the exact URL. *(He uses a POP3 client as one
    > of the examples, so it it not entirely off-topic here.)


    Yes, that was an interesting read.

    Who knows...there might an unrefined art waiting to be developed:

    "Self-Diagnosing Software"

    -Le Chuad Lapin-

+ Reply to Thread