Subject: Re: Deployment Cases

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Jan 2008 11:54:58 +0100

Dave Crocker wrote:
> Well, that's such a reasonable question, I did a subjective review of 
> Proposed Standard RFCs for the last number of years -- ignoring that 
> most recent and going back to rougly RFC 2500 -- looking for acronyms 
> that were for significant IETF-generated efforts.
> ...

I'd also consider WebDAV a success (RFC2518).

BR, Julian

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Tue, 01 Jan 2008 11:45:01 -0800

Folks,

Felíx Año Nuevo.

 From some feedback, here are changes to the list.  I'm adding guesses about
the current degree of success each has had.  Please take it as a request to
comment, whether you agree or disagree, as well as a request to add items.

However, besides indicating a simple agree/disagree, please provide some 
basis, particularly if you believe something has gained significant adoption 
and use.  Indicate who the user community is and what you think its size is.

Note that some items actually pre-date 10 years, but I'm keeping them in since
the still represent significant IETF activity:

Within IETF:

> IPv6

    15 years and counting.

> DNSSec

    13 years and counting.

> Enum

    How much real use is this getting?  I know that activity remains high, but
I haven't seen much indication of deployment and use in large scale.  If it is 
popular in closed environments, which ones?

> CPIM

    Failure.

> BEEP

    Failure.

> MSRP

    I don't know anything about this one.

> SCTP

    My impression is that this has not gained much traction.

> IPSec

    Failure, except maybe as part of the VPN niche?

> SASL

    Success?

> CalDav

    No significant uptake yet?

> RTP

    Success?  I seem to see it on streaming applications' configuration 
windows, but does it really get widely used?

> NETCONF

    Failure?

> IMAP4

    Success within organizations?  Not much between?

> (a variety of PKI efforts?)

    Failure?

> LDAP

    Although X.500 came from outside the IETF, it was largely a failure and
the changes made in the IETF had a substantial impact.  My reading is that it
is quite successful, within organizations, if not between them.

> OPES

    Failure?

> VPIM

    How much uptake has there been on this?

> FFPIM

    Failure, except maybe within-organization among related products.

> GEOPRIV

    No uptake yet?

> Diameter

    How much uptake has this gotten so far?

> DDDS

    No uptake yet?

> SIEVE

    I'm keeping Sieve in, because it had to history prior to the IETF and it
came out of the IETF culture.  I think it's developing organically first,
rather than from a working group, is secondary, although quite interesting.

 From outside IETF:

> XMPP
> iSCSI
 > MPLS

Other:

> PPP

   Much older than 10 years and not a major, current activity.  But, yes, an
IETF success story.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 1 Jan 2008 21:32:47 +0100

On 31 dec 2007, at 21:09, Dave Crocker wrote:

>> I don't think that's valid statistics: obviously many of the  
>> protocols in question were already successful before they were  
>> given to the IETF, which isn't necessarily the case for protocols  
>> developed "in-house".

> That's the point:  protocols created in the IETF, over the last 10  
> years, do not have a very good record of deployment and use.   
> Protocols created outside the IETF and then brought into the IETF  
> have a better track record.

But you missed my point, which is that stuff brought to the IETF will  
almost certainly already have some measure of success, while stuff  
developed within the IETF doesn't, because it's completely new. To  
make that comparison fair, we'd have to compare work started within  
the IETF with work started elsewhere regardless of whether it's  
brought to the IETF later.

Apart from that, the IETF has been around for 20 years now and IP for  
a few years longer than that. By now all the basic stuff has been  
invented, refined and reinvented a few times over. The low hanging  
fruit is gone, what's left is generally trivial or (almost)  
unsolvable. I don't think other standards organizations of similar  
maturity knock new protocols out of the park each and every time,  
either.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 01 Jan 2008 12:58:43 -0800

Iljitsch van Beijnum wrote:

> developed within the IETF doesn't, because it's completely new. To make 
> that comparison fair, we'd have to compare work started within the IETF 
> with work started elsewhere regardless of whether it's brought to the 
> IETF later.

Maybe.  It depends what we are trying to understand.  If we are trying to 
understand which kinds of IETF activities have more success and which kind 
have less, then the sampling method you are suggesting does not apply.

If we are trying to compare the IETF's rate of success at its new initiatives, 
compared with the rates of other venues, then your suggestion makes sense. 
While I think that that is an entirely worthy consideration, I don't think it 
is nearly as urgent as trying to understand how the IETF should spend its 
limited resources.

> Apart from that, the IETF has been around for 20 years now and IP for a 
> few years longer than that. By now all the basic stuff has been 

(FWIW, "a few years longer" is actually 11.  TCP was first implemented in 1976.)

> invented, refined and reinvented a few times over. The low hanging fruit 
> is gone, what's left is generally trivial or (almost) unsolvable. I 

