RE: U.S. officials deny technical takedown of WikiLeaks

2010-12-05 Thread Michael Sokolov
Nathan Eisenberg nat...@atlasnetworks.us wrote:

 As someone who was personally connected to this (http://www.komonews.com/ne=
 ws/local/78088192.html), and this, http://www.komonews.com/news/local/68320=
 537.html I feel pretty justified in telling you to keep this 'shoot a pig' =
 crap off the list.

To all uniformed dudes reading this: if you don't want the people you
serve to feel like shooting you, perhaps you should consider going on
strike, immediately stopping enforcing any and all man-made laws that go
against the natural law of Universe, against common sense and against
basic humanity; immediately stopping following any and all orders
telling you to do things that are morally wrong, and finally, switching
over to our side, helping defend America and the American People against
USA.

In the timeless words of The Internationale:

No more deluded by reaction,
On tyrants only we'll make war;
The soldiers too will take strike action,
They'll break ranks and fight no more!
And if those cannibals keep trying
To sacrifice us to their pride,
They soon will hear the bullets flying:
We'll shoot the generals on our own side!

MS

Hold the Heathen Hammer High!
With a battle cry!
For the pagan past I live
and one day will die.



Re: U.S. officials deny technical takedown of WikiLeaks

2010-12-04 Thread Michael Sokolov
Jorge Amodio jmamo...@gmail.com wrote:

 If you get a court order I guess you have two choices, one is to
 comply with it and the other get used to wear a nice pair of matching
 bracelets until your attorney shows up.

Option 3: unleash your full firepower against the miscreants who have
dared to invade your soil despite the sign at the gate which reads in
plain English:

THIS FACILITY IS EXTRATERRITORIAL AND IS NOT PART OF ANY COUNTRY
NO MAKERS OR ENFORCERS OF ANY FORM OF MAN-MADE LAW ARE ALLOWED
ON THE PREMISES

DEADLY FORCE WILL BE USED AGAINST ANY NATIONAL
AUTHORITIES TRESPASSING PAST THIS BOUNDARY!

Factoid: we outnumber the pigs by 1000 to 1.  Even if only 1% of us were
to go out and shoot a pig, we would still outnumber them 10 to 1!  We
*CAN* win -- wake up, people!

American People vs. USA -- let's see who is stronger.

MS

Hold the Heathen Hammer High!
With a battle cry!
For the pagan past I live
and one day will die.

http://www.youtube.com/watch?v=fu2bgwcv43o



Re: Token ring? topic hijack: was Re: Mystery open source switching

2010-11-03 Thread Michael Sokolov
Jacob Broussard shadowedstran...@gmail.com wrote:

 Wow... Reading this thread I feel like some sort of time traveler, what with
 my cable internet, multicore processor, and smartphone.

Just in case it isn't clear, I use all of my ancient computing and
network technology by a *very* deliberate choice.  Just take the case of
the hardware gadget I've designed and built myself that goes from
SDSL/ATM to V.35-nee-EIA-530: I've only built and deployed it in the
summer of this year, although I had wanted one since late 2004 and had
been developing it as a hobby open source hardware project since 2006.

MS



Re: Token ring? topic hijack: was Re: Mystery open source switching

2010-11-03 Thread Michael Sokolov
Gary Baribault g...@baribault.net wrote:

 And you live in a cabin in the woods, pedal a generator to get the
 router up and the router is connected to a 56K Dial-up morem?

I have never used those 56K dial-up modems because they are asymmetric:
it's only 56K in the downstream direction, and I oppose that on
principle.  Prior to switching to my current 384 kbps SDSL (served by a
V.35 CPE device of my own design and make, see earlier messages in this
thread), I was using an always-on (immediate redial on disconnect) analog
modem connection at 31200 bps.  One of the 4.3BSD-Quasijarus MicroVAXen
acted as the router, and the PPP implementation in the kernel was written
by me from scratch: the original non-Quasijarus 4.3BSD only had SLIP.

MS



Re: Token ring? topic hijack: was Re: Mystery open source switching

2010-11-02 Thread Michael Sokolov
Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote:

 Not only token ring. I know of some coaxial ethernets that were running as
 late as 2007.

The network I am using to compose and post this message right now is a
coaxial Ethernet.

MS



Re: Token ring? topic hijack: was Re: Mystery open source switching

2010-11-02 Thread Michael Sokolov
Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote:

 Hats off!! You should post some pictures!

As in ASCII art pictures?  Because my life revolves around ASCII text
and I abhor anything that isn't ASCII text, I do not own a camera of any
kind, never have and likely never will.

MS



Re: Token ring? topic hijack: was Re: Mystery open source switching

2010-11-02 Thread Michael Sokolov
Michael Painter tvhaw...@shaka.com wrote:

 Thick or Thin?

Thin.  I *so* wish I had thick coaxial Ethernet, but alas, my present
physical facility is just too small for that: my present coax Ethernet
network is contained within a single machine room which is a converted
bedroom.

MS



Re: Token ring? topic hijack: was Re: Mystery open source switching

2010-11-02 Thread Michael Sokolov
I wrote:

: Thin.  I *so* wish I had thick coaxial Ethernet, but alas, my present
: physical facility is just too small for that: my present coax Ethernet
: network is contained within a single machine room which is a converted
: bedroom.

Forgot to add: this thin coax Ethernet interconnects several MicroVAXen
(including ivan.Harhan.ORG, the machine on which my mail lives and from
which I am sending this post) running 4.3BSD-Quasijarus, and a Cisco
2500 router which connects my retrocomputing centre to
ARPANET^H^H^H^H^H^H^HSDSL.  The SDSL connection is made via a device of
my very own design and make that connects to the copper pair, handles
the physics of 2-wire full-duplex transmission, and converts SDSL/ATM to
V.35, or more precisely EIA-530, which then goes to the Cisco 2500.

MS



Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?

2010-09-17 Thread Michael Sokolov
Leo Bicknell bickn...@ufp.org wrote:

 There really isn't a lot of choice, 2 providers, and some minor choice
 in how much speed you want to pay for with each one.

