New proposed issues 7/21 - 7/27

["Marc Goodner" <mgoodner@microsoft.com>]

id	owner	title	target	type
proposed-01		Semantics of "At most once" Delivery assurance	all	design	*
proposed-02		An RM Policy applies two-way	policy	design	*
proposed-03		RM Policy Assertion Model's Base Retransmission Interval Clarification Needed	policy	design	*
proposed-04		Robust recovery from low-resource conditions	core	design	*

 

proposed-01	Semantics of "At most once" Delivery assurance	all - design - unassigned
	Description The semantics of the "at most once" delivery assurance are not clear. One interpretation is that at most once implies that the sender is not required to retransmit mesages which are not acked. Related to i009 Justification It is important to clarify whether the sender must retransmit unacknowledged messages when the "at most once" delivery assurance is in use. Origin Tom Rutt Proposal 12005-07-21 Clarify the semantics. There are at least three possible semantics associated with "at most once" 1.      At most once means that the sender will never retransmit a message, regardless of whether it is acknolweged by the destination. 2.      The sender may retransmis messages, but is not required to to so, however the destination will not deliver duplicates 3.      The sender must retransmit messages, however the destination may drop messages in times of resource saturation, but will never deliver a duplicate.
proposed-02	An RM Policy applies two-way	policy - design - unassigned
	Description In WS-RM Policy, and per WS-PolicyAttachment, RM Policy assertions may be attached to ports. E.g, details of parameters for the resending mechanism. It is implied by doing so, that both inbound and outbound messages are subject to this policy. This assumes that there is a strong case for in and out messages always using the same Delivery assurance. In effect this is saying that an RM Policy applies to two Destinations: the destination of the inbound messages, and the destination of the outbound messages (meaning for example to both a WS endpoint and its clients). Justification Evidence for such an aggregation of quality of service is unclear: On the contrary, both (a) differences in technical capabilities between Source and Destination, and (b) differences in business and QoS requirements, suggest that a policy (delivery assurance) defined for messages going one direction, may not be appropriate for messages going the other way. Origin Jacques Durand Proposal 12005-07-21 Even if the scope of an RM Policy remains at port level there could be an additional scoping attribute stating inbound vs outbound. Yet a cleaner way seems to make use of finer granularity in the attachment (as allowed by WS-PolicyAttachment).
proposed-03	RM Policy Assertion Model's Base Retransmission Interval Clarification Needed	policy - design - unassigned
	Description The RM policy assertion model defines InactivityTimeout and BaseRetransmissionInterval. The text in the specification WS-RM Policy (Page 5) implies that these two parameters are essentially serving the same purpose i.e. to trigger a retransmit based on a timeout value. If this is the intention, the spec needs to clarify the pecking order for an implementation i.e. what if timeout occurs before base retransmission interval has expired. Justification There is no obvious case mentioned in the spec that requires two timers for retransmission upon timeout. Origin Vikas Deolaliker Proposal 12005-07-22 Merge the two into one timer called Retransmission Timeout.
proposed-04	Robust recovery from low-resource conditions	core - design - unassigned
	Description In situations where the RMD is running low on resources, it may want to provide hints to the RMS of its situation with the expectation that the RMS pauses or slows down the (re)transmittal of messages and avoid further straining of RMD resources until recovery. The current solution of statically associating an ExponentialBackoff policy assertion may not be timely and sufficient in all the cases and a more dynamic solution for throttling the message flow may be needed. Justification In a low-resource situation, it is likely that the RMD would discard any incoming messages and stop sending any Acks. Since the current protocol design does not provide for the RMS to become cognizant of the situation on the RMD side, RMS may simply keep on (re)transmitting messages resulting into further resource utilization (network bandwidth, processing power on both ends, etc.) and possibly making the situation worse. It seems that a better option may be for the RMD to push back on the RMS in the event of low-resource like situations and request the RMS for pausing or slowing down any (re)transmissions. Origin Sanjay Patil Proposal 12005-07-26 RM Protocol to support RMD pushing back on the RMS for slowing down or stopping (re)transmission of messages.