While that well might be true, I'm not sure there is any serious basis for 
knowing it to be true.  At a minimum, it would require mapping out some sort 
of topology of capabilities that could be pursued and showing that most of the 
terrain has already been explored. (I could imagine the exercise showing you 
are right, but think it best that we not accept your point on faith.)

A counterpoint is that we seem to see bursts of innovation every 10 years or 
so, with each one providing some massive improvements, including to existing 
capabilities.

> don't think other standards organizations of similar maturity knock new 
> protocols out of the park each and every time, either.

"each and every time" is just the sort of language that undermines this sort 
of discussion.  I don't recall anyone suggesting that a perfect track record 
is required, so citing it as a criterion is not very helpful.

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 01 Jan 2008 12:59:05 -0800

d/

-- 

   Dave Crocker

---

From: Tony Finch <[email-masked]>
Date: Tue, 1 Jan 2008 22:00:32 +0000

>    Success within organizations?  Not much between?

Lots between. It's common for IMAP clients to access remote message stores
across organizational boundaries. The work on remote message submission
(RFCs 4409 and 5068) are complementary to remote IMAP.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LUNDY FASTNET: SOUTHEAST 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR ROUGH,
OCCASIONALLY VERY ROUGH. OCCASIONAL DRIZZLE. MODERATE OR GOOD, OCCASIONALLY
POOR.

---

From: "Ping Pan" <[email-masked]>
Date: Tue, 1 Jan 2008 18:00:47 -0800

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Tuesday, January 01, 2008 11:45 AM
>  From outside IETF:
> 
> > XMPP
> > iSCSI
>  > MPLS
> 

Dave,

MPLS is an IP technology that has been largely driven inside IETF. Millions
of users have benefited from the backbones running with MPLS protocols. It's
about 10-year old. MPLS has refined, modified and reused many other IETF
protocols, RSVP, OSPF, ISIS and BGP etc.

Also for the role of IETF, I think it should take a more active role in
creating standard protocols for the industry. One example comes to mind is
in the area of streaming video - way too many proprietary protocols today.
Another place that needs some serious help is P2P. The lack of standard in
those areas has negative impact to their growth.

Regards,

- Ping

---

From: Franck Martin <[email-masked]>
Date: Wed, 02 Jan 2008 15:09:25 +1200

Isn't it the role of the IRTF/IAB/? to look at which areas should the
IETF put more effort into?

Is there some kind of vision, road map, looking forward?

A wish list, which would stay as a wish list pending people willingness
to work on the items.

I think there is a need to analyse orientations, like bringing an
outsider to speak to IETF to raise new issues, like at last IETF with
power and computing and the fact that wakeonlan does not work and would
be real useful: how much intelligence to put in the card to wake up the
PC only when needed and not every time someone send a packet to the card.

Cheers

-- 
Franck Martin
ICT Specialist
[email-masked]
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

---

From: "Ping Pan" <[email-masked]>
Date: Tue, 1 Jan 2008 20:00:54 -0800

Personally, I don't believe in any "authority" telling me what's needed,
what would be the future and what to do next. Necessity is the mother of all
invention. The market today needs to have the standard protocols in a number
of areas. IETF seems to be the right place to get job done. ;-)

Best regards,

- Ping

  _____  

From: Franck Martin [mailto:[email-masked]] 
Sent: Tuesday, January 01, 2008 7:09 PM
To: Ping Pan
Cc: [email-masked]; 'IETF discussion list'
Subject: Re: Deployment Cases

Isn't it the role of the IRTF/IAB/? to look at which areas should the IETF
put more effort into?

A wish list, which would stay as a wish list pending people willingness to
work on the items.

I think there is a need to analyse orientations, like bringing an outsider
to speak to IETF to raise new issues, like at last IETF with power and
computing and the fact that wakeonlan does not work and would be real
useful: how much intelligence to put in the card to wake up the PC only when
needed and not every time someone send a packet to the card.

Cheers

Ping Pan wrote: 

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]]
Sent: Tuesday, January 01, 2008 11:45 AM
 From outside IETF:

XMPP
iSCSI

 
Dave,

 
Regards,
 
- Ping

---

From: Franck Martin <[email-masked]>
Date: Wed, 02 Jan 2008 19:26:00 +1200

This has nothing to do with an authority telling you what to do, but to
identify weakness, trends and communicate them to the rest of the IETF.
Up to the IETF to tackle the challenge or not.

Cheers

