WITNO5970141
WITNO5970141
RESTRICTED - COMMERCIAL
PWY/JFO/004
POCL Infrastructure Demo - Meeting Report
Supplier: Pathway Date: 22 November 1995
Attendees:
BA/POCL Supplier
Jeremy Folkes Martin Bennett (Risks - part)
Bob Booth Dave Hollingsworth
Dave Cooke
Tony Hayward (Network)
Glenn Stephens (System Man - part)
Roger Jones (Riposte - part)
Purpose:
Fourth “POCL Infrastructure” demonstrator meeting, concentrating on System
Management and Riposte papers, and TMS sizing/scalability.
Items of Note:
1. Actions from last meeting:
e Scales - no change from previous steer, ongoing.
e Safety Testing - with procurement, ongoing. Steer not before ITT holds.
« Smart products - steer remains that cards will be needed nationally, keys likely to be
regional, volumetrics will be passed over when available. A separate peripheral for
smart keys may be acceptable, whereas smart cards need to be integral to the
solution.
e APPU rollout may be an issue if kit already installed for ECCO and ALPS (to provide
smart card capability), when also wanted for smart key on the SP’s kit. Steer that
there is no technical constraint why further APPUs could not be further
manufactured under the SP’s control - possibly tailored e.g. just smart key. (1290
APPUs have been made so far in two tranches). Obvious commercial issues.
e Requirement issue on whether back office needs impact printing is with the
programme. Steer, not believe impact is required.
e OCR: Pathway’s views on use of OCR have already been flagged to POCL..
Pathway do not currently believe there is a OCR/1D/2D reader in one package.
Indicative costs given as:
e 1D CCD £150-£210
* 2DCCD £220-£300 (for both PDF417 / RM4SCC )
e OCR + 1D wand £380-£410
* Motorised OCR + 1D £480-£550
Choice is therefore either 1D plus either 2D or OCR.
e SP wished us to note that large volumes of OCR are in use, with some 1D but no
2D. Pathway are very keen to push the opportunities of OCR from the experiences of An
Post and presumeably their Girobank relationship?
« SP aware that RECs using bar-codes, and that 110mm reader may be needed - this
pushes away from the current contact CCD, new generation of non-contact CCD
being looked into by SP. Much bigger may force to a contact pen to cope with the
Page 1 of 8
WITNO5970141
WITNO5970141
RESTRICTED - COMMERCIAL
PWY/JFO/004
size, and 2 bar-codes may be easier. Steer to stick with 80mm to keep playing field
level but impact of 110mm needed.
e Thermal printing - will be discussed 29/11, fade characteristics still outstanding.
« Consumable distribution. Defer trying to find a contact within POCL for detailed
discussion, steer remains that POCL is open to using its in place mechanisms.
Feedback is that unlikely to be allowed to talk to distribution until after ITT.
e Archive requirements. Steer remains 18 month minimum retention and the
requirements will colour any solution for access, including the shape of TIP,
requirement extant.
e Issue of moving from one position to another with the terminal “following” without
locking - may be covered in the EPOS FS, and may need to be a requirement.
e Plug-in hard disk - decision extant, pricing decision versus risk.
e French position smart card. On-going but steer of the standard positioning holds.
Stressed ISO 7816 T=0/T=1 and Gemplus GFM2K and GFM4K cards will need to
be supported.
« Network Overview update extant. Volumetrics will be added, for end of this week or
start next.
e Presentation CLI - if included, can have the option of not adopting it (?),
analogue cannot differentiate, ISDN world may be able to differentiate,
true CLI will be passed through the network. Within industry Presentation
CLI Working group, the option of not receiving PCLI has not been offered.
e CUG support issue. If true CLI is used with 20,000 numbers, may be
okay. Introduction during 1997, but issues with cross carrier CUG and policing
there-of.
e Line lengths - BT view that whilst 100% geographic coverage, some
lines may be too long, and then decide whether to add a board into a
road-side exchange (SP believes this will support ISDN). May be
looking at leased lines in certain cases and fallback etc. Steer that
maybe cope with one or two odd cases but more would present
problems.
« IMUX to line cards - possibly need to change the office termination, SP
to investigate. SP suggests a knowledgeable BT’ite join meeting next
week if possible and tie in with network paper if possible - not a sales
pitch,
* problem if PO LTE repetitively fails, can this cause the line to be “lost”
and need resetting at the exchange. Extant.
e does ISDN blacklist akin to modems? Extant.
* p8 s5; large PO’s may have second ISDN-2 line, not a scale factor but
possibly for resilience, due to nature of failures, this may not give much
advantage.
e Internet addressing will be covered in a separate paper update 29/11.
« Power fail officially PO closes, APT has battery back up, may be some “flexibility”.
Believe up to SP to cope with local power supply, this may force UPS in such areas,
at the SP risk.
2. System Management (Glenn Stephens):
Page 2 of 8
RESTRICTED - COMMERCIAL
PWY/JFO/004
Presented “Technical Note on approach to SM’, said to describe what he’d
presented last week - “Captures last week and expands” . Risk 48 paper is
apparently a subset of this paper.
Software distribution will impact bandwidth of network, e.g. new product:
e from 3rd. class stamp - extension to existing application: new/revised
form, extend attribute grammar
e to passport 200K
* to new version of Riposte (zipped circa 2M with applic) and modules
within, SP plans these to be overnight etc.
Figures would be useful within the System Management, with lead times etc. for
distributing different sizes.
How will this be triggered and controlled? Centre has a system management
machine at each site, and - pending a sizing issue - may drive via a secondary tier
to drive the routers. SP have been looking at this, large infrequent would be
targeted for quiet times, and then the correspondence servers would be relatively
idle.
Riposte has series of hunt group numbers from the office, and correspondence
servers know about their population of terminals, the SMS only knows about IP
addresses and routers sort out telephone numbers and ISDN.
Database of IP to Post Offices and IP to ISDN network addresses across gateway
community. Each gateway runs a local copy with master held in one campus and
replicated.
Adding a new office, strategy is a vanilla set of boxes with no personality:
e install pre-configured kit in office
e centre is readied for the Post Office, fed from RIC what hardware
expected, augment with IP addresses, hunt groups to call etc. Group
Office File, and gateways set up to receive calls. Distributed to the
gateway and office.Office opening hours could be within SMS - would
impact frequency ofmarker exchange. Fairly woolly.
e download personality from centre via boot-strap
Envisage SMS with user extensions (thinking on the fly - expect ...), not been finally
decided ... Bar-coded kit for the RIC to feed the information into the system.
Personality files stored in SMS in a SQL database - so can find duplicates.
Need to ensure churn is managed (Pathway not clear ). Response from SP
requested for 6/12 - should show integrated system with little room for error 6/12.
Possibly an issue to highlight with implementation strand.
POCL does hold databases on PO, addresses etc., as well as FAD/FCD codes,
quality of data held varies. Office movement needs to be co-ordinated with BA, and
as the office is fairly soft, a notice on the door can re-direct claimants. (FAD code
may be moved with office and may have two offices with same code in existence at
once).
If do a payment at office (which is disconnected), and remotely which is done at
correspondence layer, when re-synch the discrepancy is noted - how ? SP.
perceives 1:25000 risk. May decide that foreign would not be available if the home
office is not available. BPS issue.
. Review of “The Riposte Architecture” issue 0.7:
Page 3 of 8
WITNO5970141
WITNO5970141
RESTRICTED - COMMERCIAL
PWY/JFO/004
p4: Introduction states that it concentrates on TMS, however Riposte is more
pervasive and covers the desktop as well.
p6: There are on-line issues where communications costs be a restriction. Riposte
does not care about permanent link or off-line. SP views architecture as valid even
if 50% business moves to on-line, though the correspondence server may move
away from distributing down to the offices. Communication link may move to
permanent circuit, with an agent akin to foreign. The auto-recovery and in-pay bits
would still be needed. If 25%+ foreigns then the network economies diminish
(currently based on 5-10% level). Linking additional on-line services to a centre,
rather than to the locally held data would have different, lesser, impact.
“No authority for Bill Payments” - issues on smart raised. SP aware.
p7: “no update” due to append and archive activity. Retrieval is of latest persistent
object. Archiving of persistent objects is different but unsure how. SP to explain how this
works. Incept date e.g. stamp price change on date, and undated old (current) price
needs explanation.
p8: Headings in place but no content. Security paper been submitted separately.
Specific security aspects of Riposte need to be covered, showing the mechanism
not the detail.
p9: CLI touched upon earlier.
p9: CRC is on each message, the index points to the message and then CRC’d,
may also have CRC’s on blocks and the whole journal. Expect to move to
hierarchical checksums so corrupt portions can be re-built. This is new functionality
for scaling up of the journal for BA/POCL to enable it to work efficiently of the
correspondence servers. Dublin was Riposte 2, trial Riposte 32 in Dublin and here; the
change details do not go to this level.
If a message in the journal corrupt, as the file is append only, how is the corruption
treated ? SP to respond.
We need to understand the details and scalability issues - visibility - of scope and
manner in which changes are being performed. How different is the system and
documentation driving these changes would be a good start, these are being driven
by Escher. (embarrassed silence).
Mike Murphy is architect with final say in Escher, mid level by Drew Sutherland (only
these two involved, and Pathway seemed nervous of site visit - possibly 11 Dec. in Boston if
benefit). Advised that site visits being set aside for next week.
p10: how do counter applications interface to Riposte.
p11: Riposte logs all messages, but ignores the ones it does not know about as the
functions to support these messages may not be present. Archiving is at office
rather than application level.
p12: Reliance on grammar declines as persistent journal objects take over, these
are a new item. Latest version of Riposte (32) does not have INI files.
Riposte 32 has everything either in the journal or registry or NT log, indices are
separate files. Further commentary on the index method is required. BPS indices
have been determined, EPOS have not yet got to that stage.
p13: Message store corruption, already covered.
Constrained to a 2 leg model without a special agent, as replicate within groups,
foreign payment goes across groups.
p14: synchronisation activity. Document a bit light and diagrams would help.
Archiving on the fly needs to be covered, indices and pruning of indices. Dynamic by
Page 4 of 8
WITNO5970141
WITNO5970141
RESTRICTED - COMMERCIAL
PWY/JFO/004
space not in place, currently by time period. Do not know how a one position office only re-
synchronises for only its archive period and not to the longer 90+ days worth stored on the
correspondence server.
p16: Confusion on whether marker uses the CRC of the last message or the
sequence number within the 64 bit number. SP to clarify. This may be part of the
scaling up activity but is not finalised, another Riposte 32 change...
p17: 4.3.1.3 how achieved as the JOURNAL.TXT file is a flat file at the counter,
correspondence servers may have other functions turned on and the disk
technology may be different (RAID versus normal). The single journal file will not
work for multiple group and may be separately partitioned on the server, possibly by
different files. SP to clarify.
p18: When come up will send marker when establish connection (point to point) and
ona timer - multi-cast. Marker sent is where you are. SP to clarify. Complete
contradiction from previous explanation !!!
p21: UDP is bound to ISDN lower down the protocol stack - drawing needs
clarification.
UK spec. ISDN is against a simulator, and will form part of the core Riposte.
p23: “saturate” of LAN should not be taken as such.
p25: Lot of work at counter for transition to RPC (delivered Monday in Beta 19, first
beat to support RPC) from DDE, change from counter application slight as goes
through the retail broker, and this is what has changed.
p26: Needs more, how is integrity of system ensured? No tools within Riposte for
orphaned functions. What other tools exist? Not aware of level of confidence that is
being put in place for pathway, Roger Jones would like to see some in place.
Confirm communication/peripherals done in VB, possibly using C where required,
and work must be done by Escher.
p27: Agents, how well do they perform for an on-line authorisation say. Message
written to journal, ISDN replicated to correspondence server, and this has a register
of journal entry types and invokes the relative agent when a suitable message
arrives.
Flexibility / speed of development is not true object orientated, but table driven
through the attribute grammar. Not so “dynamic binding” as seen elsewhere,
number of points in delivery route that constrain.
What system limits are there, peripherals, agents ...
Updated document. Pulling teeth on performance and scalability issues that are going on
behind the scenes.
. IMS sizing/scalability aspects of modelling:
PMS and CAPS connects into one campus; AP clients and TIP Chesterfield into the
other (but with backup routes to the other for both).
This gives PMS as an asymmetric load, EPOS as symmetric, assuming all data
local to the EPOS system as already been replicated. (Gives 4.5Gb for TIPS). Steer
still that currently every transaction will be reported.
PMS data 6 million transactions and replication is each correspondence server
replicates to local and remote correspondence server. Assumes 50% splits.
Page 5 of 8
WITNO5970141
WITNO5970141
RESTRICTED - COMMERCIAL
PWY/JFO/004
e EPOS transaction onto LAN to correspondence server, over LAN to second
correspondence server at same site, over LAN and link to other site.
¢ Assuming 15 million EPOS transactions.
e Loading by statistics 3/16 hit, but due to geographical grouping this is liable to be
higher.
e 100MB backbone (duplexed for resilience), 2 (or more) x 2MB links between
campuses.
¢ Looking at routes Bootle (primary CAPs/PMs) to Leicester (primary EPOS/AP/TIP), also
have to talk to Chesterfield and Newcastle, so these links can be used to assist the
Bootle/Leicester links.
e Model does not consider fall back scenarios.
® Seem quite sensitive to when data is available, and through-put of LANs/WANs needs to be
scaled, along with the cost of Riposte markers - will tune the system to get this under 10% -
may be a bit late then and compromise. Not allow for churn or recovery of machines,
believe collection of data across the backbone due to a correspondence server failure is the
worse case.
Model is busy day.
« Modelling busy hour needs to be done, and need to look at peaks within this as a
transaction per 30 seconds may be possible (allowing queue rotation). Can
envisage 500tps into both campuses @ 300 bytes -> 500*300"8 -> 1.5Mbs"', so
need around 8Mbs link i.e. Megastream link technology is viable.
2MB link gives 2MB in both directions as full duplex.
SMDS can go higher - though charged by volume.
e Correspondence server receives transactions from 1250 post offices, plus 2
replications from 2 other correspondence server (each seeing 1250 POs) and
replicates out the 1250 PO transactions that it received directly.
e The correspondence server and backbone modelling along with efficiency
assumptions and scalability factors (including options for the back bone), and the
gateway that fronts on to the back bone, need to formed as a formal response to the
risk (due 29/11), so that the model may then be examined off-line. For 29/11.
5. Reviewed Risk Register:
e Risk 9 - Scalability and manageability. Discussed; paper to be submitted.
« Risk 19 - Low volume equipment. Discuss 29/11 with peripherals.
e Risk 48 - Distribution of software. Paper received, will review for next week.
e Risk 11 - Impact of keyboard/touch-screen on transaction times. An Post is an
event driven system with little EROS. The way in which the EPOS transactions are
engineered may impact the transaction speed. Functional Specification given to
Application team, showing screen shots and design approach. This will be handed
over for consideration - document will be owned by application team. Paper to
cover this risk for 29/11 possibly accompanied with a demonstration.
Brief demo given of correspondence server running, plus other applications. Speed of
screen refresh raised - told it was due to development code/debug etc. Janet Dore very
keen to show off latest screens etc, seems not to understand what level we are coming from!
Page 6 of 8
WITNO5970141
WITNO5970141
RESTRICTED - COMMERCIAL
PWY/JFO/004
Papers Received:
Pathway Risk Response: Risk PWAY000048 (software update/distributio).
“The Riposte API Issue” 0.9
“Ripposte 32 Advance Release Notice” Issue 1 (Riposte 2 -> 32)
“Overview of Document Reader Options” Issue 1.0
“Technical Note on approach to System Management” Version 1
“PATHWAY - Transaction Lifecycle Exemplars” Version 2
Next meeting:
Wednesday 29/11:
Detailed changes inside Riposte 32
Options for Low volume post offices
Peripherals - reader options
BT ISDN discussion
User administration
System management paper
Riposte Scalability Risk Response
Page 7 of 8
WITNO5970141
WITNO5970141
RESTRICTED - COMMERCIAL
Requirements Queries:
PWY/JFO/004
Is there likely to be a requirement for the AP
bar-code to prompt the clerk to sell-on, in
which case the bar-code size may grow.
Unlikely in some respects, as
other outlets not likely to do this,
and REC puts data on the bill in
the first place.
Chase with Ray Jackson?
Infra
612
knowledge whether feeds to external systems
(eg TIP/Chesterfield) will be single batch or
drip fed?
In case of power failure, should the office Steer - officially close. Lack of kit I Infra 612
continue to function, or be closed down? may enforce this. Do we have a
requirement for UPS in certain
sites?
Temporary (or permanent) closure of an office I Current manual system is very BPS 6/12
- who do payments tied to that nominated flexible as local arrangements can
office get changed? Who ensures the SP has I be made.
the correct nominated PO for both planned
and emergency changes. Tie in here between POCL moves
Likewise, what if an FAD code changes (eg if I and the BPS activity.
the office type - crown/sub/franchise -
changes?).
Franchise/sub refurbishment, does this close I Joins in with “under what Infra 612
the PO and how is this agreed? conditions does an office become
unavailable”. SP will need to be
informed for management
purposes.
Do we have any firm requirements for Steer we need to understand how I Infra 6/12
management of chum? Is this a service level I will be managed by SP.
issue?
Is there requirement / scope, for At operational level need to Infra / 6/12
office/network database from SP to be fed or I establish responsibilities - who Implem
feed to POCL/BA. has master data?
Modelling for this solution needs to have Infra 6/12
Jeremy Folkes & Bob Booth 27/11/95
Page 8 of 8
WITNO5970141
WITNO5970141