Does that mean no CLECs like Covad or DSL.net who colocate in the ATT
CO, rent unbundled dry copper pairs and take it up from there themselves?

Does that mean no ISPs who buy/rent last+middle mile transport from ATT
ADSL network at Layer 2 (ATM) and provide their own IP layer?

MS



Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?

2010-09-17 Thread Michael Sokolov
Leo Bicknell bickn...@ufp.org wrote:

 Part of the reason for this is U-Verse is FTTN, Fiber to the Node.
 ATT has run fiber to my neighborhood, I believe the node in my
 case is about 1000 feet away (I drive past it on the way out).  The
 electronics sit there, so the old model of colocating in the CO and
 getting the dry pair is no longer possible, the copper stops at the
 node and it's a largeish (6' wide, 3' deep, 5' tall) cabinet, so
 there's no colo.

We have that exact same stuff in my area too: I've actually talked to
the ATT tech who was setting that cabinet up on one of our streets.

The explanation he gave me was that even though they want everyone to go
to this new-fangled fiber thing, they still have to maintain a small
number of copper pairs running all the way to the real CO like it used
to be.  The reason is that if some kooky customer like me wants a
service like ISDN that's only available from the real Class 5 switch and
not from the U-Verse remote terminal, they are still required to
provide that as a regulated telco.

Ditto with CLECs like Covad-now-MegaPath: even though they don't get
access to the FTTN infrastructure, no telco is evicting their legacy CO
presence.  Therefore, if a kooky customer like me wishes to forego fiber
speeds and prefers the slower all-copper solution, I can still get SDSL
from the CLEC, and the ILEC (ATT) will be required to provide a direct
copper pair from that CLEC's cage inside the CO to the customer premise,
no matter how much they wish for these copper pairs to die.

Long live copper!

MS



Re: Mikrotik OC-3 Connection

2010-07-04 Thread Michael Sokolov
OK, I'll bite and add my 2 Russian kopecks to the Cisco vs. Linux router
thread.

To make it clear where I'm coming from, I see the networking world from
the viewpoint of non-Ethernet WAN interfaces.  A world consisting of
nothing but Ethernet is too bland and boring for me to live in, and I
choose not to live in such an Ethernet-only world.

I do indeed like the good old ifconfig  route better than Cisco IOS
stuff: it's simpler, makes more sense to me, and fits my simple needs.
However, this model works well for Ethernet because it's very simple:
with Ethernet one generally has a 1:1 correspondence between the
physical hardware unit and the logical network interface unit visible
to ifconfig and the rest of the BSD/Linux network stack.  But that is
most definitely not the case for non-Ethernet WAN interfaces, and that
is where I see a big shortcoming in what's currently available in the
Linux router world.

With non-Ethernet WAN interfaces one really needs an extra layer of
highly configurable software functionality sandwiched in between the
hardware interface unit and the ifconfig layer.  The physical hardware
interface is a synchronous serial bit stream processor that sends and
receives either HDLC frames or ATM cells, and that is where the
hardware-dictated part ends.  Let's take the case of HDLC as it's more
pleasant than ATM: in the case of HDLC the software layer between the
HDLC controller and the ifconfig layer needs to do the following:

* Let the user choose the encapsulation, and there are many choices:
  Cisco HDLC, straight PPP (RFC 1662), Frame Relay, PPP over FR
  (RFC 1973), ATM FUNI, etc.

* If it's a Frame Relay encapsulation, let the user configure DLCIs.
  Oh, and there can be more than one, hence there may be multiple
  ifconfig-able entities on the same FR interface.

* RFC 1490 (FR) and RFC 1483 (ATM) both allow bridged/MAC-encapsulated
  and true routed circuits; our software layer should support both, as
  as well as the possibility of mixing the two on different FR interfaces
  or different DLCIs on the same interface.  These two modes need to
  look different to the ifconfig layer: if it's a bridged encapsulation,
  ifconfig needs to see a virtual Ethernet interface (virteth0 or
  macwan0); if it's a true routed encapsulation, ifconfig needs to see
  a MAC-less and ARP-less point-to-point interface like ipwan0.

* Now let's support both HDLC and serial ATM (bit-by-bit cell delineation)
  if the underlying hardware is capable of both (like Freescale MPC862
  and MPC866).  Let's provide a user to switch between the two with a
  simple software command, and let's provide as much commonality as
  possible between the two configurations: let's support all RFC 1483
  encapsulations on HDLC via FUNI, but make the configuration commands
  look just like ATM.  Let's also support FRF.5 by allowing one to take
  an ATM PVC and treat its payload as a virtual HDLC interface, with
  possibly many FR DLCIs inside.

I would love to be corrected on this, but I am not aware of anyone having
implemented all of the above for Linux (or for any BSD variant) in a
clean and generalized manner.  Instead what we see is that each vendor
of a PCI card for some non-Ethernet WAN interface has their own ad hoc
solution which typically comes nowhere close to what I've outlined above
in terms of generality and flexibility.

Now here is something I'd like to build which will attempt to solve this
mess.  I'd like to build a modular WAN router based on the MPC866 chip
from Freescale, former Motorola.  MPC866 is a PowerPC with one very neat
twist: it has 4 serial communication controller (SCC) cores on chip.
Each SCC has a traditional 7-wire serial interface coming out of it (Rx
data, Rx clock, Tx data, Tx clock, RTS, CTS and CD) and supports both
HDLC and serial ATM.  (The serial ATM mode supports both bit-by-bit cell
delineation for a raw bit stream and octet-by-octet cell delineation for
use with a framer that provides octet boundaries.)

My modular router would be rather unique in that the interface to the
pluggable WAN modules would not be PCI or anything of that sort, instead
it would be the 7-wire serial interface coming from an MPC866 SCC, and
there would be 4 possible daughtercard slots corresponding to the 4 SCCs.

