Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/08/volume-hotkeys-thinkpad-t60.html

In keeping with my tendency to write a blog post about any technical issue
I find that takes me more than five minutes to figure out when searching
the Internet, I include below a resolution to a problem that took me,
embarrassingly, nearly two and half hours across two different tries to
figure out.

The problem appeared when I took Debian 7 (wheezy) laptop hard drive out
of an Lenovo Thinkpad T61 that I was using that failed and into Lenovo
Thinkpad T60. (I’ve been trying to switch fully to the T60 for everything
because it is supported by Coreboot.)

When I switched, everything was working fine, except the volume buttons on
the Thinkpad T60 (those three buttons in the top left hand corner of the
keyboard, shown circled in purple in the image on the right) no longer did
what I expected. I expected they would ultimately control PulseAudio volume,
which does the equivalent of pactl set-sink-mute 0 0 and
appropriate pactl set-sink-volume 0 commands for my sound card.
I noticed this because when PulseAudio is running, and you type those
commands on the command line, all functions properly with the
volume, and, when running under X, I see the popup windows coming
from my desktop environment showing the volume changes. So, I knew nothing
was wrong with the sound configuration when I switched the hard drive to a
new machine, since the command line tools worked and did the right things.
Somehow, the buttons weren’t sending the same commands in whatever manner
they were used to.

I assumed at first that the buttons simply generated X events. It turns
out they do, but the story there is a bit more complex. When I
ran xev I saw those buttons did not, in fact, generate any X
events. So, that makes it clear that nothing from X windows
“up” (i.e, to the desktop software) had anything to do with the
situation.

So, I first proceed to research whether these volume keys were supposed to
generate X events. I discovered that there were indeed XF86VolumeUp,
XF86VolumeDown and XF86VolumeMute key events (I’d seen those before, in
fact, doing similar research years ago). However, the advice online was
highly conflicting whether or not the best way to solve this is to have
them generate X events. Most of the discussions I found assumed the keys
were already generating X events and had advice about how to bind those
keys to scripts or to your desktop setup of
choice^0.

I found various old documentation about the thinkpad_acpi
daemon, which I quickly found quickly was out of date since long ago that
had been incorporated into Linux’s ACPI directly and didn’t require
additional daemons. This led me to just begin poking around about how the
ACPI subsystem for ACPI keys worked.

I quickly found the xev equivalent for
acpi: acpi_listen. This was the breakthrough I needed to
solve this problem. I ran acpi_listen and discovered that
while other Thinkpad key sequences, such as Fn-Home (to
increase brightness), generated output like:

        video/brightnessup BRTUP 00000086 00000000 K
        video/brightnessup BRTUP 00000086 00000000
        

but the volume up, down, and mute keys generated no output. Therefore, it’s
pretty clear at this point that the problem is something related to
configuration of ACPI in some way. I had a feeling this would be hard to
find a solution for.

That’s when I started poking around in /proc, and found
that /proc/acpi/ibm/volume was changing each time I
hit a these keys. So, Linux clearly was receiving notice that these keys
were pressed. So, why wasn’t the acpi subsystem notifying anything else,
including whatever interface acpi_listen talks to?

Well, this was a hard one to find an answer to. I have to admit that I
found the answer through pure serendipity. I had already
loaded this
old bug report for an GNU/Linux distribution waning in popularity and
found that someone resolved the ticket with the command:

        cp /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask
        

This command:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        0x00ffffff
        0x008dffff
        

quickly showed that that the masks didn’t match. So I did:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask > /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        

and that single change caused the buttons to work again as expected,
including causing the popup notifications of volume changes and the like.

Additional searching
show this
hotkey issue is documented in Linux, in its Thinkpad ACPI
documentation, which states:

The hot key bit mask allows some control over which hot keys generate events.
If a key is “masked” (bit set to 0 in the mask), the firmware will handle it.
If it is “unmasked”, it signals the firmware that thinkpad-acpi would prefer
to handle it, if the firmware would be so kind to allow it (and it often
doesn’t!).

I note that on my system, running the command the document recommends to
reset to defaults yields me back to the wrong state:

        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x00ffffff
        commands:       enable, disable, reset, <mask>
        # echo reset > /proc/acpi/ibm/hotkey 
        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x008dffff
        commands:       enable, disable, reset, <mask>
        # echo 0xffffffff > /proc/acpi/ibm/hotkey
        

So, I added that last command above to restore it to enabled Linux’s control
of all the ACPI hot keys, which I suspect is what I want. I’ll update the
post if doing that causes other problems that I hadn’t seen before. I’ll
also update the post to note whether this setting is saved over reboots, as
I haven’t rebooted the machine since I did this. 🙂

⁰Interestingly, as has
happened to me often recently, much of the most useful information that I
find about any complex topic regarding how things work in modern GNU/Linux
distributions is found on the Arch or Crunchbang online fora and wikis. It’s
quite interesting to me that these two distributions appear to be the primary
place where the types of information that every distribution once needed to
provide are kept. Their wikis are becoming the canonical references of how a
distribution is constructed, since much of the information found therein
applies to all distributions, but distributions like Fedora and Debian
attempt to make it less complex for the users to change the
configuration.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/08/volume-hotkeys-thinkpad-t60.html

