S. Armstrong, A. Freier, and K. Marzullo. Multicast transport protocol. RFC 1301, Feb. 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....the required link capacity or choose the appropriate admission threshold. The performance of such schemes depend on how accurate the chosen model describes the traffic characteristics. This paper studies the characteristics of 70 audio traces collected from multimedia conferencing, multicast [13] lectures, distant learning and IP telephony applications. The rest of the paper is organized as follows. Section II describes the traditional on off Markov chain used to model voice conversations. Section III discusses the details of trace collection and processing. Section IV reports the ....

....issues that this paper does not address: We only consider traces over medium time scales (15 minutes 1.5 hours) Data from playback of pre recorded program or broadcast station may have very different traffic characteristics. All our traces are based on RTP packets sent over multicast [13] using the MBone tools [15] including virtual audio terminal (vat) 18] The speakers were using these tools on either Window NT or Free BSD machines. We do not characterize how application software and hardware affect the empirical distributions. ACKNOWLEDGMENTS The authors are grateful to ....

S. Armstrong, A. Freier, and K. Marzullom "Multicast Transport Protocol, " DARPA RFC 1301, Network Working Group, February 1992.

....for hardware implementation; adopts the bucket al..gorithm for error control in multicast connections. This protocol combines the main features from the above protocols; ST II [20] and RSVP [22] allow quality of service parameters negotiation through resource reservation mechanisms; MTP [2]: token based point to multipoint protocol; RAMP [4] provides different levels of QOS according to the desired level of reliability. Although these protocols try to achieve high performance by simplifying their processing overhead, each one has its specific characteristics, which make them ....

S. Armstrong, A. Freier and K. Marzullo, "Multicast Transport Protocol", RFC 1301, Network Information Center, SRI International, February 1992.

....Multicast Routing Protocols 5.0 Multicasting at the other Layers Multicast can be implemented at the different layers of the protocol stack such as the data link layer, network layer, transport layer and application layer. Multicasting in the network layer has been discussed in detail in Section [3] and [4] Multicasting and additional features for the same as provided by the data link layer, transport layer and application layer are discussed in the following subsections. 5.1 Data Link Layer The data link layer protocols such as Ethernet, FDDI, and token ring also provides support for ....

S. Armstrong, A. Freier, K. Marzullo, "Multicast Transport Protocol", Internet Request for Comment 1301, February 1992.

....the receivers request missing data (through multicast) Any host who has a copy of the requested data can answer the request. Sources also transmit periodic session messages reporting their sequence number states. Receivers use these to detect losses and to determine proximity to the sources. MTP [AFM92] uses Nacks (negative acknowledgments) and a master process to guarantee reliable data delivery. The sender responds to the Nack by retransmitting requested data. A source can transmit data only when it receives a token from the master process. SCE [TA95] uses a Single Connection Emulation (SCE) ....

....[Vic98] finding a suitable data organization for a file becomes very complex as the number of layers increases. RMTP [LP96] uses retransmission requests from receivers to handle network congestion. The sender reduces its transmission rate when it receives too many such requests. SRM [FJM 95] MTP [AFM92] and PGM [SFLT98] do not deal with congestion control. In MTCP [RBR98] a sender controls its sending rate based on the congestion summaries it receives from its immediate SAs. SCE [TA95] relies on the unicast transport protocol for handling congestion but has an Ack implosion problem. Existing ....

S. Armstrong, A. Freier, and K. Marzull. Multicast Transport Protocol. Network Working Group, RFC 1301, February 1992.

....As for voice, even small amounts of packet loss can be perceptible to the human ear [DeLW94] We will show in Sections 4 and 5 that retransmissions are both practical and useful for real time media. 3 Overview of Literature As in many light weight transport protocols for high speed networks, [ARMS92] and [BRAU93] propose a NACK only, block basis scheme, to improve data throughput. Our own preference, for reasons that are elaborated in the next section, is towards such a scheme with one qualification: the block sizes cannot be too large, as this will lead to long delays. Again as in most high ....