When the interface for pluggable WAN modules is something like PCI, the
HDLC or ATM (including SAR) core has to be reimplemented anew by everyone
who wants to build a new WAN module for a different flavor of Layer 1
physical interface, and I find it wasteful.  The proliferation of such
reinvented-wheel HDLC/ATM reimplementations is precisely the reason why
there is no universally-accepted standardized framework for non-Ethernet
WAN interfaces in Linux or *BSD.

But if the cores implementing HDLC and ATM SAR reside inside the CPU
chip like they do with MPC86x processors, we can have ONE well-written
generic driver for these cores, and it will work exactly the same way
and provide exactly the 

Re: Mikrotik OC-3 Connection

2010-07-04 Thread Michael Sokolov
Adrian Chadd adr...@creative.net.au wrote:

 FreeBSD netgraph. It's clean, it's generalised, it's just not very well
 documented.
 [...]
 Have a chat to the FreeBSD community. There's a powerpc port. Shoehorn
 FreeBSD into it somehow, help tidy up the code to do whateveer you need
 and start leveraging the very powerful network stack FreeBSD has.

Thanks for the tip - that sounds very nice indeed, very much like what I
had in mind.  It's nice to know that *someone* in the generic free OS
world has had the foresight to design this thing right.  (Just to be
clear, I have no political preferences between Linux and FreeBSD; to me
it's all a matter of what works and what I'm familiar with.)

But it won't matter until I build the hardware: I want to build the
hardware first, the HW itself will be totally open source as in free
schematics and full docs etc, and then we'll think about which free
OS(es) we want to run on it.

I still want to build my MPC866 router platform though: even if the
software part has been solved by the fine FreeBSD folks, with the present
situation (PCI as the expansion interface on FreeBSD/Linux-based routers)
one still has the issue that the HDLC interface or the ATM SAR block has
to be wheel-reinvented each time someone wants a different flavor of
Layer 1 physical interface.  The situation is even more pronounced when
a given Layer 1 medium type (say, T1 or SDSL) exists in both HDLC and
ATM flavors.  I would really like to be able to have a single hardware
card that supports both: it is trivial with MPC86x, but I expect it to
be cost-prohibitive to do that on a PCI card.

MS



Re: What is The Internet TCP/IP or UNIX-to-UNIX ?

2010-04-05 Thread Michael Sokolov
Jim Mercer j...@reptiles.org wrote:

 if the script determined an email was  X bytes (100k?), the message body
 was rewritten with:

 Contents removed at LSUC, email is not a file transport protocol.
 and the mail was left to continue on its path.

 i kinda feel like adding the same script back into my servers.

I have my Sendmail configured to cut off anything past 256 KB in the
collect phase.  At first I had it configured to reject the whole message
(close the SMTP connection while the junk is still spewing), but people
started assuming that my E-mail address was bad instead of realizing
that they were sending oversize junk, so I've changed it to cut off and
discard the excess fat, but still let the first 256 KB through so I at
least see that someone tried to send me something.

Files are meant to be FTPed, not E-mailed.  If someone is too stupid to
use a real command line FTP client to upload a file to my FTP drop box,
I make them use www.yousendit.com.

MS



Juniper's artificial feature blocking (was legacy /8)

2010-04-04 Thread Michael Sokolov
Tore Anderson tore.ander...@redpill-linpro.com wrote:

 Juniper.  If you want to run OSPFv3 on their layer 3 switches, you need
 a quite expensive advanced licence.  OSPFv2, on the other hand, is
 included in the base licence.

Really?  My level of respect for Juniper has just dropped a few notches
after reading this NANOG post - I didn't know that they were engaged in
such DRM-like feature blocking practices.

Where can I find more information about Juniper's stance on such
practices (having some feature X present in both HW and SW, but
artificially blocked until one buys an unlock key from them) and the
exact degree to which they engage in such?

The reason I ask is because I've been considering building my own PIM
for their J-series, a PIM that would terminate Nokia/Covad's flavor of
SDSL/2B1Q at the physical layer and present an ATM interface to JunOS,
optionally supporting NxSDSL bonding with MLPPPoA.  I have no love for
routers that aren't 100% FOSS, but I couldn't find any other existing
router platform which could be extended with 3rd-party physical
interface modules, and designing and building my own base router chassis
is not a viable option if I want to actually have something built before
the Sun swells into a red giant and engulfs the Earth.

So I thought that even though it isn't 100% FOSS, JunOS ought to be at
least tolerable given that it appears to be based on FreeBSD and I've
heard that it even allows the user to get direct access to the underlying
Unix shell (does it really?) - but hearing about DRM-like artificial
feature blocking seems to negate that.  I mean, how could their
disabled-until-you-pay blocking of premium features be effective if a
user can get to the underlying Unix OS, shell, file system, processes,
etc?  Wouldn't such access allow smart users to unblock whatever feature
is artificially blocked?

Someone please educate me...

MS



Re: what about 48 bits?

2010-04-04 Thread Michael Sokolov
Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote:

 Has anybody considered lobbying the IEEE to do a point to point version
 of Ethernet to gets rid of addressing fields? [...]
 Actually the minimum 64 byte packet size could probably go too, as that
 was only there for collision detection.

And maybe rename it to something else while you are at it?  All those
people who have hijacked the name Ethernet for PtP links (all those
Ethernet UTP media are really PtP at the physical level, unlike real
coaxial Ethernet) are despicable thieves - now those of us who are still
using the original coaxial Ethernet in the shared bus mode are left
without a clear, unique and distinctive name we once had to refer to
what we use.

MS



Re: Is TDM going the way of dial-up?

2010-03-29 Thread Michael Sokolov
Kevin Oberman ober...@es.net wrote:

 And, if you are using a 1988 TCP stack on a 4.3 system, you are not
 likely to ever efficiently utilize a higher speed link