In keeping with my tendency to write a blog post about any technical issue
I find that takes me more than five minutes to figure out when searching
the Internet, I include below a resolution to a problem that took me,
embarrassingly, nearly two and half hours across two different tries to
figure out.

The problem appeared when I took Debian 7 (wheezy) laptop hard drive out
of an Lenovo Thinkpad T61 that I was using that failed and into Lenovo
Thinkpad T60. (I’ve been trying to switch fully to the T60 for everything
because it is supported by Coreboot.)

When I switched, everything was working fine, except the volume buttons on
the Thinkpad T60 (those three buttons in the top left hand corner of the
keyboard, shown circled in purple in the image on the right) no longer did
what I expected. I expected they would ultimately control PulseAudio volume,
which does the equivalent of pactl set-sink-mute 0 0 and
appropriate pactl set-sink-volume 0 commands for my sound card.
I noticed this because when PulseAudio is running, and you type those
commands on the command line, all functions properly with the
volume, and, when running under X, I see the popup windows coming
from my desktop environment showing the volume changes. So, I knew nothing
was wrong with the sound configuration when I switched the hard drive to a
new machine, since the command line tools worked and did the right things.
Somehow, the buttons weren’t sending the same commands in whatever manner
they were used to.

I assumed at first that the buttons simply generated X events. It turns
out they do, but the story there is a bit more complex. When I
ran xev I saw those buttons did not, in fact, generate any X
events. So, that makes it clear that nothing from X windows
“up” (i.e, to the desktop software) had anything to do with the
situation.

So, I first proceed to research whether these volume keys were supposed to
generate X events. I discovered that there were indeed XF86VolumeUp,
XF86VolumeDown and XF86VolumeMute key events (I’d seen those before, in
fact, doing similar research years ago). However, the advice online was
highly conflicting whether or not the best way to solve this is to have
them generate X events. Most of the discussions I found assumed the keys
were already generating X events and had advice about how to bind those
keys to scripts or to your desktop setup of
choice^0.

I found various old documentation about the thinkpad_acpi
daemon, which I quickly found quickly was out of date since long ago that
had been incorporated into Linux’s ACPI directly and didn’t require
additional daemons. This led me to just begin poking around about how the
ACPI subsystem for ACPI keys worked.

I quickly found the xev equivalent for
acpi: acpi_listen. This was the breakthrough I needed to
solve this problem. I ran acpi_listen and discovered that
while other Thinkpad key sequences, such as Fn-Home (to
increase brightness), generated output like:

        video/brightnessup BRTUP 00000086 00000000 K
        video/brightnessup BRTUP 00000086 00000000
        

but the volume up, down, and mute keys generated no output. Therefore, it’s
pretty clear at this point that the problem is something related to
configuration of ACPI in some way. I had a feeling this would be hard to
find a solution for.

That’s when I started poking around in /proc, and found
that /proc/acpi/ibm/volume was changing each time I
hit a these keys. So, Linux clearly was receiving notice that these keys
were pressed. So, why wasn’t the acpi subsystem notifying anything else,
including whatever interface acpi_listen talks to?

Well, this was a hard one to find an answer to. I have to admit that I
found the answer through pure serendipity. I had already
loaded this
old bug report for an GNU/Linux distribution waning in popularity and
found that someone resolved the ticket with the command:

        cp /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask
        

This command:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        0x00ffffff
        0x008dffff
        

quickly showed that that the masks didn’t match. So I did:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask > /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        

and that single change caused the buttons to work again as expected,
including causing the popup notifications of volume changes and the like.

Additional searching
show this
hotkey issue is documented in Linux, in its Thinkpad ACPI
documentation, which states:

The hot key bit mask allows some control over which hot keys generate events.
If a key is “masked” (bit set to 0 in the mask), the firmware will handle it.
If it is “unmasked”, it signals the firmware that thinkpad-acpi would prefer
to handle it, if the firmware would be so kind to allow it (and it often
doesn’t!).

I note that on my system, running the command the document recommends to
reset to defaults yields me back to the wrong state:

        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x00ffffff
        commands:       enable, disable, reset, <mask>
        # echo reset > /proc/acpi/ibm/hotkey 
        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x008dffff
        commands:       enable, disable, reset, <mask>
        # echo 0xffffffff > /proc/acpi/ibm/hotkey
        

So, I added that last command above to restore it to enabled Linux’s control
of all the ACPI hot keys, which I suspect is what I want. I’ll update the
post if doing that causes other problems that I hadn’t seen before. I’ll
also update the post to note whether this setting is saved over reboots, as
I haven’t rebooted the machine since I did this. 🙂

⁰Interestingly, as has
happened to me often recently, much of the most useful information that I
find about any complex topic regarding how things work in modern GNU/Linux
distributions is found on the Arch or Crunchbang online fora and wikis. It’s
quite interesting to me that these two distributions appear to be the primary
place where the types of information that every distribution once needed to
provide are kept. Their wikis are becoming the canonical references of how a
distribution is constructed, since much of the information found therein
applies to all distributions, but distributions like Fedora and Debian
attempt to make it less complex for the users to change the
configuration.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/08/volume-hotkeys-thinkpad-t60.html

In keeping with my tendency to write a blog post about any technical issue
I find that takes me more than five minutes to figure out when searching
the Internet, I include below a resolution to a problem that took me,
embarrassingly, nearly two and half hours across two different tries to
figure out.