Ping Pan wrote:
>
> Personally, I don’t believe in any “authority” telling me what’s
> needed, what would be the future and what to do next. Necessity is the
> mother of all invention. The market today needs to have the standard
> protocols in a number of areas. IETF seems to be the right place to
> get job done. ;-)
>
>  
>
> Best regards,
>
>  
>
> - Ping
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Franck Martin [mailto:[email-masked]]
> *Sent:* Tuesday, January 01, 2008 7:09 PM
> *To:* Ping Pan
> *Cc:* [email-masked]; 'IETF discussion list'
> *Subject:* Re: Deployment Cases
>
>  
>
> A wish list, which would stay as a wish list pending people
> willingness to work on the items.
>
> power and computing and the fact that wakeonlan does not work and
> would be real useful: how much intelligence to put in the card to wake
> up the PC only when needed and not every time someone send a packet to
> the card.
>
> Cheers
>
> Ping Pan wrote:
>
>  
>   
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> SOPAC, Fiji

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Jan 2008 08:16:11 -0800

I think the questions of precedence, scope, etc. are interesting but not particularly on point. In may view there are two types of work the IETF performs: Infrastructure and Functional.
 
Most IETF protocols fall into the functional category. They may be building blocks for other protocols to build on or they may be application protocols in their own right but they are designed to support a clearly defined function that is either currently unmet or there are difficulties with the manner in which it is being met (cost, patent encumberance, lack of extensibility, ambiguity, proprietary control, etc.)
 
Functional protocols typically have a very clear deployment case: there is some form of functionality that users require which the protocol delivers. In many cases the choice is between no functionality and use of the protocol. Alternatively there is a situation where multiple protocols have developed as de-facto standards and a quorum of proprietary stakeholders have come to a mutual agreement that there is a need for an open standard.
 
The only cases in which a deployment case would usually be useful for a functional protocol is if either 1) the success of the protocol is dependent on establishing a network effect or 2) there is an established proprietary standard that the open standard is intended to displace. Let me be clear here: I do not assert that development deployment cases should be mandatory in such cases but I do think that they might be of use in working out how to develop a protocol that has a chance of success in a difficult situation of this type.

The deployment problem is much greater for infrastructure protocols such as IP, DNS and PKI. By infrastructure I mean a protocol whose sole purpose is to provide value as a platform on which to build other systems. IP and DNS are unique in the sense that they are the only IETF protocols that the IETF can and must claim sole control of. Development of protocols that compete with or functionally replace SMTP, PKIX or TLS could take place in W3C or OASIS. If effective change control of IP or DNS ever left IETF control it is the end of the IETF.
 
Another difference with IP is that the IETF is competing with its past success. What made IPv4 successful is also the reason that end users are reluctant to change. There is a major difference between reseach and development. IPv4 was the result of pure research. To succeed IPv6 must be a development, an incremental enhancement on the legacy base. The deployment case for IPv4 was clear: there was no effective, non-proprietary alternative established so the choice was between the Internet and no Internet.
 
The range of considerations that it is necessary to take account of in proposing to change a rapidly growing infrastructure with a billion users is much wider than the range of considerations that were relevant in developing IPv4. To answer Brian's point directly: Where the future of IP is concerned the IETF is and must be as narrowly focused as the technology specific standards organizations he refers to.

We have a mismatch here in objectives:
 
1) IETF Objective: Deploy IPv6.
2) Stakeholder Objective: Avoid the consequences of IPv4 address space exhaustion.

If we continue to simply assert that #1 satisfies #2 and thus the choice is inevitable we miss the fact that the stakeholders have many other choices. We fall victim to the fallacy of the excluded middle.
 
The reason I am proposing deployment cases is that while I beleive that #1 is the ultimate end state I also believe the same of PKI and cryptographic security systems. There is no technology developed in computer science that provides a more compelling intellectual case than Public Key Cryptography.  Yet after three decades our use of PKI barely scratches the surface of what is possible. We need to ask why.

The idea of deployment cases is not to turn engineers into marketers but to facilitate a conversation between the engineers designing the product and the stakeholders whose support is required to deploy it. The number of people who have ever attended an IETF is approximately on thousandth of one percent of the Internet user population. If we want to influence we have to communicate in a language they accept.
 
The stakeholder leadership may to first order be modeled by a warren of rabbits: myopic. The more enlightend of them are driven by the needs of the next two quarters, for most it is only one. When faced with a threat their instinct is to run away and hide. The odd Caerbannog attending the IETF is just as frustrated as the rest of us. Recently I spoke to a senior executve at a very large manufacturing company that is 100% certain that their principal product line will be completely obsolete within five years, most of you would say it is obsolete today. Their idea of forward planning for the change is not investing in any new equipment that is unlikely to see a return before that time.
 
Mere exhaustion of the IPv4 address space is not going to be a sufficient incentive unless (1) it is certain to happen in the next two quarters and (2) the impact is certain to be negative on the specific stakeholder in question. 

If we are to turn the stakeholders around we have to offer them a compelling proposition. Merely preventing the exhaustion of the unallocated IPv4 pool is not a sufficient incentive for a stakeholder executive sitting on a large pool of unused addresses. 
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Jan 2008 08:18:04 -0800

Necessity may be the mother of invention. But in order to invent we must know to distinguish what is necessary from cool capabilities offered to us by the technology.
 
Twitter is really, really cool. It also has the utility of a square tomato: A solution to a problem few people know about and even fewer care about.

________________________________

From: Ping Pan [mailto:[email-masked]]
Sent: Tue 01/01/2008 11:00 PM
To: 'Franck Martin'
Cc: [email-masked]; 'IETF discussion list'
Subject: RE: Deployment Cases

Personally, I don't believe in any "authority" telling me what's needed, what would be the future and what to do next. Necessity is the mother of all invention. The market today needs to have the standard protocols in a number of areas. IETF seems to be the right place to get job done. ;-)

Best regards,

- Ping

________________________________

Isn't it the role of the IRTF/IAB/? to look at which areas should the IETF put more effort into?

A wish list, which would stay as a wish list pending people willingness to work on the items.

I think there is a need to analyse orientations, like bringing an outsider to speak to IETF to raise new issues, like at last IETF with power and computing and the fact that wakeonlan does not work and would be real useful: how much intelligence to put in the card to wake up the PC only when needed and not every time someone send a packet to the card.

Cheers

Ping Pan wrote: 

	-----Original Message-----
	From: Dave Crocker [mailto:[email-masked]]
	Sent: Tuesday, January 01, 2008 11:45 AM
	 From outside IETF:

		XMPP
		iSCSI

 
Dave,

 
Regards,
 
- Ping

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 2 Jan 2008 18:28:11 +0100

On 2 jan 2008, at 17:16, Hallam-Baker, Phillip wrote:

> Another difference with IP is that the IETF is competing with its  
> past success. What made IPv4 successful is also the reason that end  
> users are reluctant to change. There is a major difference between  
> reseach and development. IPv4 was the result of pure research. To  
> succeed IPv6 must be a development, an incremental enhancement on  
> the legacy base. The deployment case for IPv4 was clear: there was  
> no effective, non-proprietary alternative established so the choice  
> was between the Internet and no Internet.

It's the job of the IETF to develop a protocol like IPv6, not to  
deploy it. The lack of need to deploy it (which we won't be able to  
judge for another decade or so, we still have a billion unused IPv4  
addresses currently) doesn't imply a lack of need to develop it. IPv4  
wasn't meeting projected future goals. The only resposible thing the  
IETF could do was develop (something like) IPv6. And that's what the  
IETF did. Success, we all go home early today.

Now it may turn out that not deploying IPv6 is seen as more attractive  
than deploying IPv6 by the users of the internet. However, there was  
no way to authoritatively predict that 15 years ago, so NOT developing  
IPv6 would have been irresponsible.

---

From: Tony Finch <[email-masked]>
Date: Wed, 2 Jan 2008 18:27:17 +0000

> those areas has negative impact to their growth.

A lot of people wish that p2p were less successful :-)

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE FAEROES: SOUTHEAST 6 TO GALE 8. VERY ROUGH. WINTRY SHOWERS. MODERATE
OR GOOD.

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 02 Jan 2008 10:31:39 -0800

> A lot of people wish that p2p were less successful :-)

Bittorrent has about as clear a protocol spec as anything gets. The fact
that it hasn't been blessed by an SDO has not precluded multiple
inter-operable implementations.

---

From: "Ping Pan" <[email-masked]>
Date: Wed, 2 Jan 2008 11:03:55 -0800

Exactly! It is one impressive spec: clean and simple. Looking at its
adaptation, I wonder why in the world it was not adapted and done in IETF.
On the other hand, it may take too long in IETF, and would require extensive
debate over architecture, framework, requirements... ;-)

- Ping

> From: Joel Jaeggli [mailto:[email-masked]] 
> Sent: Wednesday, January 02, 2008 10:32 AM
> To: Tony Finch
> Cc: Ping Pan; 'IETF discussion list'
> >> Another place that needs some serious help is P2P. The lack of 
> >> standard in those areas has negative impact to their growth.
> > 
> Bittorrent has about as clear a protocol spec as anything 
> gets. The fact that it hasn't been blessed by an SDO has not 
> precluded multiple inter-operable implementations.
> 
> > Tony.
> 
>

---

From: <[email-masked]>
Date: Thu, 3 Jan 2008 00:05:37 -0000

> The reason I am proposing deployment cases is that while I 
> beleive that #1 is the ultimate end state I also believe the 
> same of PKI and cryptographic security systems. There is no 
> technology developed in computer science that provides a more 
> compelling intellectual case 

...to computer scientists...

