Subject: the iab & net neutrality

From: "Tony Hain" <[email-masked]>
Date: Thu, 23 Mar 2006 20:20:50 -0600

I didn't make it to the mic fast enough at the end, but Brian's comment
about the proposal to outlaw diffserv actually gets to the heart of why the
IAB needs to take specific stands and make public comments. Telling the
telco's they are evil is not the point. General statements of principle or
observations of past behavior like 'walled gardens are not conducive to open
application innovation and frequently result in additional layering
complexity to traverse the walls', or 'allowing people to elect going to the
head of the line is what the QoS toolset is about'. I am not sure what the
right language is but there is probably something the IAB could say about
misusing the tools to effectively set up an extortion/protection racket
being a possible side effect that regulators might want to consider, but
that cutting off the tools outright would actually hamper some potential new
service and application development. 

The point is that if the IAB stands back without making any statement there
will be no guidance about the impacts of various business/deployment models.
Something along the lines of 4084 that takes no particular position of right
or wrong, but identifies the consequences of potential actions might help to
stabilize the public debate. After all even open application development
might be considered wrong by some, but when coupled with the observation
that it happens anyway with more complexity and cost might get all the
fundamental issues on the table. 

Tony

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 Mar 2006 23:24:14 -0500

This directly relates to the Skype discussion during the plenary. Skype 
will, if necessary, tunnel media on port 80 and port 443.

To some extent, the debate also highlights a lack of usable protocol 
tools: One reason, albeit likely not the only one, that there is talk 
about per-source "wholesale" charging for "improved" QoS is that we 
don't currently have a viable inter-provider "retail" mechanism that 
allows individuals and small companies, for example, to request and pay 
for a fixed-bandwidth pipe between random points on the Internet on 
short notice. The inability to offer such services also biases things 
like IPTV towards being provided by those owning the wires and DSLAMs, 
rather than third parties, even without explicit discrimination.

Henning

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Mar 2006 05:00:07 -0500

Tony,

I agree completely and believe the IAB has, of late, been 
altogether too timid in this area.

I think you know all of what I'm about to say, but your note is, 
IMO, easily misread, so an additional observation about 4084 and 
its potential relatives:  In this sphere, a document that says 
"XYZ is evil" is essential worthless.  The companies considering 
XYZ will almost always say "hmm, there is a tradeoff here.  One 
possibility is that I can increase profitability.  The other is 
that I can pay attention to that group of geeks who are living 
in some other reality."  Guess which wins, almost every time?

There are two strategies that make more sense and have more 
chance of success.  One is precisely what 4084 attempted to do: 
lay out categories and boundaries that, if adopted, make better 
information available to potential users/customers and provide a 
foundation for regulation about what must be accurately 
disclosed (as compared to what is required).    That said, I've 
been quite disappointed with the results of 4084: from the 
comments and input I got  before we did the work, I was 
optimistic that we would see at least some ISPs, and maybe even 
some regulators, pick the concepts and terminology up.  To put 
it mildly, it hasn't happened.

The other approach, with thanks to Dave Clark for pointing it 
out to me a few years ago, is to carefully write a neutral and 
balanced document whose theme is "of course the Internet 
architecture permits you do this, but, if you do, it will have 
the following good and bad consequences which you should 
understand in making your decisions".

Either approach requires serious work and people on the IAB who 
are interested, willing, and have the skills to do it.  I can't 
speak for the current IAB at all but, if the sort of output Tony 
and I are talking about is wanted, then people need to tell the 
Nomcom(s) that the ability and willingness to generate it should 
be an important candidate selection criterion.

      john

--On Thursday, March 23, 2006 20:20 -0600 Tony Hain 
<[email-masked]> wrote:

> I didn't make it to the mic fast enough at the end, but
> Brian's comment about the proposal to outlaw diffserv actually
> gets to the heart of why the IAB needs to take specific stands
> and make public comments. Telling the telco's they are evil is
> not the point. General statements of principle or observations
> of past behavior like 'walled gardens are not conducive to open
> application innovation and frequently result in additional
> layering complexity to traverse the walls', or 'allowing
> people to elect going to the head of the line is what the QoS
> toolset is about'. I am not sure what the right language is
> but there is probably something the IAB could say about
> misusing the tools to effectively set up an
> extortion/protection racket being a possible side effect that
> regulators might want to consider, but that cutting off the
> tools outright would actually hamper some potential new
> The point is that if the IAB stands back without making any
> statement there will be no guidance about the impacts of
> various business/deployment models. Something along the lines
> of 4084 that takes no particular position of right or wrong,
> but identifies the consequences of potential actions might
> help to stabilize the public debate. After all even open
> application development might be considered wrong by some, but
> when coupled with the observation that it happens anyway with
> more complexity and cost might get all the fundamental issues
> on the table.
>
> Tony
>
>
>