The problem appeared when I took Debian 7 (wheezy) laptop hard drive out
of an Lenovo Thinkpad T61 that I was using that failed and into Lenovo
Thinkpad T60. (I’ve been trying to switch fully to the T60 for everything
because it is supported by Coreboot.)

When I switched, everything was working fine, except the volume buttons on
the Thinkpad T60 (those three buttons in the top left hand corner of the
keyboard, shown circled in purple in the image on the right) no longer did
what I expected. I expected they would ultimately control PulseAudio volume,
which does the equivalent of pactl set-sink-mute 0 0 and
appropriate pactl set-sink-volume 0 commands for my sound card.
I noticed this because when PulseAudio is running, and you type those
commands on the command line, all functions properly with the
volume, and, when running under X, I see the popup windows coming
from my desktop environment showing the volume changes. So, I knew nothing
was wrong with the sound configuration when I switched the hard drive to a
new machine, since the command line tools worked and did the right things.
Somehow, the buttons weren’t sending the same commands in whatever manner
they were used to.

I assumed at first that the buttons simply generated X events. It turns
out they do, but the story there is a bit more complex. When I
ran xev I saw those buttons did not, in fact, generate any X
events. So, that makes it clear that nothing from X windows
“up” (i.e, to the desktop software) had anything to do with the
situation.

So, I first proceed to research whether these volume keys were supposed to
generate X events. I discovered that there were indeed XF86VolumeUp,
XF86VolumeDown and XF86VolumeMute key events (I’d seen those before, in
fact, doing similar research years ago). However, the advice online was
highly conflicting whether or not the best way to solve this is to have
them generate X events. Most of the discussions I found assumed the keys
were already generating X events and had advice about how to bind those
keys to scripts or to your desktop setup of
choice^0.

I found various old documentation about the thinkpad_acpi
daemon, which I quickly found quickly was out of date since long ago that
had been incorporated into Linux’s ACPI directly and didn’t require
additional daemons. This led me to just begin poking around about how the
ACPI subsystem for ACPI keys worked.

I quickly found the xev equivalent for
acpi: acpi_listen. This was the breakthrough I needed to
solve this problem. I ran acpi_listen and discovered that
while other Thinkpad key sequences, such as Fn-Home (to
increase brightness), generated output like:

        video/brightnessup BRTUP 00000086 00000000 K
        video/brightnessup BRTUP 00000086 00000000
        

but the volume up, down, and mute keys generated no output. Therefore, it’s
pretty clear at this point that the problem is something related to
configuration of ACPI in some way. I had a feeling this would be hard to
find a solution for.

That’s when I started poking around in /proc, and found
that /proc/acpi/ibm/volume was changing each time I
hit a these keys. So, Linux clearly was receiving notice that these keys
were pressed. So, why wasn’t the acpi subsystem notifying anything else,
including whatever interface acpi_listen talks to?

Well, this was a hard one to find an answer to. I have to admit that I
found the answer through pure serendipity. I had already
loaded this
old bug report for an GNU/Linux distribution waning in popularity and
found that someone resolved the ticket with the command:

        cp /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask
        

This command:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        0x00ffffff
        0x008dffff
        

quickly showed that that the masks didn’t match. So I did:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask > /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        

and that single change caused the buttons to work again as expected,
including causing the popup notifications of volume changes and the like.

Additional searching
show this
hotkey issue is documented in Linux, in its Thinkpad ACPI
documentation, which states:

The hot key bit mask allows some control over which hot keys generate events.
If a key is “masked” (bit set to 0 in the mask), the firmware will handle it.
If it is “unmasked”, it signals the firmware that thinkpad-acpi would prefer
to handle it, if the firmware would be so kind to allow it (and it often
doesn’t!).

I note that on my system, running the command the document recommends to
reset to defaults yields me back to the wrong state:

        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x00ffffff
        commands:       enable, disable, reset, <mask>
        # echo reset > /proc/acpi/ibm/hotkey 
        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x008dffff
        commands:       enable, disable, reset, <mask>
        # echo 0xffffffff > /proc/acpi/ibm/hotkey
        

So, I added that last command above to restore it to enabled Linux’s control
of all the ACPI hot keys, which I suspect is what I want. I’ll update the
post if doing that causes other problems that I hadn’t seen before. I’ll
also update the post to note whether this setting is saved over reboots, as
I haven’t rebooted the machine since I did this. 🙂

⁰Interestingly, as has
happened to me often recently, much of the most useful information that I
find about any complex topic regarding how things work in modern GNU/Linux
distributions is found on the Arch or Crunchbang online fora and wikis. It’s
quite interesting to me that these two distributions appear to be the primary
place where the types of information that every distribution once needed to
provide are kept. Their wikis are becoming the canonical references of how a
distribution is constructed, since much of the information found therein
applies to all distributions, but distributions like Fedora and Debian
attempt to make it less complex for the users to change the
configuration.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/08/volume-hotkeys-thinkpad-t60.html

In keeping with my tendency to write a blog post about any technical issue
I find that takes me more than five minutes to figure out when searching
the Internet, I include below a resolution to a problem that took me,
embarrassingly, nearly two and half hours across two different tries to
figure out.

The problem appeared when I took Debian 7 (wheezy) laptop hard drive out
of an Lenovo Thinkpad T61 that I was using that failed and into Lenovo
Thinkpad T60. (I’ve been trying to switch fully to the T60 for everything
because it is supported by Coreboot.)

When I switched, everything was working fine, except the volume buttons on
the Thinkpad T60 (those three buttons in the top left hand corner of the
keyboard, shown circled in purple in the image on the right) no longer did
what I expected. I expected they would ultimately control PulseAudio volume,
which does the equivalent of pactl set-sink-mute 0 0 and
appropriate pactl set-sink-volume 0 commands for my sound card.
I noticed this because when PulseAudio is running, and you type those
commands on the command line, all functions properly with the
volume, and, when running under X, I see the popup windows coming
from my desktop environment showing the volume changes. So, I knew nothing
was wrong with the sound configuration when I switched the hard drive to a
new machine, since the command line tools worked and did the right things.
Somehow, the buttons weren’t sending the same commands in whatever manner
they were used to.

I assumed at first that the buttons simply generated X events. It turns
out they do, but the story there is a bit more complex. When I
ran xev I saw those buttons did not, in fact, generate any X
events. So, that makes it clear that nothing from X windows
“up” (i.e, to the desktop software) had anything to do with the
situation.

So, I first proceed to research whether these volume keys were supposed to
generate X events. I discovered that there were indeed XF86VolumeUp,
XF86VolumeDown and XF86VolumeMute key events (I’d seen those before, in
fact, doing similar research years ago). However, the advice online was
highly conflicting whether or not the best way to solve this is to have
them generate X events. Most of the discussions I found assumed the keys
were already generating X events and had advice about how to bind those
keys to scripts or to your desktop setup of
choice^0.

I found various old documentation about the thinkpad_acpi
daemon, which I quickly found quickly was out of date since long ago that
had been incorporated into Linux’s ACPI directly and didn’t require
additional daemons. This led me to just begin poking around about how the
ACPI subsystem for ACPI keys worked.

I quickly found the xev equivalent for
acpi: acpi_listen. This was the breakthrough I needed to
solve this problem. I ran acpi_listen and discovered that
while other Thinkpad key sequences, such as Fn-Home (to
increase brightness), generated output like:

        video/brightnessup BRTUP 00000086 00000000 K
        video/brightnessup BRTUP 00000086 00000000
        

but the volume up, down, and mute keys generated no output. Therefore, it’s
pretty clear at this point that the problem is something related to
configuration of ACPI in some way. I had a feeling this would be hard to
find a solution for.

That’s when I started poking around in /proc, and found
that /proc/acpi/ibm/volume was changing each time I
hit a these keys. So, Linux clearly was receiving notice that these keys
were pressed. So, why wasn’t the acpi subsystem notifying anything else,
including whatever interface acpi_listen talks to?

Well, this was a hard one to find an answer to. I have to admit that I
found the answer through pure serendipity. I had already
loaded this
old bug report for an GNU/Linux distribution waning in popularity and
found that someone resolved the ticket with the command:

        cp /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask
        

This command:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        0x00ffffff
        0x008dffff
        

quickly showed that that the masks didn’t match. So I did:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask > /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        

and that single change caused the buttons to work again as expected,
including causing the popup notifications of volume changes and the like.

Additional searching
show this
hotkey issue is documented in Linux, in its Thinkpad ACPI
documentation, which states:

The hot key bit mask allows some control over which hot keys generate events.
If a key is “masked” (bit set to 0 in the mask), the firmware will handle it.
If it is “unmasked”, it signals the firmware that thinkpad-acpi would prefer
to handle it, if the firmware would be so kind to allow it (and it often
doesn’t!).

I note that on my system, running the command the document recommends to
reset to defaults yields me back to the wrong state:

        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x00ffffff
        commands:       enable, disable, reset, <mask>
        # echo reset > /proc/acpi/ibm/hotkey 
        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x008dffff
        commands:       enable, disable, reset, <mask>
        # echo 0xffffffff > /proc/acpi/ibm/hotkey
        

So, I added that last command above to restore it to enabled Linux’s control
of all the ACPI hot keys, which I suspect is what I want. I’ll update the
post if doing that causes other problems that I hadn’t seen before. I’ll
also update the post to note whether this setting is saved over reboots, as
I haven’t rebooted the machine since I did this. 🙂

⁰Interestingly, as has
happened to me often recently, much of the most useful information that I
find about any complex topic regarding how things work in modern GNU/Linux
distributions is found on the Arch or Crunchbang online fora and wikis. It’s
quite interesting to me that these two distributions appear to be the primary
place where the types of information that every distribution once needed to
provide are kept. Their wikis are becoming the canonical references of how a
distribution is constructed, since much of the information found therein
applies to all distributions, but distributions like Fedora and Debian
attempt to make it less complex for the users to change the
configuration.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/08/volume-hotkeys-thinkpad-t60.html

In keeping with my tendency to write a blog post about any technical issue
I find that takes me more than five minutes to figure out when searching
the Internet, I include below a resolution to a problem that took me,
embarrassingly, nearly two and half hours across two different tries to
figure out.

The problem appeared when I took Debian 7 (wheezy) laptop hard drive out
of an Lenovo Thinkpad T61 that I was using that failed and into Lenovo
Thinkpad T60. (I’ve been trying to switch fully to the T60 for everything
because it is supported by Coreboot.)