....that are elaborated in the next section, is towards such a scheme with one qualification: the block sizes cannot be too large, as this will lead to long delays. Again as in most high speed protocols, it is suggested to use a Selective Retransmission (SR) scheme rather than Go BACK N (GBN) In [ARMS92] retransmissions are always multicast. In [ARMS92] a token passing scheme is used for transmission whereby only one host may transmit at a given time. This is not practical for applications such as videoconferencing, where all hosts need to transmit simultaneously. CrPa88] has a feature where a ....

[Article contains additional citation context not shown here]

S. Armstrong, A. Freier, and K. Marzullo, "Multicast Transport Protocol," RFC 1301, February 1992. 37

....it introduces extra delay because data packets are committed only after the token traverses all token sites. For groups with a large number of participants or groups with participants scattered in a wide area, such a token circulation scheme is not feasible. 2. 4 Multicast Transport Protocol MTP [12] provides total data order. It categorizes group participants into producers and consumers. A producer can both send and receive data whereas a consumer can only receive data. A master is elected among the 7 heartbeat data(n) data(n 1) data(n 2,EoW) data(n 3) data(n 4,EoW) data(n 6,EoW) ....

S. Armstrong, A. Freier and K. Marzullo. "Multicast Transport Protocol ". Internet Draft, RFC1301. February 1992.

....area of synchronous groupware also do not need the strong property of reliability, but can nonetheless benefit from a multicast protocol providing some weaker form of reliable transport. An interesting multicast transport protocol with a relaxed view of reliability is defined in Internet RFC 1301 [1]. For use with the X window sharing tool Xy [3] we implemented this protocol. Combined with reliable (TCP) unicast connections, MTP turned out to be a good match for the transport requirements of Xy [2] Based on this experience, we have designed a successor protocol, which aims to achieve ....

....unicast connections will be required between pairs of members. Finally, to be successful, a protocol must be as easy to describe and implement as possible. 3. MTP as a Multicast Transport Platform The MTP reliable multicast transport protocol is defined in Internet RFC 1301, an informational RFC [1]. MTP is designed to be used with unreliable, not necessarily sequence preserving underlying multicast network protocols such as IP multicast. We use the term unreliable in its technical sense of with a loss probability that might be higher than tolerable for an application , not as an ....

[Article contains additional citation context not shown here]

S. Armstrong, A. Freier, and K. Marzullo, "Multicast Transport Protocol," Internet RFC 1301, February 1992.

....have been carried out to explore how to support multicast in various networking environments. Especially, these include systems that use multicast to deliver data and multimedia traffic [1] 2] 3] Other systems support reliable and unreliable multicast over LANs [4] 5] 6] Internet [7] [8] [9] 10] 11] 12] 13] 14] 15] ATM [16] 17] and networks including mobile hosts [18] 19] 20] 21] 22] Multicast flow control is essential for high performance multicast applications. Mishra and Wu [23] studied several techniques of flow control for atomic multicast protocols by ....

S. Armstrong, A. Freier and K. Marzullo, "Multicast Transport Protocol." RFC 1301, Xerox, Apple, Cornell University, 1992.

....distributed applications. For instance, total delivery order is a requirement for the implementation of replicated statemachines [86] which is a general paradigm for implementing fault tolerant distributed applications. Although several protocols have been described in the literature [4, 16, 13, 26, 36, 50, 51, 55, 62, 63, 71], few were speci cally targeted to operate in (geographically) large scale systems. In a large scale network processes trac patterns are usually heterogeneous. The same applies to the network links: some processes will be located within the same local area network whereas others will be connected ....

K. Marzullo, S. Armstrong, and A. Freier. Multicast transport protocol. Internet RFC 1301, IETF, 1992.

....ordering server [18] In this scheme, messages are first sent directly to the ordering server, which then retransmits them in some total order to all receivers. Alternatively, messages can be multicast directly to the receivers, with the central ordering service only sending ordering messages [22]. Like any centralized service, a total ordering service of this type suffers from the problem of how to handle the failure of the central authority. This protocol can be structured as a fault tolerant adaptive system, where the regular total ordering algorithm implements the ordering assuming ....