---

From: Scott W Brim <[email-masked]>
Date: Fri, 24 Mar 2006 16:28:51 -0600

> be an important candidate selection criterion.

These are great, John, but as you say, both approaches require serious
work -- both before and after publication.  In fact spreading an idea
can take much more work, over a longer time, than agreeing on it,
writing it up, and implementing it in the first place.

A healthy Internet requires effort on three fronts: innovation to
start with, deployment (not just of new ideas, but of what we have
already to lesser developed areas), and finally trying to get our
principles, conceptual framework, and attitudes accepted elsewhere.
The first is the usual focus of IETF WGs.  These days the third is
increasingly important.  In all cases it's not enough to launch
something -- it needs to be nursed and championed for a long time
after its birth.

The IAB's primary orientation should be toward breadth, not depth.
Individual members can focus in particular areas but the IAB as a
whole needs to cover a great deal of material on all three of these
fronts.  Doing a good job on all three "legs of the stool" takes
hundreds of people.  We non-IABers can generate the sort of thing
you're talking about as well as the IAB, and we should.  We should use
the IAB as a focal point, lookouts, facilitators, instigators,
conveners, as well as as individuals for their expertise and
dedication.  I think these capabilities are at least as important as
being able to write up results of deliberation.  We should take as
least as much responsibility for doing the grunt work, including
coming up with innovative ideas, writing documents like those you
describe, and making sure results happen in the real world, as we
expect IAB members to.

See you in Montreal.

swb

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Mar 2006 12:30:30 -0500

--On Friday, 24 March, 2006 16:28 -0600 Scott W Brim
<[email-masked]> wrote:

>> chance of success.  One is precisely what 4084 attempted to
>> do:  lay out categories and boundaries that, if adopted, make
>>...
>> Either approach requires serious work and people on the IAB
>> who  are interested, willing, and have the skills to do it.
>> I can't  speak for the current IAB at all but, if the sort of
>> output Tony  and I are talking about is wanted, then people
>> need to tell the  Nomcom(s) that the ability and willingness
>> to generate it should  be an important candidate selection
>> criterion.
 
> These are great, John, but as you say, both approaches require
> serious work -- both before and after publication.  In fact
> spreading an idea can take much more work, over a longer time,
> than agreeing on it, writing it up, and implementing it in the
> first place.

Of course.  The 4084 effort was just a first step.  As has
recently been pointed out to me, it may have been a first step
that lost focus by digging down into the interests and issues of
some Internet-consumer communities more than others, thereby
neither maintaining a consistent high-level view nor clearly
focusing in on an area or two.  That said, if I had understood
that focus problem at the time (and I understood it enough to be
nervous, but not enough to get articulate about it), I would not
have done anything differently because it seemed clear that
there wasn't sufficient community interest to cope with a
half-dozen documents, rather than one.  

But it, or even producing a revision or a few updates that focus
better on specific communities and clusters of needs, are fairly
easy: just as with 4084, someone can sit down and write, round
up a handful of people to comment, and then write some more.
The harder part requires people to stand up and call attention
to the statements.  That is where the analogy to RFC 1984
applies -- IAB and IESG statements carry far more weight than a
random BCP and can be an important tool in focusing interest on
a subject where policy or commercial interests become
problematic for the Internet.

> A healthy Internet requires effort on three fronts: innovation
> to start with, deployment (not just of new ideas, but of what
> we have already to lesser developed areas), and finally trying
> to get our principles, conceptual framework, and attitudes
> accepted elsewhere. The first is the usual focus of IETF WGs.
> These days the third is increasingly important.  In all cases
> it's not enough to launch something -- it needs to be nursed
> and championed for a long time after its birth.

As Scott correctly points out, documents such as 4084, or even
1948, isn't all there is to do either.  But, if the decision of
the IETF community is that it is more important to spend energy
exclusively on low-level technical issues or on administrative
and procedural navel-gazing, then we should keep our
expectations about leverage on this type of issues very low.