When I switched, everything was working fine, except the volume buttons on
the Thinkpad T60 (those three buttons in the top left hand corner of the
keyboard, shown circled in purple in the image on the right) no longer did
what I expected. I expected they would ultimately control PulseAudio volume,
which does the equivalent of pactl set-sink-mute 0 0 and
appropriate pactl set-sink-volume 0 commands for my sound card.
I noticed this because when PulseAudio is running, and you type those
commands on the command line, all functions properly with the
volume, and, when running under X, I see the popup windows coming
from my desktop environment showing the volume changes. So, I knew nothing
was wrong with the sound configuration when I switched the hard drive to a
new machine, since the command line tools worked and did the right things.
Somehow, the buttons weren’t sending the same commands in whatever manner
they were used to.

I assumed at first that the buttons simply generated X events. It turns
out they do, but the story there is a bit more complex. When I
ran xev I saw those buttons did not, in fact, generate any X
events. So, that makes it clear that nothing from X windows
“up” (i.e, to the desktop software) had anything to do with the
situation.

So, I first proceed to research whether these volume keys were supposed to
generate X events. I discovered that there were indeed XF86VolumeUp,
XF86VolumeDown and XF86VolumeMute key events (I’d seen those before, in
fact, doing similar research years ago). However, the advice online was
highly conflicting whether or not the best way to solve this is to have
them generate X events. Most of the discussions I found assumed the keys
were already generating X events and had advice about how to bind those
keys to scripts or to your desktop setup of
choice^0.

I found various old documentation about the thinkpad_acpi
daemon, which I quickly found quickly was out of date since long ago that
had been incorporated into Linux’s ACPI directly and didn’t require
additional daemons. This led me to just begin poking around about how the
ACPI subsystem for ACPI keys worked.

I quickly found the xev equivalent for
acpi: acpi_listen. This was the breakthrough I needed to
solve this problem. I ran acpi_listen and discovered that
while other Thinkpad key sequences, such as Fn-Home (to
increase brightness), generated output like:

        video/brightnessup BRTUP 00000086 00000000 K
        video/brightnessup BRTUP 00000086 00000000
        

but the volume up, down, and mute keys generated no output. Therefore, it’s
pretty clear at this point that the problem is something related to
configuration of ACPI in some way. I had a feeling this would be hard to
find a solution for.

That’s when I started poking around in /proc, and found
that /proc/acpi/ibm/volume was changing each time I
hit a these keys. So, Linux clearly was receiving notice that these keys
were pressed. So, why wasn’t the acpi subsystem notifying anything else,
including whatever interface acpi_listen talks to?

Well, this was a hard one to find an answer to. I have to admit that I
found the answer through pure serendipity. I had already
loaded this
old bug report for an GNU/Linux distribution waning in popularity and
found that someone resolved the ticket with the command:

        cp /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask
        

This command:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        0x00ffffff
        0x008dffff
        

quickly showed that that the masks didn’t match. So I did:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask > /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        

and that single change caused the buttons to work again as expected,
including causing the popup notifications of volume changes and the like.

Additional searching
show this
hotkey issue is documented in Linux, in its Thinkpad ACPI
documentation, which states:

The hot key bit mask allows some control over which hot keys generate events.
If a key is “masked” (bit set to 0 in the mask), the firmware will handle it.
If it is “unmasked”, it signals the firmware that thinkpad-acpi would prefer
to handle it, if the firmware would be so kind to allow it (and it often
doesn’t!).

I note that on my system, running the command the document recommends to
reset to defaults yields me back to the wrong state:

        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x00ffffff
        commands:       enable, disable, reset, <mask>
        # echo reset > /proc/acpi/ibm/hotkey 
        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x008dffff
        commands:       enable, disable, reset, <mask>
        # echo 0xffffffff > /proc/acpi/ibm/hotkey
        

So, I added that last command above to restore it to enabled Linux’s control
of all the ACPI hot keys, which I suspect is what I want. I’ll update the
post if doing that causes other problems that I hadn’t seen before. I’ll
also update the post to note whether this setting is saved over reboots, as
I haven’t rebooted the machine since I did this. 🙂

⁰Interestingly, as has
happened to me often recently, much of the most useful information that I
find about any complex topic regarding how things work in modern GNU/Linux
distributions is found on the Arch or Crunchbang online fora and wikis. It’s
quite interesting to me that these two distributions appear to be the primary
place where the types of information that every distribution once needed to
provide are kept. Their wikis are becoming the canonical references of how a
distribution is constructed, since much of the information found therein
applies to all distributions, but distributions like Fedora and Debian
attempt to make it less complex for the users to change the
configuration.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/08/volume-hotkeys-thinkpad-t60.html

In keeping with my tendency to write a blog post about any technical issue
I find that takes me more than five minutes to figure out when searching
the Internet, I include below a resolution to a problem that took me,
embarrassingly, nearly two and half hours across two different tries to
figure out.

The problem appeared when I took Debian 7 (wheezy) laptop hard drive out
of an Lenovo Thinkpad T61 that I was using that failed and into Lenovo
Thinkpad T60. (I’ve been trying to switch fully to the T60 for everything
because it is supported by Coreboot.)

