Data Processing Procedures CSTS Teleconference M. Götzelmann

Fall Meeting Approach Data Processing Procedure PDO unconfirmed Sequence Controlled Data Processing Procedure PDO confirmed Buffered Data Processing Procedure PDO unconfirmed Forward Synchronous Frame Processing Procedure Forward CLTU Processing Procedure Forward Space Packet Processing Procedure Forward TC Frame Processing Procedure CSTS Teleconference - DPP2 Specification adopted from the original DPP: Processing starts in the sequence data units are received but does not need to terminate in the same sequence

Problem 1 – Reporting of Incidents CSTS Teleconference - DPP3 waitingprocessedcompleted FSP: packet-identification-list: 5, 6, 8, 10, 11, Data unit last OK Data unit last processed Status: interrupted Data unit last processed Data unit last OK Status: completed Data unit last processed Data unit last OK Status: started

Option A CSTS Teleconference - DPP4 Data Processing Procedure PDO unconfirmed Sequence Controlled Data Processing Procedure PDO confirmed Buffered Data Processing Procedure PDO unconfirmed Forward Synchronous Frame Processing Procedure Forward CLTU Processing Procedure Forward Space Packet Processing Procedure Forward TC Frame Processing Procedure Basic Procedures can handle everything, derived procedures constrain allow concurrent processing strict sequential processing

Option B CSTS Teleconference - DPP5 Data Processing Procedure PDO unconfirmed Sequence Controlled Data Processing Procedure PDO confirmed Buffered Data Processing Procedure PDO unconfirmed Forward Synchronous Frame Processing Procedure Forward CLTU Processing Procedure Forward Space Packet Processing Procedure Forward TC Frame Processing Procedure Basic Procedures only support sequential processing, derived procedures add concurrency allow concurrent processing strict sequential processing

Is Option B possible? Viewpoints CSTS Teleconference - DPP6 Data (notify Operation) data-sequence-last-processed data-processing-status data-processing-start-time data-sequence-last-OK data-processing-stop-time production-status packet-identification-list (FSP Extension Parameter) Behaviour general specialised basic behaviour extended behaviour

Problem 1 - Conclusions Constraining basic procedures to sequential processing one data unit at a time – Simplifies the specification and implementation – Can already support a wide range of applications Derivation of procedures supporting concurrency – Is possible for data via extension parameters – Can be argued for the behaviour (although the counter argument has some validity as well) Proposal: in the framework only support strict sequential processing CSTS Teleconference - DPP7

Problem 2 – Queue Overflow Reporting Policies: Discard latest – Data unit last OK = 3 – Data unit last processed = 4? 9? Discard latest – Data unit last OK = 3 – Data unit last processed = 4? 5? Flush Queue – Data unit last OK = 3 – Data unit last processed = 4? 8? Add data unit identification list? User always in spite of overspecification? CSTS Teleconference - DPP

Problem 3 – Inherited Notification CSTS Teleconference - DPP9 Data Processing Procedure PDO unconfirmed Sequence Controlled Data Processing Procedure PDO confirmed Buffered Data Processing Procedure PDO unconfirmed Policy: undefined Notification: Queue Overflow PDO unconfirmed Policy: undefined Notification: Queue Overflow PDO confirmed Policy: always discard latest Queue overflow prevented by rejecting via negative return BUT: notification queue overflow inherited

Questions to the WG A.Shall the simple DPP support concurrent processing of data units or only serialised strictly sequential processing? B.Shall we add a parameter data-unit-identification to all notifications to identify affected data units? C.How shall we inform the user of what data have been discarded following a queue overflow event? D.Can derived procedures simply ignore the notification type 'queue overflow' specified in the simple DDP? CSTS Teleconference - DPP10