To: WTC who wrote (3970 ) 6/1/1999 12:34:00 PM From: Frank A. Coluccio Read Replies (2) | Respond to of 12823
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