What higher speed link?  I'm very happy with 384 kbps symmetric, using
SDSL as ARPANET replacement.  I have designed and built my own SDSL to
EIA-530 CSU/DSU so I can use a Cisco 2500 router instead of that nasty
new-fangled Netopia which has (oh horror!) RJ45 Ethernet instead of
proper AUI.  Oh, did I forget to mention that my Ethernet is coaxial?
To me all that UTP stuff isn't true Ethernet.

 and will not
 behave well on any link. TCP has come a long way in the past 12
 years. (Of course, I can't guess what mostly unchanged means.)

Backward compatibility rules!

MS



Re: Is TDM going the way of dial-up?

2010-03-26 Thread Michael Sokolov
Rick Ernst na...@shreddedmail.com wrote:

 I've noticed over the last 3 years or so that TDM, specifically T-1, access
 and transport has been in a steady decline.  Customers are moving to FTTH
 and cable, or going WiMAX and Metro-Ethernet.  Ethernet seems to have taken
 an even bigger bite out of DS-3.  The bigger pipes seem to favor ethernet. A
 recent upgrade from OC-3 to GigE transport actually saved us a large chunk
 of money.

 I'm wondering if others are seeing the same behavior, if it's
 market-dependant, or if I'm just imagining things.

Unfortunately what you are seeing is indeed where the world is going,
and it is extremely painful to watch.  My personal preference is the
direct opposite of that: Ethernet for non-LAN use is my very antithesis,
I hate it to the core of my being.  V.35/HDLC forever for me!  I will
continue using HDLC over traditional synchronous serial WAN media for as
long as I am alive.

MS

P.S. This message is being sent from a VAX running a variant of 4.3BSD
(Quasijarus).  Almost the entire ARPA Internet software stack that's
running on my VAXen is mostly unchanged from how it was in 1988.



Re: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems

2010-03-17 Thread Michael Sokolov
 My spammy sense is going nuts just at the whole ALL CAPS of this guy's 
 last name.

I thought all-uppercase last names were a traditional French convention...
This guy is French, isn't he? - judging by his name.

His habit of addressing everyone as Mister is peculiar indeed, but
maybe he is really just very new to the customs and conventions of the
Anglophone Internet community?

Just wondering...

MS



Any old Nokia DSLAMs gathering dust?

2010-03-17 Thread Michael Sokolov
Hello NANOGers,

I wonder, would anyone here happen to have an unused Nokia / Diamond
Lane Speedlink DSLAM chassis that's laying around gathering dust and
which you wouldn't mind donating to an open source xDSL CPE project?

Just wondering if anyone here might perchance have one they are trying
to get rid of - after all, one man's garbage is another man's
treasure...

MS



SDSL vs T1 (was Locations with no good Internet)

2010-03-06 Thread Michael Sokolov
Patrick Giagnocavo patr...@zill.net wrote:

 Isn't this really an issue (political) with tariffed T1 prices rather
 than a technical problem?

Yes, of course.  It's even worse if you are tied to one particular ISP
(VZB) by non-portable IP addresses.

I wanted service from AS701 with a V.35 hand-off; both requirements
(the ISP choice and the hand-off type) were/are for sentimental reasons.
Speed was/is a lower-priority concern, i.e., I was/am willing to live
with sub-T1 speeds if it allows me to keep my 701-assigned IP addresses
for a lower monthly extortion payment.

My choices were:

1. Get a T1, enjoy the bandwidth (I live in an alternate Universe in
   which T1 bandwidth is almost infinity) and the SLA, and getting a
   V.35 hand-off would have been as easy as pulling an Adtran DSU out of
   my junk pile.  But it was something like $650/month, probably before
   adding taxes and other extortions.

2. Opt for SDSL instead.  I'm within a short walk of my CO, but I opt
   for only 384 kbps to reduce the monthly extortion payment.  And since
   I still want V.35 hand-off, add the expense of designing and building
   my own CPE for it - but it's a one-time expense, and I have learned
   a *lot* in the process - as they say, happiness is a journey, not a
   destination.

 I was told that most T1s are provisioned over a DSLAM these days
 anyways, and that the key difference between T1 and DSL was the SLA
 (99.99% guarantee vs. when we get it fixed).

My situation is different because I am deliberately opting for a lower-
speed service than what's available.  At sub-T1 speeds SDSL has one
advantage: the actual electrical signaling rate on the circuit is
lowered to match the subscription data rate, unlike the fractional T1
kludge.

But if you are specifically looking for a 1.5 Mbps service and are
prepared to pay for 1.5 Mbps, the T1 vs. SDSL trade-off starts to look
murkier:

* With a T1 regardless of who serves it to you and how, you still get
  the classic HDLC encapsulation supported by every decent WAN router;
  with SDSL served out of a Covad DSLAM you get ATM cells on the line,
  wrapped in a wacky frame format:

http://ifctfvax.Harhan.ORG/OpenWAN/2B1Q/flavors/nokia.html

* Prior to my invention of the OSDCU gadget, it was not possible to
  connect a Covad SDSL line to a real router like Cisco (or Juniper or
  a BSD/Linux box or whatever), only to some very inferior router brands
  supplied as the standard CPE.  And as far as my gadget goes, I've
  built the hardware, but I haven't finished the firmware part yet, so
  it's still technically vaporware.

* ATM is much less bit-efficient than HDLC, so a Covad SDSL circuit sold
  as 1.5 Mbps actually has a little less real data carrying capacity
  than a T1.

* I don't know off the top of my head what the monthly price is for
  Covad SDSL at 1.5 Mbps, and there probably is some variability between
  different ISPs who go through Covad, but I assume that even with a
  good deal it would still be a bit more than what I pay to VZB for
  384 kbps.  T1 prices have been coming down OTOH, at least for those
  who aren't tied to VZB.  But I still expect T1 to be at least a little
  more expensive than SDSL @ 1.5 Mbps.  I don't know how big this price
  delta is right now though - would anyone here have a better idea?

The magnitude of this price delta ought to have a critical impact on
whether or not it is worth putting up with all the quirks of SDSL listed
above.  For my peculiar situation (willing to live with 384 kbps and
tied to VZB) the price delta (3x increase in the monthly payment) is
most definitely worth the one-time expense of finishing my OSDCU gadget,
but I don't know how the cards would fall for someone who is looking for
full 1.5 Mbps (or more with bonding) and who has a choice of ISPs.

 And T3/DS3 can run over what, 4 copper pairs?  Yet how much is the
 typical tariffed rate for that?

DS3 over 4 copper pairs?  ~11 Mbps symmetric on each pair?  That seems
like squeezing a lot out of a copper pair to me.  Over what distance?

William Herrin b...@herrin.us wrote:

 The major difference between using HDSL smart jacks and classic smart
 jacks is that the HDSL ones don't need wire that's in quite as good
 shape and they don't need repeaters between you and the CO as often.
 They're still very much a T1 service.

Yup.  Even though at the transceiver chipset level HDSL and SDSL are
very much alike, the powers that be configure them very very differently
at the higher layers.  HDSL units are configured to pass the entire T1
frame structure (SF/ESF) unaltered, and within that T1 frame structure
you get the good old familiar HDLC.  Covad SDSL uses the same 2B1Q line
code as HDSL and even the same transceiver chip (Bt8970 or RS8973), but
stuffs the bit stream with ATM cells in a wacky non-standard frame
structure instead of HDLC or T1 frames.

One can either pay a monthly premium for a more standards-based bit
stream format, or pay less per month for the hoary 

Re: SDSL vs T1 (was Locations with no good Internet)

2010-03-06 Thread Michael Sokolov
Roy r.engehau...@gmail.com wrote:

 You missed an option.  Just change to another ISP.  I know of at least 
 one AS701 address block still attached to a company that hasn't been 
 their customer for ten years or so.

How is that possible?  AFAIK no local politician has passed an IP
address portability law yet.  If my circuit from VZB were disconnected,
wouldn't they release the address block for reuse by other customers
just like any other ISP?

I'm kinda guessing that you're suggesting that VZB's business practices
are lax and that I may slip through the cracks?  But there is no
guarantee of any kind, is there?  If they were to release/reuse my
address block like they would have every right to, what recourse could I
possibly have as a voluntarily disconnected customer?

And even if the block remained unused / not reassigned after I left VZB,
how could I possibly get it routed to me while connected through another
ISP?

I just don't get it - I don't see how this could be done without some
local politician passing an IP address portability law like has been
discussed recently.

MS



Re: Locations with no good Internet (was ISP in Johannesburg)

2010-03-03 Thread Michael Sokolov
Charles N Wyble char...@knownelement.com wrote:

 The biggest problem is middle mile. That is where the money needs to go.
 You need something to back haul to the interwebz. There is a lot of
 fiber in the ground already,

Another possible way to solve the middle mile issue would again be to
use the copper plant that's already in the ground.  Unlike fiber, the
copper plant is *ubiquitous*: I don't know of any place in the 1st or
2nd worlds that doesn't have copper pairs going to it.  Also AFAIK T1s
are available everywhere too: if you order a T1, they'll deliver it to
you regardless of how deep you are in the middle of nowhere, although I
suppose there likely are extra surcharges involved.

Granted, a T1 at 1.5 Mbps may not be much for backhaul, but what about
bonded T1s?  Bond 4 of them to get 6 Mbps symmetric - not too bad in my
book for a rural community.

And again using SDSL instead of T1 offers a cost reduction opportunity.
One could get that 6 Mbps symmetric for much cheaper by bonding 4 SDSL
circuits running at 1.5 Mbps each instead of T1s.  There is a Covad
DSLAM with SDSL capability in virtually every CO in the country, but
they serve out a whacky flavor of SDSL/2B1Q.  I have good reason to
suspect that I may be the last person alive on Earth who knows how to
make CPE for this flavor *and* who cares about such things.

 but there are numerous layer 8 issues with
 getting to it most of the time. Solving those is an exercise left for
 the reader.

Layer 8?  Assuming that layers 8, 9 and 10 are management, financial and
political, respectively, the issues that keep me from being able to
build that Covad-compatible bonded NxSDSL CPE device lie at Layer 9.
Anyone interested in helping me solve those issues?

MS



Locations with no good Internet (was ISP in Johannesburg)

2010-02-26 Thread Michael Sokolov
Daniel Senie d...@senie.com wrote:

 Better than western Massachusetts, where there's just no connectivity at =
 all. Even dialup fails to function over crappy lines.

Hmm.  Although I've never been to Western MA and hence have no idea what
the telecom situation is like over there, I'm certainly aware of quite a
few places in first world USA where DSL is still a fantasy, let alone
fiber.

As a local example, I have a friend in a rural area of Southern
California who can't get any kind of high-speed Internet.  I've run a
prequal on her address and it tells me she is 31 kft from the CO.  The
CO in question has a Covad DSLAM in it, but at 31 kft those rural
residents' options are limited to either IDSL at 144 kbps (not much
point in that) or a T1 starting at ~$700/month.  The latter figure is
typically well out of range for the kind of people who live in such
places.

That got me thinking: ISDN/IDSL and T1 can be extended infinitely far
into the boondocks because those signal formats support repeaters.  What
I'm wondering is how can we do the same thing with SDSL - and I mean
politically rather than technically.  The technical part is easy: some
COs already have CLECs in them that serve G.shdsl (I've been told that
NEN does that) and for G.shdsl repeaters are part of the standard
(searching around shows a few vendors making them); in the case of
SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters
and hence no major vendors making such, but I can build such a repeater
unofficially.

The difficulty is with the political part, and that's where I'm seeking
the wisdom of this list.  How would one go about sticking a mid-span
repeater into an ILEC-owned 31 kft rural loop?  From what I understand
(someone please correct me if I'm wrong!), when a CLEC orders a loop
from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or
ISDN BRI transport from the ILEC rather than a dry pair, and any
mid-span repeaters or HDSLx converters or the like become the
responsibility of the ILEC rather than the CLEC, right?

So how could one extend this model to provide, say, repeatered G.shdsl
service to far-outlying rural subscribers?  Is there some political
process (PUC/FCC/etc) by which an ILEC could be forced to allow a third
party to stick a repeater in the middle of their loop?  Or would it have
to work by way of the ILEC providing a G.shdsl transport service to
CLECs, with the ILEC being responsible for the selection, procurement
and deployment of repeater hardware?  And what if the ILEC is not
interested in providing such a service - any PUC/FCC/etc political
process via which they could be forced to cooperate?

Things get even more complicated in those locations where the CO has a
Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving
G.shdsl.  Even if the ILEC were to provide a G.shdsl transport service
with repeaters, it wouldn't help with SDSL/2B1Q.  My idea involves
building a gadget in the form factor of a standard mid-span repeater
that would function as a converter from SDSL/2B1Q to G.shdsl: if the
loop calls for one mid-span repeater, stick this gadget in as if it
were that repeater; if the loop calls for 2 or more repeaters, use my
gadget as the first repeater and then standard G.shdsl repeaters
after it.  But of course this idea is totally dependent on the ability
of a third party to stick these devices in the middle of long rural
loops, perhaps in the place of loading coils which are likely present
on such loops.

Any ideas?

MS



Re: Locations with no good Internet (was ISP in Johannesburg)

2010-02-26 Thread Michael Sokolov
Brandon Galbraith brandon.galbra...@gmail.com wrote:

 Get dry loops from the ILEC and place repeaters at strategic points?

I guess I need a little more education on how the process of ordering
dry pairs from an ILEC works.  I thought it works like this:

1. You have to be colocated in the CO to begin with.

2. You give the ILEC the address of an end site and they run a dry pair
   from your cage within their CO to that address.

3. You don't get access to any intermediate points.

As far as placing the repeaters at strategic points, yeah, that's
exactly what I meant, but my point was that these strategic points are
owned by the ILEC, and I was/am wondering how to go about making it
possible for a third party to stick repeater equipment in there.

I envision the following picture:

* There is a CO in a town, and there is a Covad DSLAM in that CO,
  serving those folks who are located in the town itself.

* There is a winding mountain road going out of town into the
  countryside, and there are phone wires running alongside that road,
  several miles long.

* There gotta be a bunch of cyan-colored cross-connect boxes on the side
  of the road, manholes and other places where the ILEC has mid-span
  access to those lng loops.  They also very likely have loading
  coils on loops like that, and although I confess that I've never seen
  one of those coils with my own eyes, I've heard that they are rather
  bulky in terms of physical dimensions, probably bigger than a repeater
  PCB.

The problem is that these mid-span access points are property of the
ILEC along with the rest of the loop plant, and although there probably
exists an ILEC-internal procedure for installing mid-span repeaters for
T1s and maybe ISDN BRI, that is most certainly done by the ILEC itself,
not by any third parties.  Making it possible for a third party to
access those intermediate points to install repeater equipment which the
ILEC won't understand (handling Covad's non-standard flavor of
SDSL/2B1Q) is the problem I'm trying to solve.