When I switched, everything was working fine, except the volume buttons on
the Thinkpad T60 (those three buttons in the top left hand corner of the
keyboard, shown circled in purple in the image on the right) no longer did
what I expected. I expected they would ultimately control PulseAudio volume,
which does the equivalent of pactl set-sink-mute 0 0 and
appropriate pactl set-sink-volume 0 commands for my sound card.
I noticed this because when PulseAudio is running, and you type those
commands on the command line, all functions properly with the
volume, and, when running under X, I see the popup windows coming
from my desktop environment showing the volume changes. So, I knew nothing
was wrong with the sound configuration when I switched the hard drive to a
new machine, since the command line tools worked and did the right things.
Somehow, the buttons weren’t sending the same commands in whatever manner
they were used to.

I assumed at first that the buttons simply generated X events. It turns
out they do, but the story there is a bit more complex. When I
ran xev I saw those buttons did not, in fact, generate any X
events. So, that makes it clear that nothing from X windows
“up” (i.e, to the desktop software) had anything to do with the
situation.

So, I first proceed to research whether these volume keys were supposed to
generate X events. I discovered that there were indeed XF86VolumeUp,
XF86VolumeDown and XF86VolumeMute key events (I’d seen those before, in
fact, doing similar research years ago). However, the advice online was
highly conflicting whether or not the best way to solve this is to have
them generate X events. Most of the discussions I found assumed the keys
were already generating X events and had advice about how to bind those
keys to scripts or to your desktop setup of
choice^0.

I found various old documentation about the thinkpad_acpi
daemon, which I quickly found quickly was out of date since long ago that
had been incorporated into Linux’s ACPI directly and didn’t require
additional daemons. This led me to just begin poking around about how the
ACPI subsystem for ACPI keys worked.

I quickly found the xev equivalent for
acpi: acpi_listen. This was the breakthrough I needed to
solve this problem. I ran acpi_listen and discovered that
while other Thinkpad key sequences, such as Fn-Home (to
increase brightness), generated output like:

        video/brightnessup BRTUP 00000086 00000000 K
        video/brightnessup BRTUP 00000086 00000000
        

but the volume up, down, and mute keys generated no output. Therefore, it’s
pretty clear at this point that the problem is something related to
configuration of ACPI in some way. I had a feeling this would be hard to
find a solution for.

That’s when I started poking around in /proc, and found
that /proc/acpi/ibm/volume was changing each time I
hit a these keys. So, Linux clearly was receiving notice that these keys
were pressed. So, why wasn’t the acpi subsystem notifying anything else,
including whatever interface acpi_listen talks to?

Well, this was a hard one to find an answer to. I have to admit that I
found the answer through pure serendipity. I had already
loaded this
old bug report for an GNU/Linux distribution waning in popularity and
found that someone resolved the ticket with the command:

        cp /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask
        

This command:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        0x00ffffff
        0x008dffff
        

quickly showed that that the masks didn’t match. So I did:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask > /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        

and that single change caused the buttons to work again as expected,
including causing the popup notifications of volume changes and the like.

Additional searching
show this
hotkey issue is documented in Linux, in its Thinkpad ACPI
documentation, which states:

The hot key bit mask allows some control over which hot keys generate events.
If a key is “masked” (bit set to 0 in the mask), the firmware will handle it.
If it is “unmasked”, it signals the firmware that thinkpad-acpi would prefer
to handle it, if the firmware would be so kind to allow it (and it often
doesn’t!).

I note that on my system, running the command the document recommends to
reset to defaults yields me back to the wrong state:

        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x00ffffff
        commands:       enable, disable, reset, <mask>
        # echo reset > /proc/acpi/ibm/hotkey 
        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x008dffff
        commands:       enable, disable, reset, <mask>
        # echo 0xffffffff > /proc/acpi/ibm/hotkey
        

So, I added that last command above to restore it to enabled Linux’s control
of all the ACPI hot keys, which I suspect is what I want. I’ll update the
post if doing that causes other problems that I hadn’t seen before. I’ll
also update the post to note whether this setting is saved over reboots, as
I haven’t rebooted the machine since I did this. 🙂

⁰Interestingly, as has
happened to me often recently, much of the most useful information that I
find about any complex topic regarding how things work in modern GNU/Linux
distributions is found on the Arch or Crunchbang online fora and wikis. It’s
quite interesting to me that these two distributions appear to be the primary
place where the types of information that every distribution once needed to
provide are kept. Their wikis are becoming the canonical references of how a
distribution is constructed, since much of the information found therein
applies to all distributions, but distributions like Fedora and Debian
attempt to make it less complex for the users to change the
configuration.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/08/volume-hotkeys-thinkpad-t60.html

In keeping with my tendency to write a blog post about any technical issue
I find that takes me more than five minutes to figure out when searching
the Internet, I include below a resolution to a problem that took me,
embarrassingly, nearly two and half hours across two different tries to
figure out.

The problem appeared when I took Debian 7 (wheezy) laptop hard drive out
of an Lenovo Thinkpad T61 that I was using that failed and into Lenovo
Thinkpad T60. (I’ve been trying to switch fully to the T60 for everything
because it is supported by Coreboot.)