> The IAB's primary orientation should be toward breadth, not
> depth. Individual members can focus in particular areas but
> the IAB as a whole needs to cover a great deal of material on
> all three of these fronts.  Doing a good job on all three
> "legs of the stool" takes hundreds of people.  We non-IABers
> can generate the sort of thing you're talking about as well as
> the IAB, and we should.  We should use the IAB as a focal
> point, lookouts, facilitators, instigators, conveners, as well
> as as individuals for their expertise and dedication.  I think
> these capabilities are at least as important as being able to
> write up results of deliberation.  We should take as least as
> much responsibility for doing the grunt work, including coming
> up with innovative ideas, writing documents like those you
> describe, and making sure results happen in the real world, as
> we expect IAB members to.

I think we agree.   I drew the effort that produced 4084
together after hearing that it was needed from too many people
who wouldn't (or didn't feel that they could) do so themselves.
So, turning Scott's discussion above around -- what are the rest
of you doing? 

> See you in Montreal.

I hope to see enough action on this, including some drafts and
some expression of interest from our "leadership", long enough
before Montreal that focused discussion and some conclusions
there become possible.  Perhaps that is a silly hope but if not
now, when?

    john

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 25 Mar 2006 18:47:00 -0600

I don't mean to hijack this conversation, only add a data point...

I have a great deal of respect for the people who have done the heavy 
lifting in BEHAVE, but it seems like every time we meet, someone discovers a 
new and previously un-observed NAT behavior that Is Not Helpful. This week 
was the best yet...