MS



Re: Locations with no good Internet (was ISP in Johannesburg)

2010-02-26 Thread Michael Sokolov
Brandon Galbraith brandon.galbra...@gmail.com wrote:

 http://www.rric.net/

I'm very familiar with those folks of course, they've been an inspiration
to me for a long time.

However, my needs are different.  RRIC's model basically involves a
specific community with a well-defined boundary: bring the bandwidth
into the community via a bulk feed, then sublet inside the community.

But I don't have a specific community in mind - I'm trying to develop a
more generic solution.  (The case of my friend who is at 31 kft from a
Covad-enabled CO is only an example and nothing more.)  Again, consider
a town with a Covad-enabled CO plus an outlying countryside.  The people
in the town proper already have Covad xDSL available to them, and if we
could stick my SDSL/2B1Q repeater in the middle of some longer loops, it
would enable the people in the countryside to get *exactly the same*
Covad (or ISP-X-via-Covad) services as those in the town proper.

My repeater approach would also allow me to stay out of ISP or ISP-like
business which I really don't want to get into - I would rather just
make hardware and let someone else operate it.  A repeater is totally
unlike a router, it is not IP-aware, it just makes the loop seem shorter,
allowing farther-outlying users to connect to *existing* ISPs with an
already established business structure.

Anyway, I just saw a post on NANOG about an area deprived of high-speed
Internet services and thought I would post my idea in the hope that
someone would have some ideas that would actually be *helpful* to what
I'm trying to do.  If not - oh well, I'll just put the idea back on the
dusty shelf in the back of my mind until I'm ready to try presenting it
to the folks who own the CO-colocated DSLAMs it would have to work with
- gotta finish a few other things before I open that can of worms in the
earnest.

MS



Re: Using /31 for router links

2010-01-23 Thread Michael Sokolov
Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote:

 What about NAT, ATM cell tax, unnecessary addressing fields in PTP
 protocols (including your beloved HDLC), SSAP, DSAP fields not being big
 enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1
 through AAL4, PPPoE dumbell MTUs and MSS hacks? Some of those are far
 worse sins in my opinion.

Hmm.

PPPoE: this kludge is a direct fallout of abusing Ethernet for WAN/PTP.
If all those xDSL users were willing to stick V.35 cards in their PCs
and use modems that put out V.35 instead of Ethernet, the whole PPPoE
kludge with all of its attendant MTU issues would have been completely
unnecessary.  Want PPP for authentication etc?  Just run straight PPP
(RFC 1662) over V.35 instead of Ethernet/PPPoE, HDLC has no fixed MTU
unlike Ethernet (jogging my memory, all HDLC controllers which I recall
working with allowed maximum frame size up to just a little under 2^16
octets or so), and one can thus have the standard MTU of 1500 octets on
that PPP link!

