Results 1 - 10
of
740
RTP: A Transport Protocol for Real-Time Applications
"... Status of this Memo This document is an Internet Draft. Internet Drafts are working documents ..."
Abstract
-
Cited by 1666 (110 self)
- Add to MetaCart
Status of this Memo This document is an Internet Draft. Internet Drafts are working documents
A Proposal to add Explicit Congestion Notification (ECN) to IP
, 1999
"... This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue manage ..."
Abstract
-
Cited by 368 (23 self)
- Add to MetaCart
This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a Congestion Experienced (CE) bit in the packet header of packets from ECN-capable transport protocols. We describe when the CE bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process. 1. C...
Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT
, 1997
"... This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six ..."
Abstract
-
Cited by 224 (20 self)
- Add to MetaCart
This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt " listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The Lightweight Directory Access Protocol (LDAP) [1] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. The syntaxes defined in this document are referenced by this and other documents that define attribute types. This document also defines the set of attribute types which LDAP servers should support. 3. Overview Section 4 states the general requirements and notations for attribute types, object classes, syntax and matching rule definitions.
RTP profile for audio and video conferences with minimal control
, 2000
"... This document is an Internet-Draft. Internet-Drafts are working ..."
Abstract
-
Cited by 195 (23 self)
- Add to MetaCart
This document is an Internet-Draft. Internet-Drafts are working
R.: RFC-3281. An Internet Attribute Certificate Profile for Authorization. The Internet Society
, 2002
"... This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Intern ..."
Abstract
-
Cited by 148 (3 self)
- Add to MetaCart
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at
The Addition of Explicit Congestion Notification (ECN) to IP
, 2001
"... This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. Table of Contents 1. ..."
Abstract
-
Cited by 129 (7 self)
- Add to MetaCart
This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. Table of Contents 1.
Increasing TCP’s initial window
, 1998
"... The initial window MAY be two packets (instead of the current initial window of one packet). For packets of at most 1460 bytes, the initial window MAY be three packets. For packets of at most 1095 bytes, the initial window MAY be four packets. 2 The Burstiness of Current TCP in Slow-Start: cwnd = 1 ..."
Abstract
-
Cited by 105 (16 self)
- Add to MetaCart
The initial window MAY be two packets (instead of the current initial window of one packet). For packets of at most 1460 bytes, the initial window MAY be three packets. For packets of at most 1095 bytes, the initial window MAY be four packets. 2 The Burstiness of Current TCP in Slow-Start: cwnd = 1 packet:) send one data packet ( receive one ACK increase cwnd to 2 packets:) send two back-to-back packets ( receive one ACK (a delayed ACK) increase cwnd to 3 packets:) send three back-to-back packets 3 The Burstiness of Current TCP with a Dropped Ack: cwnd = N packets, N packets are in pipe: ( receive one ACK, acking two packets) send two back-to-back packets ( receive one ACK, acking two packets) send two back-to-back packets ONE ACK IS DROPPED IN THE NETWORK
Real Time Streaming Protocol (RTSP)
, 1997
"... The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both liv ..."
Abstract
-
Cited by 93 (8 self)
- Add to MetaCart
The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889). Contents 1 Introduction 5 1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Protocol Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....
internet calendaring and scheduling core object specification (iCalendar)
, 1998
"... There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provid ..."
Abstract
-
Cited by 86 (3 self)
- Add to MetaCart
There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. This memo is formatted as a registration for a MIME media type per [RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type. The proposed media type value is 'text/calendar'. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below. This MIME media type provides a standard content type for capturing calendar event, to-do and journal entry information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems, using HTTP or some other Internet transport. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities. This memo is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information. In order to avoid confusion with this referenced work, this memo is to be known as the iCalendar specification. This memo defines the format for specifying iCalendar object methods. An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be...
Session Announcement Protocol
, 2000
"... This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors. ..."
Abstract
-
Cited by 83 (2 self)
- Add to MetaCart
This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.