When I switched, everything was working fine, except the volume buttons on
the Thinkpad T60 (those three buttons in the top left hand corner of the
keyboard, shown circled in purple in the image on the right) no longer did
what I expected. I expected they would ultimately control PulseAudio volume,
which does the equivalent of pactl set-sink-mute 0 0 and
appropriate pactl set-sink-volume 0 commands for my sound card.
I noticed this because when PulseAudio is running, and you type those
commands on the command line, all functions properly with the
volume, and, when running under X, I see the popup windows coming
from my desktop environment showing the volume changes. So, I knew nothing
was wrong with the sound configuration when I switched the hard drive to a
new machine, since the command line tools worked and did the right things.
Somehow, the buttons weren’t sending the same commands in whatever manner
they were used to.

I assumed at first that the buttons simply generated X events. It turns
out they do, but the story there is a bit more complex. When I
ran xev I saw those buttons did not, in fact, generate any X
events. So, that makes it clear that nothing from X windows
“up” (i.e, to the desktop software) had anything to do with the
situation.

So, I first proceed to research whether these volume keys were supposed to
generate X events. I discovered that there were indeed XF86VolumeUp,
XF86VolumeDown and XF86VolumeMute key events (I’d seen those before, in
fact, doing similar research years ago). However, the advice online was
highly conflicting whether or not the best way to solve this is to have
them generate X events. Most of the discussions I found assumed the keys
were already generating X events and had advice about how to bind those
keys to scripts or to your desktop setup of
choice^0.

I found various old documentation about the thinkpad_acpi
daemon, which I quickly found quickly was out of date since long ago that
had been incorporated into Linux’s ACPI directly and didn’t require
additional daemons. This led me to just begin poking around about how the
ACPI subsystem for ACPI keys worked.

I quickly found the xev equivalent for
acpi: acpi_listen. This was the breakthrough I needed to
solve this problem. I ran acpi_listen and discovered that
while other Thinkpad key sequences, such as Fn-Home (to
increase brightness), generated output like:

        video/brightnessup BRTUP 00000086 00000000 K
        video/brightnessup BRTUP 00000086 00000000
        

but the volume up, down, and mute keys generated no output. Therefore, it’s
pretty clear at this point that the problem is something related to
configuration of ACPI in some way. I had a feeling this would be hard to
find a solution for.

That’s when I started poking around in /proc, and found
that /proc/acpi/ibm/volume was changing each time I
hit a these keys. So, Linux clearly was receiving notice that these keys
were pressed. So, why wasn’t the acpi subsystem notifying anything else,
including whatever interface acpi_listen talks to?

Well, this was a hard one to find an answer to. I have to admit that I
found the answer through pure serendipity. I had already
loaded this
old bug report for an GNU/Linux distribution waning in popularity and
found that someone resolved the ticket with the command:

        cp /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask
        

This command:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        0x00ffffff
        0x008dffff
        

quickly showed that that the masks didn’t match. So I did:

        # cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask > /sys/devices/platform/thinkpad_acpi/hotkey_mask 
        

and that single change caused the buttons to work again as expected,
including causing the popup notifications of volume changes and the like.

Additional searching
show this
hotkey issue is documented in Linux, in its Thinkpad ACPI
documentation, which states:

The hot key bit mask allows some control over which hot keys generate events.
If a key is “masked” (bit set to 0 in the mask), the firmware will handle it.
If it is “unmasked”, it signals the firmware that thinkpad-acpi would prefer
to handle it, if the firmware would be so kind to allow it (and it often
doesn’t!).

I note that on my system, running the command the document recommends to
reset to defaults yields me back to the wrong state:

        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x00ffffff
        commands:       enable, disable, reset, <mask>
        # echo reset > /proc/acpi/ibm/hotkey 
        # cat /proc/acpi/ibm/hotkey 
        status:         enabled
        mask:           0x008dffff
        commands:       enable, disable, reset, <mask>
        # echo 0xffffffff > /proc/acpi/ibm/hotkey
        

So, I added that last command above to restore it to enabled Linux’s control
of all the ACPI hot keys, which I suspect is what I want. I’ll update the
post if doing that causes other problems that I hadn’t seen before. I’ll
also update the post to note whether this setting is saved over reboots, as
I haven’t rebooted the machine since I did this. 🙂

⁰Interestingly, as has
happened to me often recently, much of the most useful information that I
find about any complex topic regarding how things work in modern GNU/Linux
distributions is found on the Arch or Crunchbang online fora and wikis. It’s
quite interesting to me that these two distributions appear to be the primary
place where the types of information that every distribution once needed to
provide are kept. Their wikis are becoming the canonical references of how a
distribution is constructed, since much of the information found therein
applies to all distributions, but distributions like Fedora and Debian
attempt to make it less complex for the users to change the
configuration.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/04/fcc-14-28.html

I remind everyone today, particularly USA Citizens, to be sure to comment
on
the FCC’s
Notice of Proposed Rulemaking (NPRM) 14-28. They even did a sane thing
and provided
an email address you can write to rather than using their poorly designed
web forums,
but PC
Magazine published relatively complete instructions for other ways.
The deadline isn’t for a while yet, but it’s worth getting it done so you
don’t forget. Below is my letter in case anyone is interested.

Dear FCC Commissioners,

I am writing in response to NPRM 14-28 — your request for comments regarding
the “Open Internet”.