Oh, and yet another soapbox of mine, an xDSL modem that puts out V.35
instead of goddamn Ethernet would be a true modem: a modulator/demodulator
that modulates/demodulates the bits at the electrical level without
caring about what's in those bits.  What everyone else in this fubared
world calls an xDSL modem (a black box that puts Ethernet out) is not
a modem at all (i.e., total misappropriation of the term), it is
actually a bastardized router!  These boxes forward packets between two
network interfaces: the presented Ethernet interface and the internal
(often horrendously non-standard and proprietary) HDLC or ATM interface
on the actual line.  A device that forwards packets between two
different network interfaces is by definition a router, hence what
everyone calls a modem is actually a bastardized router - bastardized
because its routing (packet forwarding) function is something
incomprehensible.  The Ethernet-to-Ethernet NAT boxes that everyone else
calls routers should be called NATters or something like that,
anything but a router!  A true router is a box with a few AUIs and a few
V.35 ports sticking out of it, running some very capable, flexible and
totally user-configurable packet forwarding software stack that supports
all networking models: IP routing, MAC bridging, VC cross-connect.

As for ATM...  The part that totally baffles me about the use of ATM on
xDSL lines is that I have never, ever, ever seen an xDSL line carrying
more than one ATM VC.  OK, there may be someone out there who has set up
a configuration like that just for fun, but 99.999% of all ATM'd xDSL
lines out there carry a single PVC at 0*35 or 0*38.  So what then is the
point of running ATM?!?!  All the hyped benefits of ATM (a little cell
can squeeze in the middle of a big packet without waiting for it to
finish, yadda yadda yadda) are contingent upon having more than one
VPI/VCI going across the interface!  If every single non-idle cell going
across that ATM interface is 0*35 or 0*38, the interface will never
carry anything other a direct succession of cells making up an AAL5
packet, strictly in sequence and without interruption.  So what's the
point of ATM then?  Why chop that packet up into cells only to transmit
those cells in direct sequence one after another?  Why not simply send
that same packet in plain HDLC over the same copper pairs/fiber?  OK,
the backhaul network upstream of the DSLAM may be ATM and that one does
have many VCs, so ATM *might* be of use there, but even in that case why
not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul,
sending HDLC down the copper pairs?

off the soapbox for the moment

MS



Re: Using /31 for router links

2010-01-23 Thread Michael Sokolov
Stephen Sprunk step...@sprunk.org wrote:

 Ah, but who's to say that all PTP links are WANs?  Are you really going
 to run an OC-48 from one router to another _in the same building_ when
 you need 1Gb/s between them?

Can't say - I have never needed that much bandwidth. :)  I still live in
an alternate Universe where 10 Mbps coaxial Ethernet for LANs is near-
infinity and 2 Mbps or so makes for a *very* sweet WAN.  The facility
housing the mail server from which I am sending this message is
connected to the outside Inet via a 384 kbps SDSL pipe which I am using
basically as ARPANET replacement - I miss the ARPANET.

If I wanted a PTP link between two routers in the same building that
runs at the same speed as my Ethernet (10 Mbps), I would use EIA-422
(which is rated up to 10 Mbps) and run something HDLC-based over it.

 Even for MANs or WANs, the price of a pipe (plus equipment at each end)
 will still often be significantly lower for Ethernet than for real
 circuits

Wait a moment here.  With a MAN/WAN involving wires/fiber running over
public property, what one is paying for is the right to use those wires
for your data, right?  The wires themselves do NOT run Ethernet at the
electrical level, so if you have some MAN/WAN Ethernet service, there
is a black box of some kind that converts the native electrical signal
format to Ethernet.  Why not take that black box out of service, use it
for baseball practice (Office Space style), and use the exact same
wires/fiber (rented at exactly the same monthly recurring price) in its
native non-Ethernet form?

IOW, if you are renting dry copper / dark fiber, you have a choice to
use it either through a stinky black box Ethernet converter or in the
native non-Ethernet form directly, but the monthly recurring cost
remains exactly the same.

 Well, it'd certainly be nice if someone would make something even
 cheaper than Ethernet for that purpose (which would squeeze out a few
 more bits of payload), but so far nobody has.  It's hard to beat
 Ethernet on volume, and that's the main determinant of cost/price...

But that's non-recurring equipment cost only, and at least in my case
the little investment in V.35 etc hardware is a much lower cost than the
price of pain and suffering with Ethernet for a purist like me.

MS



Re: Using /31 for router links

2010-01-23 Thread Michael Sokolov
Brielle Bruns br...@2mbit.com wrote:

 Back in the days of Rhythms and Copper Mountain gear, Netopia had the D 
 series routers which were actually xDSL to DSU units.

Yes, I am very familiar with them:

http://ifctfvax.Harhan.ORG/OpenSDSL/existing_cpe/netopia/dsu.html

As that page explains, they are only pseudo-DSUs though.  I much much
prefer a true bit-transparent DSU:

http://ifctfvax.Harhan.ORG/OpenSDSL/existing_cpe/xsb2000.html

I have also designed and built an SDSL to EIA-530 DSU of my very own:

http://ifctfvax.Harhan.ORG/OpenSDSL/OSDCU/

On the latter I have the hardware (the page above has a photo of the
board), but the operational software (or firmware if you will) remains
to be finished.

 Though, I'm not sure they'd work these days,

Only in the very limited geographic footpring of what used to be DSL.net
- they are the last remaining semi-major operator of CM DSLAMs:

http://ifctfvax.Harhan.ORG/OpenSDSL/megapath.html

My big goal is to make my own DSU which I have just mentioned function
as a Layer 2 converter (FRF.8 and friends) from Nokia SDSL/ATM served by
Covad to HDLC.

 nor do I think 
 they came in ADSL models either.

I don't think anyone have *ever* used V.35  friends with ADSL -
probably because those who would want V.35 (i.e., people like me) would
find ADSL morally offensive. :-)

MS



Re: Using /31 for router links

2010-01-22 Thread Michael Sokolov
Nathan Ward na...@daork.net wrote:

 ARP is still required on ethernet links, so that the MAC address can be =
 discovered for use in the ethernet frame header. /31 does not change the =
 behavior of ARP at all.

soapbox

That is why I hate Ethernet with a passion.  Ethernet should be for LANs
only; using Ethernet for WANs and PTP links is the vilest invention in
the entire history of data networking in my opinion.

My medium of choice for PTP links (WAN) is HDLC over a synchronous
serial bit stream, with a V.35 or EIA-530 interface between the router
and the modem/DSU.  Over HDLC I then run either RFC 1490 routed mode or
straight PPP (RFC 1662); in the past I used Cisco HDLC (0F 00 08 00 IP
header follows...).  My 4.3BSD router (or I should better say gateway as
that's the proper 80s/90s term) then sees a PTP interface which has no
netmask at all, hence the near and far end IP addresses don't have to
have any numerical relationship between them at all.  No netmask, no MAC
addresses, no ARP, none of that crap, just a PTP IP link.

/soapbox

MS



RE: Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions)

2010-01-05 Thread Michael Sokolov
Frank Bulk - iName.com frnk...@iname.com wrote:

 It's being done by Actelis, Hatteras, and Zhone.  More exactly SHDSL or
^
 similar variants.  The market is being well-served.
  ^

The highlighted sentence is precisely the difference between what they
are doing and what I am doing.  The SHDSL folks seem to live in some
kind of fantasy world where they think that all major network operators
are going to throw out all their SDSL/2B1Q infrastructure and install
SHDSL DSLAMs across the country instead.

My SDSL work on the other hand is oriented toward working with the
existing SDSL/2B1Q infrastructure massily deployed across USA by
networks like Covad and what used to be DSL.net (now part of MegaPath).
My Open SDSL Connectivity Project has successfully reverse-engineered
the proprietary SDSL/2B1Q flavors used by the DSLAM brands deployed by
the two networks named above, and I want to build bonded SDSL CPE for
those flavors/networks.

And yes, I have already had discussions with some people at both of the
named companies.  It wasn't even necessary for me to initiate contact
with them as both of them have sought my open source project out and
contacted me on their own about this very idea of SDSL bonding.  However,
despite lots of excited talk, both dialogues have ended with a mutter.
Apparently there is some kind of wall of arrogance that prevents those
folks from even considering getting their CPE from a mosquito like me,
even though I can deliver it for one-tenth to one-hundredth of what the
big vendors would want for the same thing if they would even consider
building such - those big vendors have plenty of their own arrogance!

Therefore, my next angle of approach is to see if there are any ISPs who
go through Covad or through MegaPath's ex-DSL.net component as their
Layer 2 transport (I know that at least in Covad's case there is a huge
number of ISPs large and small who do that) and who want bonded SDSL
badly enough to punch through that wall of arrogance.

If you are an ISP who rents Layer 2 transport from Covad and I were to
supply you the CPE, I think you should be able to serve bonded SDSL to
your customers without having to beg Covad to descend from the heavens
and give that service its blessing.  Just order 2 (or 3 or 4 or however
many loops you want to bond) ATM transport pipes from Covad terminating
at your customer's address on one end and at your DS3/ATM interconnection
point on the other end.  Have your Cisco/Redback/whatever router run
PPPoA on each of those ATM pipes and do MLPPP bonding between them.  All
that would be needed then is the CPE, and that's what the Open SDSL
Connectivity Project is for...

MS



Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions)

2010-01-04 Thread Michael Sokolov
Frank Bulk - iName.com frnk...@iname.com wrote:

 We offer it, but practically speaking we haven't gotten much higher than 1.5
 Mbps on the upstream.

Sorry that I'm coming into this thread late (I have just subscribed),
but since I see people discussing DSL with beefy upstream, I thought I
would be brave and ask: do you esteemed high-end network op folks think
that there may be anyone in the world who might be interested in bonded
SDSL or not?

I have spent the past 5 years of my life learning everything there is to
know about SDSL.  Don't ask me why, I don't really know the answer to
that question myself.  I won't waste the bandwidth of this elite list
with dirty details of just what I've done with SDSL over the past 5 y,
but I'll give a link to an open source project that contains the body of
SDSL knowledge amassed over those years:

http://ifctfvax.Harhan.ORG/OpenSDSL/

To make the long story short, for most of those years I kept trudging on
my project, treating it as an ultra-weird hobby that no one else in the
world could possibly have any interest in.  That persisted until 2009
when my project got noticed by two fairly major North American DSL
network operators.  (Well, one very major and one semi-major, but I'll
spare the names.)  Both of those had contacted me via my Open SDSL
Connectivity Project expressing interest in SDSL bonding.  Both
companies were telling me how much interest they had in SDSL bonding,
how much it would help their business to be able to offer bonded SDSL
services at 3 or 6 Mbps, how many customers they would be able to sign
up for these services, etc.  But when I asked them to back their
verbally-expressed interest with the tiniest amount of money or even no
money at all but a letter of intent which I could show to SBA etc, they
both went silent.  We've been playing a game of cat-and-mouse ever since.

As far as I could understand the existing situation is that the SDSL
infrastructure already deployed en masse by the major North American DSL
network operators already has the capability to serve out bonded SDSL
circuits, bonding either in the DSLAM or somewhere upstream of it, using
MLPPP, Multilink Frame Relay or whatever else one can think of, but the
problem is with CPE.  Apparently bonding-capable multiport SDSL CPE
devices are quite scarce.

Considering everything I've done with SDSL over the past 5 y, I believe
I have a right to say with confidence that I am more than capable of
designing and building a bonding-capable multiport SDSL CPE device for
any existing SDSL flavor with any desired number of ports (2, 4 or
whatever).  But what I don't know, and what I'm asking this highly
esteemed list for advice with, is this question: is there anyone at all
in the world who might have a real serious interest in such a thing?

If there is someone in the world who would truly appreciate having a
bonded SDSL solution, I would be delighted to work on developing such a
thing.  I would see it as a service to humanity whereby more use would
be made out of existing copper infrastructure in the ground instead of
having to dig more ditches to bury more fiber or whatever.  But if there
is no one in the world who would be interested in bonded SDSL (or at
least interested enough to invest one dime into development), then why
bother...

MS