Buffered Data Processing Procedure Version of Comments MG / CCSDS Fall Meeting 2012 Recap on Previous Discussions Queue overflow processing Production Interrupted (processing failures) Further Issues (revisit earlier decisions?) WG DECISIONS

Recap: Previous Discussions & Decisions (1/2) Buffered DPP introduced to support – “AOS Forward Type” of processing Provider not to enforce strict sequence control In case of problems, just drop data unit and continue with next (recovery handled by higher level protocol) – Increased throughput by buffering (  experience in Orange Book prototyping) – Unconfirmed PD Operation to support buffering without the need to fundamentally change approach to CSTS operations CSTS Fall Meeting- BDPP2

Recap: Previous Discussions & Decisions (2/2) Results from the Spring Meeting – Specify the BDPP in a manner that is analogous to BDDP Complete mode with back-pressure Timely mode – discard data when the queue is full – Discard in Units of Transfer Buffer – The data in a TB are either processed completely or not at all – Exception: If processing of a data unit is affected by a fault, only this unit is discarded and other data units delivered with the same TB are still processed – Discard all data units that belong to the TB received earliest for which no data units have started processing yet – Individual Buffer overflow events (and data discarding) are not notified to the user: This avoids repetitive notifications if the queue full situation persists and new transfer buffers are arriving It is assumed that one or more monitored parameters will monitor quality of service (e.g. number of units lost)  creates a dependency on the MD CSTS? A service can add the notification if considered essential – Maximum queuing time not included in the FW BDPP, can be added by a service is needed – Maximum transfer buffer size is a managed parameter CSTS Fall Meeting- BDPP3

Queue Overflow in Timely Mode DA Meeting: discard all data units that have been included in the earliest Transfer Buffer received for which no data unit has started processing until there is enough room to accommodate a maximum sized TB. (YAGNI?) Proposal TR: On queue overflow discard as many of the oldest data units as needed to make room for the data units in the received buffer. – Will work, might be simpler for implementation – Violates the analogy with the return case – Makes discarding of data somewhat arbitrary – Limits the control of the user on how data shall be discarded Do we stick to the decision that no notification is sent? – If yes, add notes on the reason and the assumptions – Alternatively send notification only for the first set of data units discarded (rest overflow recorded flag when a TB is received without the need to discard data) CSTS Fall Meeting- BDPP4

Production Interrupted (Processing Failures) Processing when production changes to interrupted (processing of a data unit fails) should be addressed for both modes (even if we say the same as in the parent procedure) Parent procedure: – Discard a data unit that has started but not completed processing (might not know the status anyway) – Wait until the PS changes to operational again or the user stops the procedure For BDPP would we want to discard the remaining part of the units transmitted in the same transfer buffer? CSTS Fall Meeting- BDPP5

Further Issues … Maximum Queuing Time – Originally proposed by JP as better option than earliest and latest processing time – In DA decided not to use but to delegate the decision to the service using the procedure – Use would better align the return and forward case Transfer / process (with best effort) data of one TB as long a s a specified maximum latency is not exceeded Discard data in units of TB when the maximum latency is exceeded However, if adopted, then we must decide whether and how the user is informed if data are discarded when the latency limit is exceeded. Configuration Parameters – Always to be defined by the service specification (which may delegate to service management) – Should we have a list of configuration parameters for every procedure? (too late?) Specification style currently not quite in line with the other procedures in the framework Actions in state tables should be more explicit (not only expressed in prose) CSTS Fall Meeting- BDPP6

WG DECISIONS Shall the Transfer Buffer be considered as a group of Process Data Operations that should either be processed completely (with best effort) or not at all (YES) or should it be used to increase ground link throughput only (NO)? In case the PS changes to interrupted when a data unit is being processed discard only that data unit or all data units from the same TB that have not been processed yet? In case of input queue overflow discard all data units that were part of the earliest TB received for which no data units started processing until there is room for all data units within a maximum sized TB In case of input queue overflow discard as many of the oldest data units as needed to provide space for the data units in the TB received Do we want to define a maximum queuing time (maximum processing latency) after all data received within one TD are discarded unless at least one of the units started processing? Do we want to define a maximum queuing time (maximum processing latency) after that data units are discarded when processing has not yet started? Do we notify the user of every data unit / TB discarded because the maximum latency has been exceeded? Do we notify the user of an input queue data overflow event that caused data to be discarded? YES NO YESNO one UnitRemaining TB NO YES NO