Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (ASCEND) Callback time to long...

On Fri, Feb 20, 1998 at 06:44:52PM -0800, Matt Holdrege wrote:
> At 04:25 PM 2/20/98 -0800, Kevin A. Smith wrote:
> >At 06:17 PM 2/20/98 +0100, Winfried Haug wrote:
> >>Hello..
> >>
> >>we have a customer with a pipeline50 (rel. 5.1A+) which connects to
> >>us via Callback. We call him, he calls back. The time until the lan session
> >>comes up is 5-6 seconds (8 Pings get lost). This is too long. Competing
> >>solutions only have 2-3 seconds... 
> >
> >Competing solutions??

Good question. Must be *ware that has no call collision effect and
run under ideal circumstances (minimal telco delay, no B channel reser-
vation effects). But seems possible.

> >
> >>The callback call comes in after 2-3 seconds, but it takes 4 seconds
> >>until the Lan Session comes up...
> >
> >RADIUS authentication involved after the call-back?
> 
> There are also ISDN connect time improvements in 6.0 that may help. But
> Radius delays still apply. On 6.0 I would expect the connect time to be
> only 1 second.

Sounds interesting. I've done a bit of testing lately and found out
that the first LCP answer I'm getting from our 4k is 2 to 3 seconds
into the connection (i.e. _after_ the client side got the CONNECT of
the B-Channel). This was in a discussion about syncPPP vs. rawIP (i.e.
EU-RAW) and the outcome was that my delay of 3s is not dependend on the
mystical PPP overhead. With EU-RAW the first two ICMP echo requests
time out and the first response packet comes after 3s as well. I would
see two possible reasons:

1) B channel assignment delays. Seems to be a growing phenomenon, especially
   with PBXes. The channel is signalled to have connected but it isn't
   really, it gets transparent some time later. ISDN equipment usually
   applies an arbitrary penalty delay after CONNECT and before actually
   touching the channel. Does the Maxes have such delay ? If yes, how
   large is it ? The downside of such delay is clearly that it increases
   the delay the other side sees. On my Linux I4L I'm currently using
   400 ms (this is ten times the default of 40 ms) as penalty delay
   and it doesn't change anything, neither the first two LCP frames (in
   syncPPP mode) nor the first two IP packets (in EU-RAW mode) seem to
   make it to the other side.

2) Max problems with taking calls. I seem to remember that there was a
   time (some major firmware version(s) ago) when taking a call was very
   performant, say 1 to 2 seconds to have a syncPPP call up. Especially
   when I think back to the good old P400 we did use. When reading the
   above I'd guess that call acceptance really got slower and 6.x will
   fix that. How exactly ?

Anyway, I'd think a Callback that is up after a total of 5 to 6
seconds is not that bad. Callback has a lot of bad influence factors,
especially due to the still present call collision problems with
outgoing callback triggering calls vs. incoming callbacks on the
whole Ascend platform, despite telco problems (delayed RELEASE COMPLETE
signalling and overoptimistic B channel allocation). Is there a chance
for a fix to the first aspect in 6.x ? Combined with a callback delay
timer (user configurable) on the P50's this would eventually help us
get rid of the hacks that are in use at the moment (the infamous "RADIUS
wrong IP in outgoing profile hack" etc).

-- 

Kanther-Line: PGP SSH IDEA MD5 GOST RIPE-MD160 3DES RSA FEAL32 RC4

+-o-+--------------------------------------------------------+-o-+
| o |               \\\- Brain Inside -///                   | o |
| o |                   ^^^^^^^^^^^^^^                       | o |
| o | Andre' Beck (ABPSoft) beck@ibh-dd.de XLink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>
References: