There is, I think, something ethereal about i —the square root of minus one. I remember first hearing about it at school. It seemed an odd beast at that time—an intruder hovering on the edge of reality.

Usually familiarity dulls this sense of the bizarre, but in the case of i it was the reverse: over the years the sense of its surreal nature intensified. It seemed that it was impossible to write mathematics that described the real world in …

I and i

다중혈관 관상동맥 환자에서 y-문합을 이용하여 양쪽 내흉동맥만을 사용한 우회술의 조기 성적

Imagined communities: Reflections on the origin and spread of nationalism

The modern science of networks has brought significant advances to our understanding of complex systems. One of the most relevant features of graphs representing real systems is community structure, or clustering, i. e. the organization of vertices in clusters, with many edges joining vertices of the same cluster and comparatively few edges joining vertices of different clusters. Such clusters, or communities, can be considered as fairly independent compartments of a graph, playing a similar role like, e. g., the tissues or the organs in the human body. Detecting communities is of great importance in sociology, biology and computer science, disciplines where systems are often represented as graphs. This problem is very hard and not yet satisfactorily solved, despite the huge effort of a large interdisciplinary community of scientists working on it over the past few years. We will attempt a thorough exposition of the topic, from the definition of the main elements of the problem, to the presentation of most methods developed, with a special focus on techniques designed by statistical physicists, from the discussion of crucial issues like the significance of clustering and how methods should be tested and compared against each other, to the description of applications to real networks.

/pdf/community-detection-in-graphs-34rogm3r6p.pdf

Community detection in graphs

https://www.cl.cam.ac.uk/~ey204/pubs/2012_JNCA.pdf

Evaluating opportunistic networks in disaster scenarios

In the last few years there has been considerable research toward extending the Internet architecture to provide quality of service guarantees for the emerging real-time multimedia applications. QoS provision is a rather controversial endeavour. At one end of the spectrum there were proposals for reservations and per-flow state in the routers. These models did not flourish due to the network's heterogeneity the complexity of the mechanisms involved, and scalability problems. At the other end, proposals advocating that an overprovisioned best effort network will solve all the problems are not quite convincing either. The authors believe that more control is clearly needed for protecting best effort service. An important requirement is to prevent congestion collapse, keep congestion levels low, and guarantee fairness. Appropriate control structures in a best effort service network could even be used for introducing differentiation. This could be achieved without sacrificing the best effort nature of the Internet or stressing its architecture beyond its limits and original design principles. We revisit the best effort service model and the problem of congestion while focusing on the importance of cooperative resource sharing to the Internet's success, and review the congestion control principles and mechanisms which facilitate Internet resource sharing.

/pdf/congestion-control-mechanisms-and-the-best-effort-service-3kdrlzcpxe.pdf

Congestion control mechanisms and the best effort service model

The open access, unlicensed or spectrum commons approach to managing shared access to RF spectrum offers many attractive benefits, especially when implemented in conjunction with and as a complement to a regime of market-based, flexible use, tradable licensed spectrum ([Benkler02], [Lehr04], [Werbach03]). However, as a number of critics have pointed out, implementing the unlicensed model poses difficult challenges that have not been well-addressed yet by commons advocates ([Benjam03], [Faulhab05], [Goodman04], [Hazlett01]). A successful spectrum commons will not be unregulated, but it also needs not be command & control by another name. This paper seeks to address some of the implementation challenges associated with managing a spectrum commons. We focus on the minimal set of features that we believe a suitable management protocol, etiquette, or framework for a spectrum commons will need to incorporate. This includes: (1) No transmit only devices; (2) Power restrictions; (3) Common channel signaling; (4) Mechanism for handling congestion and allocating resources among users/uses in times of congestion; (5) Mechanism to support enforcement (e.g., established procedures to verify protocol is in conformance); (6) Mechanism to support reversibility of policy; and (7) Protection for privacy and security. We explain why each is necessary, examine their implications for current policy, and suggest ways in which they might be implemented. We present a framework that suggests a set of design principles for the protocols that will govern a successful commons management regime. Our design rules lead us to conclude that the appropriate Protocols for a Commons will need to be more liquid ([Reed05]) than in the past: (1) Market-based instead of CC (2) Decentralized/distributed; and, (3) Adaptive and flexible (Anonymous, distributed, decentralized, and locally responsive)

/pdf/managing-shared-access-to-a-spectrum-commons-3ti7esemr3.pdf

Managing shared access to a spectrum commons

This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast".

Forward Error Correction (FEC) Building Block

This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC.

Jon Crowcroft

Papers

Evaluating opportunistic networks in disaster scenarios

Congestion control mechanisms and the best effort service model

Managing shared access to a spectrum commons

Forward Error Correction (FEC) Building Block

The Use of Forward Error Correction (FEC) in Reliable Multicast