> than Public Key Cryptography.  
> Yet after three decades our use of PKI barely scratches the 
> surface of what is possible. We need to ask why.

Human psychology.

> Recently I spoke to a senior 
> executve at a very large manufacturing company that is 100% 
> certain that their principal product line will be completely 
> obsolete within five years, most of you would say it is 
> obsolete today. Their idea of forward planning for the change 
> is not investing in any new equipment that is unlikely to see 
> a return before that time.

How many senior executives in Internet operators are consciously
not investing in any IPv4 products that will not provide a 
return before the global IPv4 space is exhausted. I believe that
very few such executives have even made this fundamental decision.

As a result, there is not yet enough pressure on vendors to get
their products IPv6 ready before 2010. Where are the Internet 
gateways that seamlessly work with IPv4 or IPv6 on either side
of the box? Where are the OSS systems? Where are the firewalls,
load balancers, and other linchpins of the data center? Given the
fact that network operators need a fair amount of lead time to test
and certify new equipment (or software) before easing it into
production in stages, I don't believe that we are as advanced as
we need to be by this point in time.

> Mere exhaustion of the IPv4 address space is not going to be 
> a sufficient incentive unless (1) it is certain to happen in 
> the next two quarters and (2) the impact is certain to be 
> negative on the specific stakeholder in question. 

Even this is problematic because the fund managers and 
investment analysts are not yet asking senior executives
how they plan to mitigate IPv4 exhaustion. If senior executives
don't consider the issue, then they won't take action even if
it is certain to happen in the next two quarters.

> If we are to turn the stakeholders around we have to offer 
> them a compelling proposition. Merely preventing the 
> exhaustion of the unallocated IPv4 pool is not a sufficient 
> incentive for a stakeholder executive sitting on a large pool 
> of unused addresses. 

It is not the exhaustion of the free pool that should be feared.
It is the fact that your IPv4 network will lose the ability to
grow (and therefore drive growth in revenue) when there are no
free addresses. You will be forced to spend a lot of money on
either implementing IPv6 in a last minute panic, or spend a lot
of money on "strings and sealing wax" to make IPv4 services more
or less feasible. 

The sooner that companies take action, the sooner they can navigate
an optimal path through these waters. In some case, spending on 
things like double NAT for IPv4 may well provide a return on 
investment, but that has to be balanced against a scenario in 
which more investment dollars go towards making an IPv6 Internet
service functionable earlier.

Unless I've missed something recent, the IETF did not do a lot of
work on the scenario where IPv4 islands need to communicate over
an IPv6 Internet, talking to both IPv4 and IPv6 services. Yet this
core-outwards scenario seems to be the primary transition scenario
that we are driving towards. The first companies to be impacted
by lack of IPv4 addresses are the core network operators, so they
must transition to IPv6 before the end user islands.

--Michael Dillon

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 03 Jan 2008 01:24:50 +0100

[email-masked] wrote:
[..]
> an IPv6 Internet, talking to both IPv4 and IPv6 services.

It is called dual-stack.

One will have IPv4 NAT and IPv6 e2e. This is already the case for most
end-users who have received an IPv6 block from their provider or who
went to a tunnel broker to get a nice fat /48 IPv6, while they only got
a /32 IPv4 from their provider. This has actually been a huge incentive
for a lot of people to start using IPv6 and to start using it everywhere
they have hosts as this way they can reach all their hosts at home and
have full e2e connectivity between machines, thus allowing you to SSH in
to your local box. This is a, by now, 8 year old trick btw ;)

The big question of course is: what exact problem do you want to solve?

Stating "I want to connect from IPv4 to IPv6", can mean a lot of things,
is this HTTP? SMTP? or do you really want a generic solution?

