Conference help::decnet-osi_for_vms

    Versions of DECnet/OSI before V6.3 do not implement NSP segment flow
    control correctly under all circumstances and this caused problems with
    other implementations which do implement segment flow control. The fix
    was to set NSP on DECnet hosts to use no flow control (i.e. the Phase
    IV flow control mechanism).
    
    So the answer is if you are using a variant of DECnet/OSI before V6.3,
    you must set NSP flow control to no flow control otherwise you will
    lose data (I think the symptom is that GAP connections hang). If you
    are using DECnet/OSI V6.3 onwards, it all works correctly and you don't
    need to change anything.
    
    I don't have the architecture docs to hand, but flow control sorts
    itself out: if one end states that it can't or won't use segment flow
    control they will both use no flow control.
    
    Antonio

	We're using DECnet/OSI V6.3-ECO5 on AXP and we have
	the problem that X.25 GAP connections hang.

	So it's still not fixed isn't it ?

	Peter

>	We're using DECnet/OSI V6.3-ECO5 on AXP and we have
>	the problem that X.25 GAP connections hang.

If you have a problem, raise an IPMT (as this is Alpha, I won't see it so you
may already have done this).

GAP connections hanging might be caused by any of a number of things:
incorrectly coded X.25 application, X.25 network problems, X.25 GAP
client/server problems as well as the NSP flow control problem.

To determine whether NSP flow control is the culprit you need to take an NSP
trace and verify that you actually have flow control problems. (Or, as a quick
check, set flow control policy to no flow control on the Alpha and see if your
problem goes away).


Antonio

Peter,

Do *not* refer to "the problem", or make statements like "it is still not
fixed". If "it" or "the problem" refers to the well known NSP flow control
problems which existed prior to V6.3, then they are definitely fixed in
V6.3! There were at least 5 interacting problems, which were fixed in V6.3.
The reason that the fixes were never released as an ECO to V6.2 (for example)
is that the changes were too extensive and therefore required to be field
tested (as for a complete new version, not an ECO).

There have been a number of problems with NSP since the release of V6.3, and
some of these problems have appeared to be the NSP flow control problem, as
setting "NSP Flow Control Policy = No Flow Control" has sometimes acted as
a work-around. But, it is impossible for the pre-V6.3 well known NSP problems
to occur under V6.3. They were fixed. We know they were fixed.

I cannot remember the details (and might be wrong) but I think that some
AXP-NSP-X.25 problems were investigated around Oct '95, and maybe a fix
exists. If my memory is right, then the NSP fix might be in ECO-6 (but not
in ECO-5) and you might also require fixes to X.25. I cannot remember whether
the fixes made it into X.25 V1.0G. I think that the problems were to do with
the interaction between NSP/Session and the X.25/GAP software, which is why
you may also need to upgrade the X.25 software, and why you will probably not
see the same problems on VAX systems (at least with current versions).

Finally, and to correct a minor error, if the two ends of an NSP link are
set up for different types of flow control then there is no problem. The
CI (Connect Initiate) specifies the flow control to be used for data going
towards the initiator, and the Connect Confirm specifies the flow control to
be used for data going towards the responder. In other words, a) the DECnis
only requests/uses "No Flow Control" for inbound data, but will use whatever
the other end specifies for outbound data, and b) the flow control in the
two directions of a single link can be different.

Regards,

	John