3Com Engineer confirms problems

"3Com Engineer Responds"

Posted 3/9/98

I posted the following message to the USR-TC mailing list:

-----Original Message-----
From: Allen Marsalis <am@shreve.net>
To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
Date: Thursday, March 05, 1998 10:15 PM
Subject: Re: (usr-tc) Breaking v.90 / 3Com news


>Dunno what you think of Jack Rickard but you might want to take a look
>at this related article on 56K issues also.... I just loved the
>empirical results of his 56K dialup tests.. x2 was a good 10kbps
>faster on average than kflex across 89 national isps.. Can only imagine
>what MZ thinks of Jack and his methods..
>
>http://www.boardwatch.com/mag/98/mar/bwm24.html
>
>I also heard MPIP for HiPer is shipping in the next release scheduled for
>mid to late March. Can't hardly wait..
>
>allen


I found the article to be very interesting. Also think his dialup tests were
severely flawed. I've put a link to the article and added why the tests are
worthless on my page at http://pages.prodigy.net/bbhi/r-rnut-x2.htm

Thanks for the info.

Aloha,
Richard

This is the reply of John Powell, 3Com Engineer:

From: "John Powell"<John_Powell@mw.3com.com>
To: bbhi@prodigy.net
Cc: usr-tc@lists.xmission.com
Date: Mon, 9 Mar 1998 03:00:49 -0600
Subject: Re: (usr-tc) Breaking v.90 / 3Com news

Aloha Richard,

I checked out your web page, and it sure looks like you have had a bad time
with x2 (and even more with K56).  For the x2 problems, I apologize.

I can say with a great deal of certainty, this issue you are encountering
is a pad issue.  The ability to get x2 on LD calls and not on local (with
the definition of "local" and "LD" being a judgement call by the telco) is
a tell-tale sign.  I can also say with a great deal of confidence that you
are REALLY going to like our implementation of V.90!  The pad problems are
quite rare, as we got most of them covered, but there were certainly enough
people having problems to justify an overhaul of the pad detection scheme.

I think you hit the issue on the head in your comments on the pad issue and
telco configurations. There is no way that the telcos will be able to put
only pads on the network that 3Com/USR, Rockwell, Lucent or whoever wants
to be in the path.  We came to that conclusion quite some time ago.  We
could have tried to put a patch in for every possible digital pad we have
found over the last year (and various combinations of digital impairments),
but that would have been an endless process, would have taken up huge
chunks of memory and would have caused incredible havoc for ISPs and client
customers trying to figure out what revs of code are on either end and what
pad or RBS pattern was causing the problem, in addition to sucking up
development and test resources that were best put on the "total kill
solution".

The only way to do this right was to kill them all at once, on the fly,
automatically.  This took a fairly signiificant amount of research and
development and had to be implemented carefully.  The Boardwatch article
pretty much covers the topic, see the section on "DIL" (or "Digitial
Impairment Learning").  The way the "DIL" was implemented in 3Com V.90
modems will solve exactly the logistical problems you describe.  It is
designed (and tested) to detect the digital impairments during training,
and build a custom constellation on the fly designed to overcome or
circumvent whatever digital impairments it encounters in the path.  This
works on a call-by-call basis to handle different routing paths and for use
on different lines served by different COs and/or PBXs with different
settings.  It even works through A-law to mu-law conversions.  It is very
automatic and requires no configuration, it just works.  When you get the
V.90 upgrade for your Courier, and connect to a V.90 server, you will hear
a new "bong-bong" sound at the end of the training sequence, that is the
DIL sequence.  This concept has been in field testing since way back in
October, works great and is very refined now.

As far as your points that the Boardwatch testing was flawed due to the
testing being mostly toll calls.  You are right to a degree, but not
totally.  You would be surprised how many ISPs use creative, innovative
techniques pioneered by the CLECs to provide local dialup numbers to super
POPs concentrated in cities far away.  These calls are backhauled over
digital lines back to the real POP, often over multiple AMI links that add
additional Robbed Bits with digital padding applied that is consistent with
an LD call.  Boardwatch's tests showed mostly 1-3 Robbed bits in the path,
which is pretty typical of a CLEC networked Super-POP "local" call.   Also
note that the "throughput tests" done to verify connect message to
throughput consistency were done to local Denver ISPs, not over LD calls.
They also "favored" local POPs in their wardialer program (both for the
reasons you mention, plus the obvious cost factor).

On the similar note you made on 3Com's testing procedures.  The description
of the testing in the article was just a "gloss-over".  The concept of
ensuring a duplication of the "typical local call" was not lost in the test
design and site choices.  There were 11 POPs in 10 countries, with 2 POPs
in the US.  One on the "left coast", and one in the middle (Skokie).  The
vast bulk (roughly 70%) of the testers were local to the test POPs, and the
remainder were long distance.  This provided a very wide variety of pad,
robbed bit and Round trip delay values and covered the "network model"
very, very well.  We also made special efforts to test on local calls in
areas known to cause trouble to x2.  Raleigh/Durham, NC. and Korea are two
that come to mind.  I wish I had known their were problems in Hawaii a few
months ago, that would have been a real nice field trip in December ;-)

Anyway, I did not want to barrage you with data and facts, but the
conclusions you made were based on some partially false assumptions and
begged for clarification.  I truly regret the trouble you have encountered,
but know that there are many, many people at 3Com that totally "give a
hoot", do know what some of our customers are experiencing and are
dedicated to resolving the problems once and for all.  I am confident you
will be totally blown away by the improvements we have put in this code.

Our goal is to achieve 92% network coverage.  5% are taken off the top due
to additional A/D conversions, and another 3% that have so much noise or
other analog impairments that it is just not possible.  We believe we have
reached, or are very close to, that goal with our V.90 release.  We will
probably not be perfect, but this is the result of two years of solid R&D
and should please many a user.

I hope this clears the air a bit, and gives you something to look forward
to.  I know you are pessimistic, and for good reason, but I know you will
be pleased when you get a chance to make a V.90 call with your Courier.
Remember, these improvements in digital impairment detection require V.90
code at the server end also, otherwise you are in x2 backwards
compatibility mode with the same restrictions (which will be fine for most,
but you really need the V.90 fixes for your environment).

Regards,

John Powell
3Com Carrier Systems Division
x2/V.90 Engineering Team

A searchable archive of the usr-tc discussion group is at:
http://usr-tc.datasys.net/
A downloadable archive is available at:
ftp://ftp.xmission.com/pub/lists/usr-tc/archive

To subscribe,
send a message to mailto:majordomo@xmission.com with this text in the body:
subscribe usr-tc (if you subscribe, you will receive all messages, primarily dealing with USR Total Control equipment used by ISPs)