As for the case where you have a limited number of public IPv4 addresses
and want to provide them to the clients, who will have IPv6 all the
time, there is a sweet little protocol called DSTM (See for more
http://www.dstm.info) which solves that problem. Of course a protocol
like AYIYA also allows a IPv4 over IPv6 tunnel and lastly we also still
have SOCKS and application-specific proxies (eg MX's and HTTP proxies).
Oh I forget of course our good old ones: L2TP, PPTP etc :)

There are a LOT of choices, probably too many. The following URL:
http://www.sixxs.net/faq/connectivity/?faq=comparison has a short list
of them, not all of them are on it of course. eg tinc/OpenVPN etc are
missing.

Greets,
 Jeroen

---

From: Tony Hansen <[email-masked]>
Date: Wed, 02 Jan 2008 22:16:01 -0500

Dave Crocker wrote:
> A number of questions come to mind:
> 
> 1.  What additions or removals should be made to the list?

add MsgTrk

	Tony Hansen
	[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 03 Jan 2008 10:11:44 +0000

> debate over architecture, framework, requirements... ;-)
Wouldn't Bittorrent fail congestion considerations review?

Stewart

---

From: <[email-masked]>
Date: Thu, 3 Jan 2008 10:35:24 -0000

> > Unless I've missed something recent, the IETF did not do a 
> lot of work 
> > on the scenario where IPv4 islands need to communicate over an IPv6 
> > Internet, talking to both IPv4 and IPv6 services.
> 
> It is called dual-stack.

That seems to simply ignore the issue by saying, let there be IPv4
everywhere for those who need it. But if there are not enough
addresses to grow the IPv4 infrastructure, you can't have IPv4
everywhere.

> The big question of course is: what exact problem do you want 

An IPv4 island, that is blissfully unaware of the IPv4 address
crunch until far too late, wants to avoid changing their network
but still maintain connectivity to both the IPv6 and the IPv4 
Internet. They may have to connect to an IPv6 ISP (for instance
if their IPv4 ISP goes bankrupt or they move an office location)
or they may connect to an IPv4 ISP who peers with a dual-stack
ISP or 6PE ISP. How do they continue to access all Internet services
from their IPv4 island, regardless of whether or not the services
are using IPv6 only?

Note that this is rather similar to the question raised regarding
the IPv4 outage at an IETF meeting. How does an IPv4 laptop user
continue to function without interruption when only IPv6 Internet
access is available at an IETF meeting? Assume that IPv4 wifi is
functioning and that the user does not change anything on their
laptop to accommodate the fact that connectivity is via IPv6. And
include the scenario where the IPv4 user successfully accesses an
arbitrary protocol server which is IPv6 only and has no A records
in its DNS.

> Stating "I want to connect from IPv4 to IPv6", can mean a lot 
> of things, is this HTTP? SMTP? or do you really want a 
> generic solution?

A generic solution that will work for all TCP and UDP protocols.

I don't believe that there is an IETF solution for this scenario
which I expect to be a very common scenario specifically because 
transition to IPv6 is being triggered by an IPv4 address shortage
whose effects will be felt first in the network core and ripple
outward from there.

--Michael Dillon

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 03 Jan 2008 11:44:00 +0100

> from their IPv4 island, regardless of whether or not the services

What is so difficult in going dual-stack? IPv4 is NATted, as it already
is at a lot of places, and IPv6 comes in there using a tunnel.

Most 'services' that people use over the internet, fall under either:
 - HTTP -> Use a HTTP Proxy with both IPv4 & IPv6
 - SMTP -> Use a SMTP server which supports both IPv4 & IPv6

Anything else? Not really. As such, which exact services do you want to
transition?

> access is available at an IETF meeting?

As your source address breaks the moment your connection is interrupted
your have an interruption already. But you probably mean so that they
can continue using service X, well first start by defining service X.

The generic answer is of course NAT-PT, but there is a big reason why we
don't want that. Another trick is totd and there are a number of these
transition functions which are already in place and in use for a long
long time.

As such the sole problem left, which is going to be resolved soon, is
DNS, we will finally have AAAA in the root, next step DNSSEC :)

[..]
> A generic solution that will work for all TCP and UDP protocols.

NAT-PT, but NAT doesn't understand all the protocols, if it did, then we
would not have to go to IPv6 in the first place.

> whose effects will be felt first in the network core and ripple

As you clearly believe that there is no such thing, then make a list of
all the things you have tried and where they fail to meet your
requirements. Then make a list of the requirements you are missing and
propose that we solve that problem.

Greets,
 Jeroen

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 3 Jan 2008 08:30:59 -0800

Yes, as you point out the generic answer to the problem is NAT-PT which was recently squashed after a cabal got together.
 
My point here is that the thinking on the transition in the IETF to date has all been of the form 'well everyone is going to have to become like us, only they can't possibly expect to so its a bit of a problem but not our problem'.

I received a lot of criticism when I first proposed that the IETF embrace NAT as a transition tool rather than deprecate it. The idea that we should actively encourage the NAT-ing of IPv4 was considered as unacceptable as Brian and others now find my proposals for changing the way that the IETF operates and the considerations it takes into account. 
 
I don't see much dispute on that point today. Pretty much everyone seems to now accept that we are going to run out of IPv4 addresses before IPv6 deployment is complete and that some form of address sharing is therefore inevitable. What we have failled to do so far is to act on that.

Take a look at what has happened in the film industry, the camera film industry that is. Every manufacturer of 35mm film has understood that digital would replace film in the consumer market shortly after 2005, that studios would have transitioned from 35mm to digital by 2010 and that distribution of 35mm prints will effectively cease by 2015. Virtually everyone in that business understands exactly what the story is.
 
