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

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-

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.

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.

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.

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-

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

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-

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

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

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-

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

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-

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

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...

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-

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

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!

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-