I am a trained computer scientist and I work in the technology industry.
(I’m a software developer and software freedom activist.) I have subscribed
to home network services since 1989, starting with the Prodigy service, and
switching to Internet service in 1991. Initially, I used a PSTN single-pair
modem and eventually upgraded to DSL in 1999. I still have a DSL line, but
it’s sadly not much faster than the one I had in 1999, and I explain below
why.

In fact, I’ve watched the situation get progressively worse, not better,
since the Telecommunications Act of 1996. While my download speeds are
little bit faster than they were in the late 1990s, I now pay
substantially more for only small increases of upload speeds, even in a
major urban markets. In short, it’s become increasingly more difficult
to actually purchase true Internet connectivity service anywhere in the
USA. But first, let me explain what I mean by “true Internet
connectivity”.

The Internet was created as a peer-to-peer medium where all nodes were
equal. In the original design of the Internet, every device has its own
IP address and, if the user wanted, that device could be addressed
directly and fully by any other device on the Internet. For its part,
the network in between the two nodes were intended to merely move the
packets between those nodes as quickly as possible — treating all those
packets the same way, and analyzing those packets only with publicly
available algorithms that everyone agreed were correct and fair.

Of course, the companies who typically appeal to (or even fight) the FCC
want the true Internet to simply die. They seek to turn the promise of
a truly peer-to-peer network of equality into a traditional broadcast
medium that they control. They frankly want to manipulate the Internet
into a mere television broadcast system (with the only improvement to
that being “more stations”).

Because of this, the three following features of the Internet —
inherent in its design — that are now extremely difficult for
individual home users to purchase at reasonable cost from so-called
“Internet providers” like Time Warner, Verizon, and Comcast:

• A static IP address, which allows the user to be a true, equal node on
  the Internet. (And, related: IPv6 addresses, which could end the claim
  that static IP addresses are a precious resource.)
• An unfiltered connection, that allows the user to run their own
  webserver, email server and the like. (Most of these companies block TCP
  ports 80 and 25 at the least, and usually many more ports, too).
• Reasonable choices between the upload/download speed tradeoff.

For example, in New York, I currently pay nearly $150/month to an
independent ISP just to have a static, unfiltered IP address with 10
Mbps down and 2 Mbps up. I work from home and the 2 Mbps up is
incredibly slow for modern usage. However, I still live in the Slowness
because upload speeds greater than that are extremely price-restrictive
from any provider.

In other words, these carriers have designed their networks to
prioritize all downloading over all uploading, and to purposely place
the user behind many levels of Network Address Translation and network
filtering. In this environment, many Internet applications simply do
not work (or require complex work-arounds that disable key features).
As an example: true diversity in VoIP accessibility and service has
almost entirely been superseded by proprietary single-company services
(such as Skype) because SIP, designed by the IETF (in part) for VoIP
applications, did not fully anticipate that nearly every user would be
behind NAT and unable to use SIP without complex work-arounds.

I believe this disastrous situation centers around problems with the
Telecommunications Act of 1996. While
the
ILECs
are theoretically required to license network infrastructure fairly at bulk
rates to

CLECs,
I’ve frequently seen — both professional and personally — wars
waged against
CLECs by
ILECs. CLECs
simply can’t offer their own types of services that merely “use”
the ILECs’ connectivity. The technical restrictions placed by ILECs force
CLECs to offer the same style of service the ILEC offers, and at a higher
price (to cover their additional overhead in dealing with the CLECs)! It’s
no wonder there are hardly any CLECs left.

Indeed, in my 25 year career as a technologist, I’ve seen many nasty
tricks by Verizon here in NYC, such as purposeful work-slowdowns in
resolution of outages and Verizon technicians outright lying to me and
to CLEC technicians about the state of their network. For my part, I
stick with one of the last independent ISPs in NYC, but I suspect they
won’t be able to keep their business going for long. Verizon either (a)
buys up any CLEC that looks too powerful, or, (b) if Verizon can’t buy
them, Verizon slowly squeezes them out of business with dirty tricks.

The end result is that we don’t have real options for true Internet
connectivity for home nor on-site business use. I’m already priced
out of getting a 10 Mbps upload with a static IP and all ports usable.
I suspect within 5 years, I’ll be priced out of my current 2 Mbps upload
with a static IP and all ports usable.

I realize the problems that most users are concerned about on this issue
relate to their ability to download bytes from third-party companies
like Netflix. Therefore, it’s all too easy for Verizon to play out this
argument as if it’s big companies vs. big companies.

However, the real fallout from the current system is that the cost for
personal Internet connectivity that allows individuals equal existence
on the network is so high that few bother. The consequence, thus, is
that only those who are heavily involved in the technology industry even
know what types of applications would be available if everyone had a
static IP with all ports usable and equal upload and download speeds
of 10 Mbs or higher.

Yet, that’s the exact promise of network connectivity that I was taught
about as an undergraduate in Computer Science in the early 1990s. What
I see today is the dystopian version of the promise. My generation of
computer scientists have been forced to constrain their designs of
Internet-enabled applications to fit a model that the network carriers
dictate.

I realize you can’t possibly fix all these social ills in the network
connectivity industry with one rule-making, but I hope my comments have
perhaps given a slightly different perspective of what you’ll hear from
most of the other commenters on this issue. I thank you for reading my
comments and would be delighted to talk further with any of your staff
about these issues at your convenience.

Sincerely,

Bradley M. Kuhn,
a citizen of the USA since birth, currently living in New York, NY.