Then take a look at what those companies are doing about it. Polaroid has already gone bankrupt and Kodak is desperately trying to re-invent itself as a digital photography provider in time. Both companies understood what would happen to their market and the new technologies that would come in. But neither company ever made a serious attempt to become Sandisc.
 
Yes, whole industries can and do march right off a cliff in lockstep even when they see the cliff comming. 

From: Jeroen Massar [mailto:[email-masked]]
Sent: Thu 03/01/2008 5:44 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Deployment Cases

[..]

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 3 Jan 2008 20:39:17 +0100

On 3 jan 2008, at 17:30, Hallam-Baker, Phillip wrote:

> Yes, as you point out the generic answer to the problem is NAT-PT  
> which was recently squashed after a cabal got together.

I think the second v6ops meeting in Vancouver showed a decent amount  
of interest in resurrecting it again. (This is becoming a bit of a  
third rate zombie movie, though.)

> Pretty much everyone seems to now accept that we are going to run  
> out of IPv4 addresses before IPv6 deployment is complete and that  
> some form of address sharing is therefore inevitable.

Hold on, you're going a bit too fast there.

The most basic transition strategy would be a flag day. For obvious  
reasons, this doesn't work.

The second most basic transition strategy would be to add IPv6 until  
everyone is dual stack, and then start removing IPv4. This doesn't  
work either, because nobody has an incentive to add IPv6 until they  
can remove IPv4 and nobody can remove IPv4 until everyone is dual stack.

This means that the real transition MUST be such that there is a time  
during which there are both IPv4-only and IPv6-only hosts. With  
improved NAT-PT this won't be any worse than IPv4+NAT and even without  
any form of NAT-PT it's still possible to get a lot done with proxies,  
so this isn't necessarily a problem.

