Hi Tim, glad you added your views here.
As I read your reply, I retraced the development of the
discussion, which shows my initial "first glance" remarks,
leading up to a stronger sense that the problem was most
likely in the access and/or edge areas. In the process, I
discounted the various potential loop causes which I
previously stated, and which you enumerated on, although I
did leave some room open for these types of problems to
come to fruition later on, as DSL uptake progresses.
BTW, I wasn't being cynical when I stated that "cleaner pair
hunts" might ensue for the DSLs -at the possible detriment of
the dialups- only being realistic, since regular dialups are not
covered by data-related tariffs or SLAs, in the same way
that DSLs will be. Some copper and DLC configurations
could be entirely suitable for straight voice communications,
and still be useless for data rates above 9.6 kb/s.
"Do you imagine it is possible that all of the BLS repair
technicians working the problem are so outside plant
oriented that they might not be aware of such "inside"
potential trouble spots with these trouble reports?"
With all due deference and respect to the trials and
tribulations that service desks endure every day, I do
actually believe that such a disconnect does exist, almost
across the board, when introducing data related problems
to service groups whose primary roles have been in POTS.
Veteran test desk personnel are not sensitized to the
nuances of latter day IP-related problems, at least not
anywhere near where they are attuned to matters affecting
dial tone. Especially in residential end offices. Maybe I'm
wrong about this, and everything is centralized in New
Orleans from a remote access test desk, I don't know. My
sense would be that even though these are data affecting
problems, the reports probably still go to the POTS folks for
diagnosis and resolution. There would be no reason, by
definition, for them to go anywhere else, unless a squeaky
wheel syndrome kicked in.
I had considered IPRS-like application possibilities, along
with other methods used to perform access arbitration,
mediation, and redirects (the types used to free up central
office switch resources), but since this problem manifested
among multiple ISPs, and since this was residential... I
tended to discount it. Primarily for those reasons, and for
lack of any evidence that it was being subscribed to.
Incidentally, I had to go back and refresh on IPRS, a al
BEL's approach, and I have to ask if this is available by
other RBOCs [specifically, BLS in this case] under the same
service heading, as well. I became aware of IPRS last year,
but never saw it in any other context other than BEL's.
Curious.
When I first came across IPRS, it appeared to me to be a
response that BEL was going to employ in order to offset
some clever CLEC options that were being made available to
ISPs, primarily, in order to save them money on access costs.
For others who may be interested in knowing more about
this service, see:
bai.net
But this general discussion does bring up the possibility of
some level of data path arbitration (and redirect) process not
being tuned properly, which again puts the problem into the
access platform and edge transiting areas. Such would be the
case if the ILEC recently implemented a means to alleviate
congestion and long hold times that would cause blocking in their
end office switch, by introducing such a redirect measure.
Just for my own edification here, Tim, how would IPRS
(IP [re]Routing Service) come into play with residential
customers using different ISPs? I think that this would
require that all of the non-AOL ISPs affected would need to
be subscribing to the same service from BLS. I don't view
that as likely, but one never knows. What do you think?
Regards, Frank Coluccio
|
