-Original Message-
From: Noel Chiappa [mailto:[EMAIL PROTECTED]
Sent: 12. janúar 2004 20:49
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Death of the Internet - details at 11
From: Tony Hain [EMAIL PROTECTED]
Like it or not, the IETF must stop wasting time and effort
On 31-jan-04, at 2:14, Armando L. Caro Jr. wrote:
That's why I think it makes more sense to backport the SCTP
multihoming
features to TCP so all TCP apps can use them without having to be
changed, or even better: contain the changes in a separate shim layer
so that all transport protocols can
Agreeing with what Iljitsch said, with the addition that the
deadline was imposed to get people to submit proposals so the
working group had something to discuss, not to exclude proposals that
show up two weeks later.
The chairs made explicit requests on the mailing list to ANYONE to
submit an
Dave,
RRSh But of course the whole point is that we don't need this.. at least
RRSh not with SCTP
There is a small matter of getting 500 million hosts to convert to
SCTP and then to convert all Internet applications over to it.
I think this argument can be taken too far. Yes, there are 500
Hi Spencer/Armando,
I haven't been following this discussion through.. so let me know if I'm
going off track.
On Fri, 30 Jan 2004, Spencer Dawkins wrote:
something, transports ignoring path changes makes a lot of sense. If
you are changing paths frequently (and round-robin would be the
Ayyasamy, Senthilkumar (UMKC-Student);
To summarise, read:
http://www.ietf.org/internet-drafts/draft-ohta-multi6-8plus8-00.txt
which describes a end2end scalable 8+8 id/loc proposal, a lot different
from Mike O'dell's version of 8+8.
Also, since the transport is maintaining per path
Daniel Senie;
Ah, so you have indeed made routing policy decisions and placed them
into the end systems of the originator of the session. This is most
interesting. A site which has multiple connections with varying cost has
to either live with the routing policy you've encoded into the stack
Iljitsch van Beijnum;
Ok, we can discuss whether the changes are significant but the fact
that changes are required at all is the main problem.
You don't get new features without change of some sort...
Sure. But wouldn't it be better to keep the number of places where
changes are necessary to
X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
(Resend)
Hi Mike,
On Fri, 30 Jan 2004 09:09:57 -0800 (PST)
Michael Thomas [EMAIL PROTECTED] wrote:
Now wait a minute. It's your
However, with multihoming, the change may be a common occurance
throughtout the lifetime of a connection depending on the application and
the use of the multiple paths (failover, concurrent multipath transfer,
etc). So TCP (or whatever transport) should not be blind to the fact that
data is
On Sat, 31 Jan 2004, Ayyasamy, Senthilkumar (UMKC-Student) wrote:
However, with multihoming, the change may be a common occurance
throughtout the lifetime of a connection depending on the application and
the use of the multiple paths (failover, concurrent multipath transfer,
etc). So TCP
Hi Mike,
On Fri, 30 Jan 2004 09:09:57 -0800 (PST)
Michael Thomas [EMAIL PROTECTED] wrote:
Now wait a minute. It's your bandwidth... shouldn't
you be _shaping_ his traffic if there's some reason
he shouldn't be using one path or another? And thus
provide negative feedback so that
Randall,
Let's see. I get a CIDR network address from one provider. I get
another from another. I can have my BGP announce both of them all the
time or one of them at a time. I guess I do not see the horrible
scaling problem.
RRSh The scaling problem shows up when you tell the provider of
[I'm not going to get into _all_ the details as this probably isn't the
right place for it.]
On 29-jan-04, at 13:43, Randall R. Stewart (home) wrote:
Ok, we can discuss whether the changes are significant but the fact
that changes are required at all is the main problem.
You don't get new
That's why I think it makes more sense to backport the SCTP multihoming
features to TCP so all TCP apps can use them without having to be
changed, or even better: contain the changes in a separate shim layer
so that all transport protocols can become address agile without having
to be
On 30-jan-04, at 11:34, Ayyasamy, Senthilkumar ((UMKC-Student)) wrote:
As far as I can tell, most of the multi6 wg participants are thinking
along similar lines.
3. you should speak for yourself, not for others.
I think I used enough qualifiers to be able to make this statement.
Obviously
Noel:
Comments in line :-
Noel Chiappa wrote:
From: John C Klensin [EMAIL PROTECTED]
Of course, multiple A records works, is out there, and have worked for
years. But they worked better before we introduced routers (i.e., when
the hosts with multiple A records really had
John,
JJCK Of course, multiple A records works, is out there, and have
JCK worked for years. But they worked better before we introduced
JCK routers (i.e., when the hosts with multiple A records really had
JCK interfaces on different networks). Today, it effectively
JCK implies having
We're clearly looking at this issue from VERY different viewpoints. See
comments inline.
At 07:11 AM 1/30/2004, Randall R. Stewart (home) wrote:
Daniel Senie wrote:
I really don't see how this fits with routing policy. You appear to make
the assumption that a multi-homed site wants to use the
Daniel Senie writes:
Wrong origination of routing information. I see from comments below you're
looking at the I'm an end user and want to have multiple paths to the
Internet to get more bandwidth or redundancy aspect. I run a web hosting
company. We want to be able to have multiple
Dave Crocker wrote:
John,
JJCK Of course, multiple A records works, is out there, and have
JCK worked for years. But they worked better before we introduced
JCK routers (i.e., when the hosts with multiple A records really had
JCK interfaces on different networks). Today, it effectively
JCK
Anyway, with IPv6 the address format is fundamentally incompatible with
that of IPv4 so there is no choice but running them concurrently during
the transition period. A new multihoming-capable transport protocol
doesn't have to be incompatible with existing TCP so this situation is
On Fri, 30 Jan 2004, Michael Thomas wrote:
Daniel Senie writes:
Wrong origination of routing information. I see from comments below you're
looking at the I'm an end user and want to have multiple paths to the
Internet to get more bandwidth or redundancy aspect. I run a web hosting
On Sat, 31 Jan 2004, Jeroen Massar wrote:
I see a possibility of speeding up SCTP deployment by using semi-NAT,
what about PT, Protocol-Translation, this could be accomplished using
a BIA (Bump In the API) approach.
Scenario: Clients connects to server.
Client's TCP/SCTP stack sees a
On Wed, 28 Jan 2004, Iljitsch van Beijnum wrote:
And if you had the PI space, why would you bother? Contrary to some
reports multihoming using independent address space and links to more
than one ISP works fairly well: failover times are almost always
shorter than TCP or user timeouts.
I
PROTECTED]
Sent: Friday, January 30, 2004 7:14 PM
Subject: Re: Death of the Internet - details at 11
This _kind_ of a solution has already been proposed by Joe Touch and
Ted
Faber in their ICNP 97 paper, Dynamic Host Routing for Production
Use of
Developmental Networks. It works
On 28-jan-04, at 23:47, Randall R. Stewart (home) wrote:
- increased overhead compared to TCP
Ok lets see. SCTP takes on average 4 more bytes per data packet then
TCP. However, if the TCP implementation enables timestamps then
that is not true and TCP takes more overhead by about 4 bytes...
Iljitsch van Beijnum wrote:
On 28-jan-04, at 23:47, Randall R. Stewart (home) wrote:
- increased overhead compared to TCP
Ok lets see. SCTP takes on average 4 more bytes per data packet then
TCP. However, if the TCP implementation enables timestamps then
that is not true and TCP takes more
--On Thursday, 29 January, 2004 14:34 +0900 Dave Crocker
[EMAIL PROTECTED] wrote:
...
JCK Yes. And it may speak to the IETF's sense of priorities
that JCK the efforts to which you refer are predominantly
going into the JCK much more complex and long-term problem,
rather than the one JCK that
At 07:43 AM 1/29/2004, Randall R. Stewart (home) wrote:
Iljitsch van Beijnum wrote:
On 28-jan-04, at 23:47, Randall R. Stewart (home) wrote:
- increased overhead compared to TCP
Ok lets see. SCTP takes on average 4 more bytes per data packet then
TCP. However, if the TCP implementation enables
From: John C Klensin [EMAIL PROTECTED]
Of course, multiple A records works, is out there, and have worked for
years. But they worked better before we introduced routers (i.e., when
the hosts with multiple A records really had interfaces on different
networks). Today, it
Noel,
(1) Sorry to have misconstrued your comments.
(2) Yes, I was trying to refer to situations in which each of
the hosts on a multihomed LAN has exactly one address, largely
because of bad experiences with client machines running
widely-used junk software trying to handle multiple
John,
JCK but the only realistic solution for someone who needs high
JCK reliability in that environment is multihoming, and there seems
JCK to be no hope for multihoming of small-scale networks with IPv4.
There is not much of a solution, today, for either IPv4 _or_ IPv6.
However there are
Dave,
Just to pick a small nit or three...
--On Wednesday, 28 January, 2004 07:36 +0900 Dave Crocker
[EMAIL PROTECTED] wrote:
John,
JCK but the only realistic solution for someone who needs high
JCK reliability in that environment is multihoming, and there
seems JCK to be no hope for
On 1/28/04 at 12:39 PM -0500, John C Klensin wrote:
The reality is that there is very little that we do on the Internet
today that require connection persistence when a link goes bad (or
when using more than one IP address). If a connection goes down,
email retries, file transfer connections
On Wed, 28 Jan 2004, Dave Crocker wrote:
John,
JCK but the only realistic solution for someone who needs high
JCK reliability in that environment is multihoming, and there seems
JCK to be no hope for multihoming of small-scale networks with IPv4.
There is not much of a solution, today,
Pete,
I think the _attempt_ and _effort_ to get a solution to the
persistent connection problem is entirely worthwhile and did not
mean to suggest otherwise. I think that ignoring or delaying an
easier, and still important, problem while we work the
persistent connection one borders on
Amen to those words
Wayne
Dave:
Comments in-line below..
Dave Crocker wrote:
John,
JCK but the only realistic solution for someone who needs high
JCK reliability in that environment is multihoming, and there seems
JCK to be no hope for multihoming of small-scale networks with IPv4.
There is not much of a solution,
John C Klensin wrote:
Dave,
Just to pick a small nit or three...
--On Wednesday, 28 January, 2004 07:36 +0900 Dave Crocker
[EMAIL PROTECTED] wrote:
John,
JCK but the only realistic solution for someone who needs high
JCK reliability in that environment is multihoming, and there
seems JCK to
Applications have to deal with more then just losing a
connection. They have to deal with the loss of state that occurs when
you lose a connection. In general you really don't know which
transactions finished and which ones didn't, so you have to re-sync
your state in some way.
I believe that no
John C Klensin [EMAIL PROTECTED] wrote:
--On Wednesday, 28 January, 2004 07:36 +0900 Dave Crocker
[EMAIL PROTECTED] wrote:
In other words, when there is a serious solution to
multihoming -- ie, being able to preserve a connection when
using more than one IP Address -- it will likely work
On 28-jan-04, at 22:00, Randall R. Stewart (home) wrote:
In other words, when there is a serious solution to
multihoming -- ie, being able to preserve a connection when
using more than one IP Address -- it will likely work for IPv4.
Yes.. SCTP solves the problem for V4 and V6 (missed that bit
From: John C Klensin [EMAIL PROTECTED]
For _that_ problem, we had a reasonably effective IPv4 solution .. for
many years
We only has a solution as long as we had a small network. It was not a
solution which would scale. If that was a solution, then IPv4 is a
solution to the need
On 28-jan-04, at 18:39, John C Klensin wrote:
The reality is that there is very little that we do on the Internet
today that require connection persistence when a link goes bad (or
when using more than one IP address). If a connection goes down,
email retries, file transfer connections are
Iljitsch van Beijnum wrote:
On 28-jan-04, at 22:00, Randall R. Stewart (home) wrote:
In other words, when there is a serious solution to
multihoming -- ie, being able to preserve a connection when
using more than one IP Address -- it will likely work for IPv4.
Yes.. SCTP solves the problem for
--On Tuesday, 13 January, 2004 16:08 -0700 Vernon Schryver
[EMAIL PROTECTED] wrote:
From: John C Klensin [EMAIL PROTECTED]
...
(1) As others have pointed out, the knowledge/skill level of
a typical ISP seems to be on a rapid downslope with no end
in sight. ...
...
* The difference
On Tue, Jan 13, 2004 at 09:36:07AM +, Paul Robinson wrote:
But that app has to be something particularly splendid. And in Europe at
least, NAT is not as prevalent as some think it is.
It is prevalent wherever there is broadband. And that is where (with the
extra bandwidth and always-on)
On Tue, Jan 13, 2004 at 09:36:07AM +, Paul Robinson wrote:
Are you suggesting then, that all RFCs based on IPv6 should be... stopped?
That's what happens when you write e-mails and then don't check them before
sending them...
s/IPv6/IPv4 - obviously. :-)
--
Paul Robinson
On Mon, Jan 12, 2004 at 08:13:02PM +, Paul Robinson wrote:
IPv6 will not take off any time soon because neither the end-user nor the
service provider sees the need. The moment AOL, Wanadoo, Tiscali, World
Online et al shout out we *need* IPv6 it will happen. Quickly.
IPv6 is taking off
On 13-jan-04, at 10:36, Paul Robinson wrote:
Continuing work on IPv4 only creates the illusion that it is a viable
protocol for application developers to rely on for future income.
Are you suggesting then, that all RFCs based on IPv6 should be...
stopped?
I think that one should read IPv4...
On Tue, Jan 13, 2004 at 10:30:05AM +, Tim Chown wrote:
It is prevalent wherever there is broadband. And that is where (with the
extra bandwidth and always-on) connectivity into the network is desirable.
Not around me it isn't. In the UK, even with cable modem providers, I have
non-NAT -
On Tue, Jan 13, 2004 at 11:21:33AM +, Paul Robinson wrote:
Not around me it isn't. In the UK, even with cable modem providers, I have
non-NAT - as they are known in the European ISP industry RIPE addresses -
and although I've installed NAT myself to enable quick and easy WiFi access
Paul Robinson wrote:
I think if we say From the middle of next year, no more IPv4 RFCs or drafts
please, then vendors and application developers will have to sit up and
take notice. Remember, the protocols take between 6-36 months to be deployed
for real, so what we'd actually be saying is we
On Tue, Jan 13, 2004 at 06:43:43AM -0600, Randall R. Stewart (home) wrote:
Something about this thread confuses me :-0 Now maybe it
is just me having my head down in the sand.. I work in the
transport area mainly and last I checked:
1) TCP/SCTP and UDP all run over IPv6, in fact SCTP
From: Paul Robinson [EMAIL PROTECTED]
of course, if after a couple of years it isn't working, there is nothing
stopping the IETF rescinding, and supporting IPv4 once more due to
customer pressures. :-)
Hello? That's where we are *now*.
May I remind you that IPv6 has been
At 07:37 13/01/04, Joe Abley wrote:
The operational cost of supporting both v4 and v6 from the network
perspective not great, based on our experience (although the support load
for v6 clients to content hosted in our network is currently much lower
than for v4 clients, as you'd expect).
I'd be
Just a small comment:
Should not you first investigate the reason why IPv6 is not successful in
terms of deployment (yet)? So that, we won't make the same mistakes if the
world decides to sth else
At 09:39 AM 1/13/2004 -0500, J. Noel Chiappa wrote:
From: Paul Robinson [EMAIL
J. Noel Chiappa wrote:
Anyway, the point is that successful networking
technologies don't take 10 years to succeed. They
either catch on, or they don't, and after 10
years this one has not caught on.
And as of the DoD requirements, those of us that are old enough will
remember the ADA
From: Tony Hain [EMAIL PROTECTED]
Like it or not, the IETF must stop wasting time and effort building new
structures on a crumbling framework.
I agree completely.
Now, can we all agree that almost 10 years after it was formally adopted by
the IETF, IPv6 is has clearly not
From: Tony Hain [EMAIL PROTECTED]
You seem to have missed the point. ... You will never hear a consumer
demanding IPv6 .. You won't hear ISP's demanding IPv6 unless their
customers are demanding apps that run over IPv6 (even then the consumer
is more likely to use an
Noel Chiappa writes:
Now, can we all agree that almost 10 years after it was formally adopted by
the IETF, IPv6 is has clearly not succeeded in becoming the ubiquitous
replacement for IPv4, and needs to be moved to Historic, so we can turn our
energy and attention to things that *will*
Hayriye Altunbasak wrote:
Should not you first investigate the reason why
IPv6 is not successful in terms of deployment
(yet)? So that, we won't make the same mistakes
if the world decides to sth else
These reasons are well-known and two-fold:
1. It's an investment without any
--On Tuesday, 13 January, 2004 15:41 +0100 jfcm [EMAIL PROTECTED]
wrote:
Gentlemen,
let agree IETF is lacking formal interfaces with the real
world of users and the real world of operators. John
Klensin's official participation to the ICANN BoD is a first
good step towards formal links with
On Tue, 13 Jan 2004 08:23:10 PST, Michel Py [EMAIL PROTECTED] said:
And as of the DoD requirements, those of us that are old enough will
remember the ADA language.
GOSIP.
pgp0.pgp
Description: PGP signature
On Tue, 13 Jan 2004, J. Noel Chiappa wrote:
The upgrade path (replace the entire internet layer in one fell swoop) IPv6
adopted clearly isn't working. Time to try something rather different.
Exactly. As we have been saying for years not, we must aim for
co-existence of IPv4 and IPv6, not
Pekka Savola
Exactly. As we have been saying for years not,
we must aim for co-existence of IPv4 and IPv6,
not replacing IPv4 with IPv6.
IPv6 is currently not worth the price of dual-stack, which is the very
reason it is not being deployed. As of transition mechanisms, they're
not good
On Tue, 13 Jan 2004, Pekka Savola wrote:
On Tue, 13 Jan 2004, J. Noel Chiappa wrote:
The upgrade path (replace the entire internet layer in one fell swoop) IPv6
adopted clearly isn't working. Time to try something rather different.
Exactly. As we have been saying for years not, we must
On 1/12/2004 9:03 PM, Noel Chiappa wrote:
IPv6's only hope of some modest level of deployment is, as the latter
part of your message points out, as the substrate for some hot
application(s). Somehow I doubt anything the IETF does or does not do
is going to have any affect on whether or not
On Tue, 13 Jan 2004, Michel Py wrote:
IPv6 is currently not worth the price of dual-stack, which is the very
reason it is not being deployed.
Some think it's worth the price. In many cases, the price (in terms
of money, at least) is zero.
In any case, the users are given the opportunity to
Noel Chiappa wrote:
...
IPv6 simply isn't going to get deployed as a replacement for IPv4. It's
just
not enough better to make it worth switching - and you can flame all day
about
how NAT's are preventing deployment of new applications, but I can't run
an
SMTP or HTTP server in my house
Yup, it needs a killer app or feature. Bigger address space was that
feature, but one made moot by NATs.
VoIP and multimedia via SIP without having a resident network engineer in
your attic.
Enough said?
Dan
On 1/13/2004 1:06 PM, Dan Kolis wrote:
Yup, it needs a killer app or feature. Bigger address space was that
feature, but one made moot by NATs.
VoIP and multimedia via SIP without having a resident network engineer in
your attic.
Enough said?
in your attic implies end-user benefit. As I
Eric A. Hall wrote:
On 1/12/2004 9:03 PM, Noel Chiappa wrote:
IPv6's only hope of some modest level of deployment is, as the latter
part of your message points out, as the substrate for some hot
application(s). Somehow I doubt anything the IETF does or does not do
is going to have any affect
Tony,
Tony Hain wrote
Like it or not, we are at the end of the IPV4 road
I think that's where you missed it. We are not. The truth is that the
end of the IPv4 road is in sight; how far away we don't really know, as
looking through the NAT binoculars does not seem to make it closer. How
fast we
On 1/13/2004 1:24 PM, Joe Touch wrote:
Eric A. Hall wrote:
Other than conserving addresses, NAT features are basically poison
resold as bread.
Heck, I don't even like the conservation feature.
Misguided allocation policies created a false demand. We would have been
better off to run out
--On Monday, 12 January, 2004 22:03 -0500 Noel Chiappa
[EMAIL PROTECTED] wrote:
...
IPv6 simply isn't going to get deployed as a replacement for
IPv4. It's just not enough better to make it worth switching
- and you can flame all day about how NAT's are preventing
deployment of new
John C Klensin wrote:
Noel, I'm slightly more optimistic along at least two other dimensions...
...
(2) The no servers unless you pay business rates, and its close
relative, you don't get to run VPNs, or use your own email address
rather than ours nonsense you and many others are experiencing
J. Noel Chiappa wrote:
[..]
(Yes, I know, the support situation has improved and we expect wide-scale
deployment in the next year - I think I've heard that same mantra every year
for the last N years. I really ought to go back through my email folders and
create a web page of IPv6
From: John C Klensin [EMAIL PROTECTED]
...
(1) As others have pointed out, the knowledge/skill level of a
typical ISP seems to be on a rapid downslope with no end in
sight. ...
...
* The difference between those business rates and
whatever you are paying are mostly
At 18:39 13/01/04, John C Klensin wrote:
--On Tuesday, 13 January, 2004 15:41 +0100 jfcm [EMAIL PROTECTED] wrote:
Gentlemen,
let agree IETF is lacking formal interfaces with the real world of users
and the real world of operators. John Klensin's official participation
to the ICANN BoD is a
At 02:02 PM 1/12/2004, Tony Hain wrote...
While one aging application does not constitute 'the Internet', this should
be taken as an early indicator of things that are happing, with more to
come.
The true threat is administrative, not technical. It won't do any good to have an IPv6
address
While one aging application does not constitute 'the Internet', this should
be taken as an early indicator of things that are happing, with more to
come.
http://www.fourmilab.ch/speakfree/eol/
Like it or not, the IETF must stop wasting time and effort building new
structures on a crumbling
Tony Hain wrote:
While one aging application does not constitute 'the Internet', this should
be taken as an early indicator of things that are happing, with more to
come.
http://www.fourmilab.ch/speakfree/eol/
Like it or not, the IETF must stop wasting time and effort building new
structures on
On 12-jan-04, at 20:55, Gordon Cook wrote:
http://www.fourmilab.ch/documents/digital-imprimatur/ is the really
spooky essay. Excerpted in my December issue.
Read the Digital Imprimatur if you haven't already.
I find it a tad on the wordy side... (27731 words, to be precise, more
than an hour
On 12-jan-04, at 21:13, Paul Robinson wrote:
The modern Internet is run by marketing, not technical, requirements.
IPv6 will not take off any time soon because neither the end-user nor
the service provider sees the need. The moment AOL, Wanadoo, Tiscali,
World Online et al shout out we *need*
: Monday, January 12, 2004 12:13 PM
To: Tony Hain
Cc: [EMAIL PROTECTED]
Subject: Re: Death of the Internet - details at 11
Tony Hain wrote:
While one aging application does not constitute 'the Internet', this
should
be taken as an early indicator of things that are happing, with more
Tony Hain wrote:
You won't get the development community to pay attention
to the simplicity afforded by IPv6 until the IETF stops
wasting time trying to extend a dead protocol.
If one in {IPv4,IPv6} could be qualified as dead, it's IPv6. If it was
not for IPv4, the majority of this list would
On 12 Jan 2004, at 15:13, Paul Robinson wrote:
IPv6 will not take off any time soon because neither the end-user nor
the service provider sees the need. The moment AOL, Wanadoo, Tiscali,
World Online et al shout out we *need* IPv6 it will happen. Quickly.
Interestingly, whenever we deploy an F
89 matches
Mail list logo