The interesting thing is that running out of IPv4 addresses in and of  
itself doesn't make IPv6 more attractive, even though NOT running out  
of IPv4 addresses definitely makes IPv6 NOT attractive to most people.  
Even with IPv4 addresses all used up, you can still only talk to 0.1%  
of the internet over IPv6. With an IPv4 address that is shared through  
NAT you can probably reach 50% of the internet (everyone except others  
behind NAT who don't have any incoming ports mapped). However, the  
first value is only going to go up, while the second is only going to  
go down. So at some point, it starts making sense to do IPv6 or  
IPv6+IPv4NAT.

So it looks like much more NAT is actually a necessary intermediate  
step to get IPv6 deployed. We here at the IETF, the group of self- 
appointed people that should know better, should make sure that we  
don't get unduly stuck in that intermediate phase. That's why I am  
very much interested in bringing back NAT-PT: it gives people IPv6  
with their NAT so the usefulness of IPv6 is enhanced as that of IPv4  
deteriorates so it addresses both the temporary situation and the  
eventual goal of full IPv6 deployment.

> Then take a look at what those companies are doing about it.  
> Polaroid has already gone bankrupt

How is proactively going bankrupt useful?  (-:

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Jan 2008 08:42:16 +1300

> Yes, as you point out the generic answer to the problem is NAT-PT which was recently squashed after a cabal got together.

That's a bizarre statement. Which of the technical arguments
in RFC 4966 are you referring to as being products of a cabal?
Did you raise your objections to those arguments during the
IETF Last Call on draft-ietf-v6ops-natpt-to-historic
(issued 2007-03-08)?

> My point here is that the thinking on the transition in the IETF to date has all been of the form 'well everyone is going to have to become like us, only they can't possibly expect to so its a bit…

Have you been contributing to ngtrans and v6ops over the last
ten years to correct this wrong way of thinking?

> I received a lot of criticism when I first proposed that the IETF embrace NAT as a transition tool rather than deprecate it. The idea that we should actively encourage the NAT-ing of IPv4 was consi…

That comparison is a category mistake. And given that NAT-PT was defined
as a co-existence technique in February 2000 (RFC 2766), I'm not sure
I see your point exactly.

> I don't see much dispute on that point today. Pretty much everyone seems to now accept that we are going to run out of IPv4 addresses before IPv6 deployment is complete and that some form of addres…

Well, the original plan was that IPv6 would deploy before sharing
of IPv4 addresses started. That didn't happen and of course it's
unfortunate. It's true that those of us who were aghast at the
negative consequences of address sharing did nothing to make it work
better, and wrote about the negative consequences. I make no apology
for my part in that.

Given today's reality, some of the aghast are thinking actively about
how to define a method that isn't broken in the ways described by
RFC 4966.

    Brian

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 3 Jan 2008 12:38:06 -0800

Brian,
 
Yes I did object, we had the same argument then.
 
At the time my position was a distinctly minority one. Today I think I have won that argument and I think that people are looking at NAT as an opportunity, not merely an annoyance.
 
NAT is only about 30% of the solution. The other two essential components are an administration model for the transition and a new layering model that properly abstracts and separates the applications layer from the layer we are attempting to change.
 
At this point I am pretty confident that people are going to do the right thing on NAT. Certainly there are people who know a lot more than me at that layer of the stack. I can add most value here by pushing on the other two pieces of the puzzle where I believe change is necessary and where currently my position is still a minority one.

IPv6 transition is not going to happen unless it is 100% transparent to application developers and end users.

From: Brian E Carpenter [mailto:[email-masked]]
Sent: Thu 03/01/2008 2:42 PM
To: Hallam-Baker, Phillip
Cc: Jeroen Massar; [email-masked]; [email-masked]
Subject: Re: Deployment Cases

    Brian

---

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Jan 2008 10:22:48 +0100

> Wouldn't Bittorrent fail congestion considerations review?

Not necessarily. It does use a large number of TCP connections,  
because the goal is to fully saturate a user's up- and downlink. But  
because it uses TCP, it will correctly back off under loss, so  
congestion collapse at least is not an issue. (It obviously does cause  
issues for ISPs that provisioned their networks with certain  
aggregation ratios in mind, which became invalid with the rise of P2P.  
Separate issue though.)

There are still fairness issues with BitTorrent, in that the large  
number of BitTorrent sessions will use a comparatively large fraction  
of a user's access link compared to the typically small number of  
other (and typically bursty) connections that are active. Given that  
users typically run P2P in the background, this decrease in  
performance of the transport sessions that the users were more  
immediately interested in quickly got noticed. Modern BitTorrent  
implementations have pretty clever schemes to free up a larger share  
of the access link capacity when they notice concurrent non-BitTorrent  
sessions sharing the access link. This piece of BitTorrent seems to be  
pretty actively evolving, and I'm not sure how much of it has been  
written down. Basically, BitTorrent has recently been trying  
approximate a scavenger service that tries to restrict its  
transmissions to otherwise idle capacity, using application-level  
mechanisms. (Which is IMO exactly what it should be.)

There has been a bunch of research an even some standardization  
attempts on integrated congestion control, i.e., congestion and rate  
controlling the aggregate traffic that a host is sending at any given  
time, i.e., across all active connections, but deployment never  
happened and interest quickly waned.

Lars

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 8 Jan 2008 05:56:41 -0500

>> Wouldn't Bittorrent fail congestion considerations review?

Since Bittorrent is heavily used now by endusers and is likely to be  
used by commercial enterprises (either as is, or with modifications  
for security, DRM, etc.), if it doesn't provide good congestion  
control it would be better to try and fix it than to simply bemoan it.

Regards
Marshall

> because the goal is to fully saturate a user's up- and downlink.  
> But because it uses TCP, it will correctly back off under loss, so  
> congestion collapse at least is not an issue. (It obviously does  
> cause issues for ISPs that provisioned their networks with certain  
> aggregation ratios in mind, which became invalid with the rise of  
> P2P. Separate issue though.)
>
> number of BitTorrent sessions will use a comparatively large  
> fraction of a user's access link compared to the typically small  
> number of other (and typically bursty) connections that are active.  
> Given that users typically run P2P in the background, this decrease  
> in performance of the transport sessions that the users were more  
> implementations have pretty clever schemes to free up a larger  
> share of the access link capacity when they notice concurrent non- 
> BitTorrent sessions sharing the access link. This piece of  
> BitTorrent seems to be pretty actively evolving, and I'm not sure  
> how much of it has been written down. Basically, BitTorrent has  
> recently been trying approximate a scavenger service that tries to  
> restrict its transmissions to otherwise idle capacity, using  
> application-level mechanisms. (Which is IMO exactly what it should  
> be.)
>
> attempts on integrated congestion control, i.e., congestion and  
> rate controlling the aggregate traffic that a host is sending at  
> any given time, i.e., across all active connections, but deployment  
> never happened and interest quickly waned.
>
> Lars
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 8 Jan 2008 08:05:35 -0800

Building the deployment case for a strictly functional protocol that does not have a competitor is simply a matter of asking 'does anyone actually case about these use cases enough to deploy'. In the case of Bittorrent, the answer is of course yes.
 
Proposing to transition from current bittorrent protocol to an incompativble successor on the other hand requires much more thought. What is the deficiency with the current protocol that is going to be fixed?
 
If the defect is functional in nature one can expect rapid take up. If on the other hand the proposal is to convert XML to ASN.1 or vice versa for the sake of prettification then its not likely to happen.

From: Marshall Eubanks [mailto:[email-masked]]
Sent: Tue 08/01/2008 5:56 AM
To: Lars Eggert
Cc: 'Tony Finch'; Ping Pan; 'IETF discussion list'; [email-masked]
Subject: Re: Deployment Cases

Regards
Marshall