In a recent posting 
(http://list.sipfoundry.org/archive/ietf-behave/msg01189.html), Dan Wing 
said:

> That isn't quite the scenario.  The scenario where the UDP/TCP
> interworking is useful is this:
>
>  Alice---[NAT/firewall]---[TURN]------------[NAT]---Bob
>  <-------TCP---------------->|<-----------UDP-------->
>
> Where Alice's NAT/firewall device blocks UDP.  Many company
> firewalls have that behavior, which cause applications such as
> Skype and Yahoo Voice to send their traffic over TCP.
>
> Bob, on the other hand, has a 'normal' NAT, however Bob's
> endpoint has no support for framing RTP over TCP.  This is
> pretty common -- many endpoints have no ability to send their
> RTP traffic over TCP.
>
> So, this functionality provides a way for Alice and Bob to
> communicate where they couldn't communicate if they were both
> forced to use UDP (because Alice's firewall blocks UDP).
>
>> OTOH we definetly need to nail down framing in the TCP->TURN->UDP
>> scenario.  I think we can use the TCP framing mechanism that Jonthan
>> proposed at the behave meeting; the server would emit every
>> TCP 'chunk' as a UDP packet.

I'm still thinking about the "telling our children about the ancient past 
when it was possible/legal for an ordinary person to put a server on the 
Internet" remark from Thursday's plenary. Dan's note, quoted above, is an 
excellent summary of where we are now, and it is not too much of a leap to 
JohnK's favorite rhetorical question, "where are we going, and how did we 
get in this handbasket?"

So my point was, I'd really like to take a chance on some IAB statements 
about things that need to be stated about our architecture. They might be 
ignored. Would the result be any worse?

Thanks,

Spence

P.s. And how many working group meetings did YOU sit in this past week, 
where firewall and NAT traversal were affecting our protocol designs? I 
think I counted six different working groups (including BEHAVE). Dan Wing 
could be thinking about USEFUL problems, if we weren't distracting him with 
stuff like this. Ditto the rest of the ICE/TURN/STUN crew.

---

From: Melinda Shore <[email-masked]>
Date: Sun, 26 Mar 2006 17:56:43 -0500

> ignored. Would the result be any worse?

This is a somewhat bothersome case, because the IAB *did* issue
an RFC explaining what many of the problems were with "Unilateral
Network Self-Address Fixing" (i.e. STUN).  They included a list
of conditions they felt that an UNSAF protocol had to meet in order to
be published, including a description of a transition mechanism away
from itself and towards something more robust.  I don't know what
more the IAB could have done in order to kill what I think is
a clearly pathological approach to NAT traversal (and I chaired the
working group that standardized it, so I accept a great deal of
responsibility for this mess), but if putting out a document that
says "These are the reasons that this isn't a good protocol" isn't
enough, well, I'm not sure.  But it seems to me that trying to
fix it this late in the process (my other .sig is "software longa,
hardware brevis") has less to do with architecture and more to do
with oncology.  

At any rate, I do think that in this case the IAB did do their job
and it was the rest of us louts who messed up.  And I'll tell you
where I think it happened: when we accepted the idea that something
might be transitional and would eventually go away.

Melinda

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 27 Mar 2006 05:45:33 -0600

Dear All,

My apologies for not being clearer - my intention was not to criticize WG or 
IAB actions in the past, but to point out that we are now in an escalating 
game of whack-a-mole with our applications as the moles that NATs and FWs 
are finding new ways to frustrate.

The security guys have taught us that holding the mallet and waiting for the 
next mole to pop up is not fun; I think the NAT/FW guys are teaching us that 
being the mole is just as bad ("gee, this used to work, until someone 
decided that yet another normal operation was a security threat and 
configured their FW to block it, or someone just installed a NAT that is 
broken in some new and exciting way").

Thanks,

Spencer

p.s. I apologize for the use of culture-specific analogies. For an 
explanation of "Whack-a-mole", see http://en.wikipedia.org/wiki/Whack_a_mole 
or http://whacamole.com/ ("the official website" - now, that's scary).

>From Wikipedia:

"Colloquial usage: The term Whac-a-Mole, or Whack-a-mole, has been used in 
the computer and networking industry to describe the phenomenon of fending 
off recurring spammers, vandals or miscreants. The connotation is that of a 
repetitious and futile task: each time the attacker is "whacked" or kicked 
off of a service, he only pops up again from another direction. Also used in 
the military to refer to opposing troops who keep re-appearing: Whack the 
mole here and it dies, but another pops up in a different spot."

From: "Melinda Shore" <[email-masked]>

---

From: Melinda Shore <[email-masked]>
Date: Mon, 27 Mar 2006 07:10:21 -0500

> are finding new ways to frustrate.

I think we're actually making similar points - if you find yourself
playing whack-a-mole (and we are) there's a good chance that you're
taking the wrong approach.  In this particular case there's a reliance
on using side-effects for NAT traversal, which suggests that we need
sufficiently similar side-effects from all NATs for the approach to
work predictably.  Rather than concluding that maybe betting on
uniformity in side-effects inside closed boxes isn't a great design
decision there's been a tendency to respond to all these problems
that have cropped up as if applying heaps of baling wire and duct
tape will eventually get everything working properly.

Melinda

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Mar 2006 10:43:57 -0500

Traditionally, it was sufficient for the IETF to publish an RFC 
specifying requirements or behavior; the purchasing process, through 
RFIs and RFPs, then cited the long list of RFCs, essentially creating 
the protocol police force that the IETF doesn't have.

That list-of-RFC-numbers approach is clearly not workable for consumer 
gear. The consumer wireless providers recognized that a while ago. Thus, 
802.11b became "WiFi" and an easily recognizable logo, with 
interoperability testing. Same for BlueTooth.

Trying to devise ever more elaborate NAT traversal mechanisms that 
include sending keep-alives every few seconds and various "let's try 
this and then that" algorithms clearly don't scale if we want to get to 
consumer-grade reliability, not just interesting toys that try to stay 
one step ahead of the next stupid NAT trick.

Thus, I think we need a separate organization (or work with a separate 
organization) that does branding and certification. It's hard to buy a 
non-WiFi device in stores today; the equivalent consumer assurance needs 
to be true for core consumer and small-business network devices, and 
possibly services.

Henning

Spencer Dawkins wrote:
> Dear All,
> 
> My apologies for not being clearer - my intention was not to criticize 
> WG or IAB actions in the past, but to point out that we are now in an 
> escalating game of whack-a-mole with our applications as the moles that 
> NATs and FWs are finding new ways to frustrate.
> 
> The security guys have taught us that holding the mallet and waiting for 
> the next mole to pop up is not fun; I think the NAT/FW guys are teaching 
> us that being the mole is just as bad ("gee, this used to work, until 
> someone decided that yet another normal operation was a security threat 
> and configured their FW to block it, or someone just installed a NAT 
> that is broken in some new and exciting way").
> 
> Thanks,
> 
> Spencer
> 
> explanation of "Whack-a-mole", see 
> http://en.wikipedia.org/wiki/Whack_a_mole or http://whacamole.com/ ("the 
> official website" - now, that's scary).
> 
>> From Wikipedia:
> 
> "Colloquial usage: The term Whac-a-Mole, or Whack-a-mole, has been used 
> in the computer and networking industry to describe the phenomenon of 
> fending off recurring spammers, vandals or miscreants. The connotation 
> is that of a repetitious and futile task: each time the attacker is 
> "whacked" or kicked off of a service, he only pops up again from another 
> direction. Also used in the military to refer to opposing troops who 
> keep re-appearing: Whack the mole here and it dies, but another pops up 
> in a different spot."
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 27 Mar 2006 10:31:09 -0600

I think Henning and I are saying the same thing (he's just saying it 
better).

From: "Henning Schulzrinne" <[email-masked]>

> Trying to devise ever more elaborate NAT traversal mechanisms that include 
> sending keep-alives every few seconds and various "let's try this and then 
> that" algorithms clearly don't scale if we want to get to consumer-grade 
> reliability, not just interesting toys that try to stay one step ahead of 
> the next stupid NAT trick.

I know that I agree with this.

> to be true for core consumer and small-business network devices, and 

I don't know how this would work, but if it could be made to work, that 
might be very helpful.

Thanks,

Spencer

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 27 Mar 2006 22:23:46 -0500

John, everyone,

I think it's fair to say that the IAB has "heard the concern"
at this point -- about the net neutrality issue, and the desire
to see some concrete IAB action.

I've also seen a fair bit of discussion about what an appropriate
stance *is*, and whether or how to express it as a useful and
usable (IAB) action.  I'm not sure that "timid" is the right
word -- in at least some instances, "considered" would be better.
Which means there could (should?) be some time delay between
"heard the concern" and that "concrete IAB action".

Leslie.

John C Klensin wrote:
> Tony,
> 
> I agree completely and believe the IAB has, of late, been altogether too 
> timid in this area.
> 
> I think you know all of what I'm about to say, but your note is, IMO, 
> easily misread, so an additional observation about 4084 and its 
> potential relatives:  In this sphere, a document that says "XYZ is evil" 
> is essential worthless.  The companies considering XYZ will almost 
> always say "hmm, there is a tradeoff here.  One possibility is that I 
> can increase profitability.  The other is that I can pay attention to 
> that group of geeks who are living in some other reality."  Guess which 
> wins, almost every time?
> 
> There are two strategies that make more sense and have more chance of 
> success.  One is precisely what 4084 attempted to do: lay out categories 
> and boundaries that, if adopted, make better information available to 
> potential users/customers and provide a foundation for regulation about 
> what must be accurately disclosed (as compared to what is required).    
> That said, I've been quite disappointed with the results of 4084: from 
> the comments and input I got  before we did the work, I was optimistic 
> that we would see at least some ISPs, and maybe even some regulators, 
> pick the concepts and terminology up.  To put it mildly, it hasn't 
> happened.
> 
> The other approach, with thanks to Dave Clark for pointing it out to me 
> a few years ago, is to carefully write a neutral and balanced document 
> whose theme is "of course the Internet architecture permits you do this, 
> but, if you do, it will have the following good and bad consequences 
> which you should understand in making your decisions".
> 
> Either approach requires serious work and people on the IAB who are 
> interested, willing, and have the skills to do it.  I can't speak for 
> the current IAB at all but, if the sort of output Tony and I are talking 
> about is wanted, then people need to tell the Nomcom(s) that the ability 
> and willingness to generate it should be an important candidate 
> selection criterion.
> 
>      john
> 
> 
> --On Thursday, March 23, 2006 20:20 -0600 Tony Hain <[email-masked]> 
> wrote:
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Mar 2006 10:56:41 -0500

We could ask the IEEE, since the relationship between the WiFi folks and 
IEEE 802.11 seems to be somewhat similar.

One of the problems I see is that many of the industry associations (SIP 
Forum, IPv6 forum, to name two I'm somewhat familiar with) tend to focus 
on service providers, not consumers. But an organization such as the SIP 
Forum could provide a "VoIP-optimized" label for NAT boxes and maybe 
even ISPs.

>> non-WiFi device in stores today; the equivalent consumer assurance 
>> needs to be true for core consumer and small-business network devices, 
>> and possibly services.
>