K. Marzullo, S. Armstrong, and A. Freier. Multicast transport protocol. Technical report, 1992. Internet RPC 1301.

....bandwidth utilization and require more processing. Braudes and Zabele introduced in [BZ93] a Multicast Group Authority, MGA, that arranges nodes into a tree and requires a parent to poll its children for heartbeats to check their connectivity. The owner of the transmit token in the MTP protocol [AFM92] must transmit at least one message in every heartbeat or the master node assumes that it failed and generates a new transmission token. A source node in TRM [SBD96] send heartbeats periodically to the multicast group to declare its state when there is no data to transmit. A connection manager in ....

S. Armstrong, A. Freier, and K. Marzullo. "Multicast Transport Protocol ". Internet Request for Comment (RFC 1301), February 1992.

....the role of end systems are motivated by our desire to provide the highest possible performance and the lowest possible latency. There is a substantial literature on providing reliable multicast mechanisms in networks. One of the earliest contributions was [4] More recent contributions include [1, 2, 6, 8, 10, 9, 11, 12, 13]. Much of this more work is directed toward multicast in the context of the internet protocol suite and shifts much of the responsibility for recovering lost data onto the receivers. The recent paper by Floyd, Jacobson, et al. 7] is a good example of the receiverbased recovery. This paper also ....

Armstrong, S. A. Freier and K. Marzullo. "Multicast Transport Protocol," RFC 1301, 2/92.

....on their past and most recent locations, and agent provided itineraries ) We are well equipped to address this problem, as our systems faculty have strong expertise in the area of group communication. Flaviu Cristian and Keith Marzullo have focused on the reliability aspects [40] 42] 41] 43][8][37] 94] while Joseph Pasquale and George Polyzos have focused on the performance aspects, especially in the context of real time multimedia communications [114] 115] 84] 116] 148] 85] 149] 147] G.2.4 AToken Economy for a Computational Marketplace There are major economical benefits to ....

S. Armstrong, A. Freier, K. Marzullo, Multicast Transport Protocol. Internet RFC 1301, February 1992.

No context found.

S. Armstrong, A. Freier, and K. Marzullo. Multicast transport protocol. RFC 1301, Feb. 1992.

No context found.

Susan M. Armstrong, Alan O. Freier, and Keith A. Marzullo. Multicast transport protocol. IETF Request for Comments (RFC 1301), February 1992.

No context found.

S. Armstrong et al., "Multicast Transport Protocol", RFC 1301, February 1992.

No context found.

ARMSTRONG, S., FREIER, A., AND MARZULLO, K. 1992. Multicast transport protocol. RFC 1301, IETF. Feb.

No context found.

Freier, A., "Multicast Transport Protocol", RFC 1301, February 1992. and Braudes, R., and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993.

No context found.

Amstrong, S., Freier, A. and K. Marzullo, "Multicast Transport Protocol", RFC 1301, February 1992.

No context found.

S. Armstrong, A. Freier, and K. Marzullo. Multicast transport protocol. Internet Request for Comments RFC 1301, February 1992.

No context found.

Armstrong, S., Freier, A., and K. Marzullo, "Multicast Transport Protocol", RFC 1301, Xerox, Apple, Cornell University, February 1992.

No context found.

S. Armstrong, A. Freier, and K. Marzullo, "Multicast transport protocol, " Xerox, Apple, Cornell Univ., RFC 1301, 1992.

No context found.

Armstrong, S., Freier, A., and Marzullo, K., "Multicast Transport Protocol", Request for Comments (RFC) 1301, Feb. 1992.

No context found.

S. Armstrong, A. Freier, K. Marzullo, Multicast Transport Protocol, RFC1301, February, 1992.

No context found.

Armstrong, S., A. Freier and K. Marzullo. "Multicast Transport Protocol.", Request for Comments (RFC) 1301, February 1992.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC