The increase in link speeds, increased parallelism within routers and switches, QoS support and load balancing among links, all point to future networks with increased packet reordering. Unchecked, packet reordering will have a significant detrimental effect on the end-to-end performance, while resources required for dealing with packet reordering at routers and end-nodes will grow considerably. A formal analysis of packet reordering is carried out and Reorder Density (RD) metric is defined for measurement and characterization of packet reordering. RD captures the amount and degree of reordering, and can be used to define the reorder response of networks under stationary conditions. Properties of RD are derived, and it is shown that the reorder response of the network formed by cascading two subnets is equal to the convolution of the reorder responses of individual subnets. Packet reordering over the Internet is measured and used to validate the derivations.

Improved Packet Reordering Metrics Status of This MemoThis memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. IESG NoteThe content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. The IETF standard for reordering metrics is RFC 4737. The metrics in this document were not adopted for inclusion in RFC 4737. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. AbstractThis document presents two improved metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering.

No abstract

No abstract

An innovative middleware-transparent approach to developing distributed applications is presented. The approach uses an aspect-oriented software development technique to separate an application's middleware-independent functionality from its middleware-specific functionality. Application elements that are specific to the middleware are localized in aspects that can be seamlessly integrated into middleware-independent application designs. The middleware-transparent approach is used to decouple business functionality from middleware-specific functionality. The decoupling allows developers to change middleware application elements without significantly modifying business functionality. Middleware technologies such as Java Remote Method Invocation (RMI), Jini, Simple Object Access Protocol (SOAP) remote procedure call (RPC) and .Net are used as examples to illustrate the approach.Middleware functionality is cross-cutting, in that it is pervasive and is tangled with business-specific functionality in distributed applications. Middleware services (e.g., security), may also cross-cut other middleware features (e.g., event services and transactions). Middleware services are sometimes encapsulated as components. However, to use the services, the business-specific design must include calls to services at appropriate locations in the design and must ensure appropriate ordering of services (e.g., performing authentication before authorization). The cross-cutting nature makes changing the middleware of distributed applications risky and challenging.This paper presents a middleware-transparent approach to the development of distributed applications that allows architects to design business functionality without considering the middleware that will provide transparent access to remote resources. The approach uses an aspect-oriented technique to decouple business functionality from middleware concerns. Middleware-specific application elements are localized in aspects that can be seamlessly integrated (or woven) into an application design describing core business functionality. The localization of cross-cutting middleware concerns helps to insulate designs of business functionality from changes in middleware technologies.The approach can be applied to designs expressed in an aspect-oriented programming (AOP) language, such as AspectJ, or to designs expressed in a modeling language such as the Unified Modeling Language (UML) [6]. The focus of this paper is on the use of the approach at the code level. An overview of how the approach can be used to support model-driven development is given in Sections 2 and 9. BACKGROUNDAdvances in Internet and middleware technologies have spawned a new generation of softwareintensive systems. As organizations seek to enhance services and gain competitive advantage, developers are under increasing pressure to develop quality systems that quickly utilize new technologies. Software evolution is problematic when developers must adapt software systems to rapidly evolving technologies in order to mainta...